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.

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 jailbreakme.com 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일에 만나요!

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.

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 info@sektioneins.de.

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”

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.

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.

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 drawing@php-security.org or you have no chance of winning one of the coupons.

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
#endif
 
#ifdef ZEND_WIN32
__declspec(align(PAGE_SIZE))
#endif
char suhosin_config[PAGE_SIZE]
#if defined(__GNUC__)
__attribute__ ((aligned(PAGE_SIZE)))
#endif
;
 
static void suhosin_write_protect_configuration()
{
#if defined(__GNUC__)
   mprotect(suhosin_config, PAGE_SIZE, PROT_READ);
#endif
}

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);
#endif
}
...
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) {
      perror("suhosin");
      _exit(1);
   }
}

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.