Improving the ASLR of Mac OS X Snow Leopard

December 25th, 2010 by Stefan Esser

Last week I presented my research about “Adding ASLR to jailbroken iPhones” at the Power of Community 2010 (POC2010) security conference in Seoul. During my talk I explained how one can use a modified ‘rebase’ utility to rebase the dynamic linker dyld on the iPhone. Rebasing dyld is important because it contains enough code gadgets that can be used to kickstart arbitrary shellcode on jailbroken iPhones. A tool called Antid0te will be released until the end of this year that allows normal users to add ASLR to their iPhones. The release of this tool was originally planned for 24th December 2010 but it had to be postponed because I got really ill and also my glasses broke.

Anyway a few days ago I demonstrated how my “rebase dyld” research that was originally done for the iPhone applies directly to the dynamic linker used by Mac OS X Snow Leopard. I released a short article describing how one can rebase his dyld binary with a patched ‘rebase’ utility which I also released. This can be used to rebase your own dyld binary to a different position. Rebasing dyld to an address other than the normal one, improves the security of your Mac because all the public articles/techniques about state of the art Mac OS X exploitation assume/require the dyld binary to be loaded at a fixed address. All attacks based on this will fail once you have rebased your dynamic linker binary.

So enjoy this little christmas present until I am fit enough to release antid0te.

Speaking at POC 2010 - ASLR for jailbroken iPhones

December 1st, 2010 by Stefan Esser

December has arrived and it is time to announce my talk for the Power of Community security conference in Seoul. This year I will not only return there for the 3rd time as speaker, but this time I will talk about something not related to PHP or web security at all. My company SektionEins recently started to offer mobile security audits and I am now playing around with iPhone security all the time which resulted in the talk that I will present at POC this year.

Session: Adding Address Space Layout Randomization (ASLR) to jailbroken iPhones
This year has brought bad news for the security of the iPhone. First it was demonstrated during the PWN2OWN contest that ROP payloads can steal information like the SMS database from factory iPhones and later this year combined multiple exploits for vulnerabilities in MobileSafari, the iOS kernel and the userland to jailbreak the device from remote. And for jailbroken devices the situation is even worse because the jailbreak weakens the otherwise strong security features of the iPhone in a way that remote exploits are far easier to accomplish.

However it is time to remember that the whole purpose of a jailbreak is to free the device from Apple and to allow users to do whatever they want with their device. The fact that current jailbreaks destroy the security is just because jailbreakers did not bother to find a better solution. This changes now.

In this session the differences in exploiting jailbroken and factory iPhones will be highlighted and it will be explained step by step how a new tool was developed that adds ASLR (address space layout randomization) to jailbroken iPhones. With ASLR an exploit mitigation is added that is not available in factory iPhones and makes exploitation more difficult. And this is only the first step, more mitigations and a full reactivation of the codesigning protection are planed for the next months.

See you in Seoul between 13th and 16th December.

서울에서 12월 13일에서 16일에 만나요!

Month of PHP Security 2010 has begun…

May 2nd, 2010 by Stefan Esser

In case you haven’t noticed it through the other channels already…

The Month of PHP Security 2010 has finally begun.

During the Month of May 2010 we (SektionEins) will post every day at least one new vulnerabilities in PHP and one new vulnerability in a PHP applications. In addition to that every other day we will post an article about a PHP security topic or a new PHP security tool. Among these articles and tools are those that were submitted to us during the Month of PHP Security CFP.

BTW: You can also follow the Month of PHP Security on twitter.

SyScan-Workshop: Advanced PHP Auditing at Source and Bytecode Level

April 19th, 2010 by Stefan Esser

At SyScan’10 Singapore I will give a two day workshop about “Advanced PHP Auditing at Source and Bytecode Level”.

This course will teach students advanced methods and techniques for PHP application audits at source code and at bytecode level. The students will get to know the most common PHP security problems and how to find them at source code and bytecode level. Throughout the course several free and open source software tools will be introduced and used in order to visualize application structure, find security problems with static and dynamic analysis on source code and bytecode level and also to break PHP bytecode encryption.

You can read the full description here. During the course students will get exclusive access to a few of our internal tools. You should apply early because seats are limited. And if you want to get training like this outside of a conference, then please contact

MOPS CFP: Deadline Extension - April 18, 2010

April 9th, 2010 by Stefan Esser

The Month of PHP Security committee has decided to extend the CFP deadline from April 11, 2010 to April 18, 2010. The reason for that is very simple: so far we only got a few submissions from the PHP community and the security community. Even fewer submissions than we have prizes. Therefore it is only fair to wait a bit more for your submissions.

There seems to be a confusion about the accepted topics.

  • We do not only accept but welcome articles about PHP security topics. The whole point of involving the community in MOPS was to gather articles about secure PHP programming or PHP security research.
  • We will accept vulnerabilities in PHP applications as long the application is installed on more than 100 systems and the vulnerability gives you access to the data or to the system. However you have to write a text describing the vulnerability and what you can do with it.
  • You DO NOT loose any rights by submitting something to us. You will be credited and in case of bugs you are also allowed to write your own advisory to bugtraq (or whereever else). In case of articles you can reuse them for everything you want. Only condition: no other publication before the article/bug appears during MOPS.

To revisit the full list of accepted topics: look here.

If there are no more community submissions this does not mean that the MOPS is cancelled. We at SektionEins GmbH will ensure that there is enough content to fill each day. In any case the Month of PHP Security will start on May 1, 2010.

TIP: If you send in an article please ensure that chapters titled “conclusion” actually contain a conclusion and not “WE ARE THE MOST AWESOME GUYS IN WEB APP SEC - HERE IS A LINK LIST OF OUR OTHER PROJECTS”

MOPS - Zend Webinar: Secure Application Development with the Zend Framework

April 9th, 2010 by Stefan Esser

During the Month of PHP Security there will be a Zend Webinar about “Secure Application Development with the Zend Framework” by me. While this webinar is not directly connected to the MOPS and the time (5th of May) is just a coincident it fits nicely into the whole MOPS idea. The webinar contains the following content:

More and more developers have started to use Zend Framework for new PHP application development projects. This changes the way applications are developed, because more framework components are used and less core PHP functions. Therefore new guidelines for secure programming are needed.

This webinar will introduce the audience to Zend Framework features that help while developing secure applications and to features that result in security vulnerabilities if wrongly used. Zend Framework’s own security features will be explained and evaluated what kind of security problems still have to be dealt with by the programmer himself.

Because I am not entirely sure how many visitors can attend a Zend Webinar you should register early.

Zend Webinar: Sichere Applikationen auf Basis des Zend Frameworks

March 14th, 2010 by Stefan Esser

Hier einmal ein Announcement in letzter Minute: in zwei Tagen halte ich für Zend ein Webinar über “Sichere Applikationen auf Basis des Zend Frameworks“.

Immer mehr PHP-Entwickler setzen das Zend Framework bei der Programmierung neuer Applikationen ein. Für die Entwicklung bringt dies einige Veränderungen mit sich, da mehr und
mehr Framework-Komponenten benutzt werden und immer weniger direkt auf PHP Funktionen zurückgegriffen wird. Dadurch ändert sich auch der Prozess, wie sichere Applikationen zu entwickeln sind.

In diesem Webinar erfahren Sie, welche Features des Zend Frameworks die Entwicklung sicherer Applikationen erleichtern, welche Features bei falschem Einsatz zu Sicherheitsproblemen führen können, welche Sicherheitsfeatures existieren, wie man sie einsetzt und welche Sicherheitsprobleme nach wie vor alleine gelöst werden müssen.


March 5th, 2010 by Stefan Esser

Together with the release of PHP 5.3.2 by the PHP team I have released Suhosin-Patch which comes with bugfixes and new features. The changes are:

  • fixed some crashbugs for IA64 architecture
  • check return value of mprotect() to ensure that memory is read only - credits: PAX Team
  • fixed mprotect() call - encrypted pointer was used in revoked 0.9.9 - credits: PAX Team
  • added additional hardening to destructor protection
  • added pointer obfuscation to memory manager
The most important new feature is the pointer obfuscation inside the PHP memory manager. This mitigation makes it much harder to exploit lots of memory corruptions correctly. Pointer obfuscation is also used to protect the pointer to the read only configuration inside Suhosin-Patch that allows it to be configured by environment variables.

Month of PHP Security - Blog Post Drawing

March 5th, 2010 by Stefan Esser

While going through the HTTP_REFERER log of the Month of PHP Security website I realised that there are more incoming refers from various blog posts about it than there are submissions to Like I previously announced we will honor 10 blog postings with 25 EUR amazon coupons. The winners will be selected by random, however only among those we will select that announce their blogpost to us via the email address provided above.

The reasons for this rule is very simple. Without the announcement we would have to look at every new HTTP_REFERER and manually check if it is just spam, an old link to the Month of PHP Bugs, someone who just copied the blog of another person or other nonsense. In addition to that we have to find a contact address of the person who originally has written the entry and ask him/her if he/she wants to take part in the drawing. This would be too much work. Therefore announce your blog posting to or you have no chance of winning one of the coupons.

Patch breaks Suhosin Security Feature in Debian Unstable/Testing

February 27th, 2010 by Stefan Esser

Two days ago I installed a mail client on my reinstalled desktop system that was not doing anything for 2 month and checked mails of the hardened-php account that were not checked for 2 months. Usually noone uses this email account to contact me, but the Suhosin bug reports sometimes end up there. While killing thousands of SPAM messages I also found a message from the Debian PHP maintainers, dating back to the 10th February 2010, telling me about a crash problem inside the Suhosin patch. The email also contained their solution to the problem: a patch for the suhosin patch. You can view this patch here. However you should not commit this patch to your PHP because it does not solve the problem correctly.

I previously blogged about one of the new features in Suhosin Patch for PHP 5.3.x. It is now possible to adjust several internal features by setting certain environment variables on startup. This includes the memory manager canary protection, the sanitization of free memory blocks, the protection of linked lists and hashtables. When a Suhosin patched PHP starts the environment variables are evaluated and the suhosin config is written into a variable called suhosin_config.

It should be obvious that this kind of feature comes with a little problem. Certain bytes in memory now control if Suhosin’s internal memory protections are activated or not. This means that a memory corruption vulnerability in PHP could be used by an attacker to overwrite the config variable and disable the security. Because of this Suhosin Patch tries to align the suhosin_config variable to a page boundary and then set it to read only.

/* hack that needs to be fixed */
#ifndef PAGE_SIZE
#define PAGE_SIZE 4096
#ifdef ZEND_WIN32
char suhosin_config[PAGE_SIZE]
#if defined(__GNUC__)
__attribute__ ((aligned(PAGE_SIZE)))
static void suhosin_write_protect_configuration()
#if defined(__GNUC__)
   mprotect(suhosin_config, PAGE_SIZE, PROT_READ);

The implementation has some problems. First of all it only works in case of a GNU C compiler. The second and more serious problem is that it assumes that the PAGE_SIZE is smaller than or equal to 4096. Otherwise mprotect() will not correctly work. On systems where the PAGE_SIZE is bigger than 4096 the mprotect() will either fail or set too many bytes to read only. In case of a write access after the suhosin_config variable this can lead to a crash.

The Debian people saw this crash on some architectures and reacted with a patch. However they did misunderstand the security idea behind it and therefore their patch looks like this.

char *suhosin_config = NULL;
static void suhosin_write_protect_configuration()
#if defined(__GNUC__)
   mprotect(suhosin_config, sysconf(_SC_PAGESIZE), PROT_READ);
if (!suhosin_config) {
   suhosin_config = mmap(NULL, sysconf(_SC_PAGESIZE), PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0);
   if (suhosin_config == MAP_FAILED) {

The Debian maintainers tried to fix the problem by replacing the aligned suhosin_config variable with a pointer. They then allocate a single memory mapped page and set it to read only. While this fixes the possible crash it shows that the Debian PHP maintainers did not fully understand the idea behind that code. The patch ensures that the suhosin configuration is set to read only, but now a memory corruption exploit can just overwrite the suhosin_config pointer and let it point to a memory area that contains a new configuration.

A correct fix would be to check if the dynamic page size is indeed bigger than 4096 and in this case just warn the user that he should recompile PHP with a bigger PAGE_SIZE definition and do not set the variable to read only in this case. But this might arise the next problem that the PAGE_SIZE might exceed the maximum alignment that the compiler supports.

UPDATE: I rewrote several parts of this blog entry to make it less critic and sound less aggressive. I spent the day discussing possible fixes and other problems with the current solution. The current solution is also not safe in all cases (all OS/architectures/compilers) because of intermediate pointers introduced by the compiler that are invisible at the C level. The solution to this is that the runtime configurability of Suhosin will become optional and can be selected at compile time. If the runtime configurability is selected the sysconf() method will be used to determine the correct page size. The pointer however will be protected by pointer obfuscation/encryption and maybe checksums.