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 idea of the project is very simple. During a PHP upgrade there is always the possibility that some bug was introduced, some behaviour changed, some crash was introduced, some functions got deprecated. This possibility can be measured from past statistical values and interpolated into the future to simulate an update.

At this point I want to thank all the members of the PHP community that helped me reviewing the bug reports from the last 5 years to gather information about the likeliness of each incident. It was hard work, but it was worth it. In the end we developed a formula that determines how likely one of the incidents is given a certain delta in the version number.

To use the extension you simply have to compile, load and configure it like every other PHP extension. The configuration directive is called usim.upgradeversion. You just set it to whatever version you want to simulate.

usim.upgradeversion = 5.4.17

From that point on your PHP installation will behave like an interpolated PHP 5.4.17. The following features are supported:

• Important functions are suddenly deprecated
• Deprecated functions are removed
• Not deprecated functions are removed (e.g. move to PECL)
• Introduction of random crashes (on shutdown, during functions, on function call)
• register_globals and magic_quotes_gpc randomly turned on and off
• safe_mode removed
• Leaking of .ini directives to other VHOST (e.g. open_basedir)
• Introduction of new keywords or classes which collide with popular names
• Random change of the namespace separator character during minor upgrades
• Change of default memory_limit

The PHP Upgrade simulator is available here for download. Have fun with it.

Yesterday I was able to take this picture of two of the guardian ghosts that are called Suhosin over here in Korea. This might help designing a long overdue logo for Suhosin.

• Fixed problem with suhosin.perdir
  Thanks to Hosteurope for tracking this down
• Fixed problems with ext/uploadprogress
  Reported by: Christian Stocker
• Added suhosin.srand.ignore and suhosin.mt_srand.ignore (default: on)
• Modified rand()/srand() to use the Mersenne Twister algorithm with separate state
• Added better internal seeding of rand() and mt_rand()

The last three items in the changelog mean that the randomness of PHP’s rand() and mt_rand() functions have been greatly improved over vanilla PHP. This means when the Suhosin extension is installed on a server all the attacks described in my previous blogpost about PHP’s random number generators are no longer possible. This adds another generic protection to kill a whole class of bugs at once.

As usual you can grab your copy at

http://www.suhosin.org/

Today I present the more interesting approach that I promised to publish after my webinar yesterday. This approach is based on the idea that SQL queries issued by an application always have a certain structure. This structure can be learned and remembered by MySQL-Proxy. Any SQL query that has a different structure can then be considered an attack.

Training Mode

The first Lua script learn_sql_queries.lua uses MySQL-Proxy’s read_query hook to catch COM_INIT_DB and COM_QUERY packets. COM_INIT_DB packets are issued when the database is changed and COM_QUERY packets contain normal queries.

When a change of database is detected a CREATE TABLE is injected into the communication to create a table called ‘allowed_queries’ in the newly selected database. This table consist of only on column called ‘query’. Within this column normalized queries are collected.

When a normal query is received it is first tokenized by MySQL-Proxy’s tokenizer. The tokens are then used to recreate a normalized version of the query where all data values are replaced by the ‘?’ placeholder. Additionally IN ( ?, ?, ?, …) statements are compressed to IN ( ? ) to allow arbitrary length IN value lists without having to learn all possibilities. The normalized query is then learned by inserting it into the table.

When all queries have been learned (maybe during development) the blocking mode can be started.

Blocking Mode

The second Lua script block_unknown_queries.lua also uses MySQL-Proxy’s read_query hook to catch COM_INIT_DB and COM_QUERY packets.

When a change of database is detected a SELECT statement is injected into the communication that loads the table ‘allowed_queries’ into a Lua-Table. The queries become the indices so that they can be found fast.

When a normal query is received it is first tokenized and normalized. The normalized Query is then searched in the Lua-Table which is just a key lookup. If the query is found in the table it is one of the known query structures that are allowed. The query is then executed as normally.

If the query is not found in the table it is either a query that was not learned by mistake or it is an SQL-Injection attack. The query is not executed and a database error “Possible SQL Injection” is returned.

Both proof of concept examples are released as GPL. Therefore feel free to modify them for your needs. You might prefer to just log SQL-Injection attempts instead of blocking them.

Is it?

Well not really, because there are still millions of servers running PHP 4 that haven’t upgraded to the faster, more stable and more secure PHP 5 and most of them will continue to use it. So PHP 4 will still be around a while.

However last night PHP 4.4.9 was released which is the final security update by the PHP development team. This means from now on not only normal support (which was dropped at the end of 2007) but also security support for PHP 4 has ended. It is therefore recommended to finally upgrade.

Because I know that upgrading is sometimes not that easy Suhosin will continue to support PHP 4 for a while. This means the current Suhosin-Patch 0.9.6 will be ported to PHP 4.4.9 and also the next release of Suhosin-Patch will still support recent PHP 4 versions. However at the end of 2008 I will also discontinue Suhosin-Patch for PHP 4 and new features to the Suhosin-Extension will only be implemented for PHP 5.

• Fixed PHP 4 compilation problem introduced in 0.9.24
• Fixed PHP 5.3 compilation problem
• Changed PHP default POST handler to PHP’s current handler

As usual you can grab your copy at

http://www.suhosin.org/

The flexibility of MySQL Proxy is based on the fact that every aspect is scriptable with Lua. Because I am new to MySQL Proxy and the Lua language I tried to implement a very simple script that waits for incoming SQL queries, tokenizes them and tries to detect SQL Injection heuristically by searching for certain disallowed SQL functions, databases, tables, statements or comments. When an SQL query is believed to contain an SQL injection is it not executed and a “Possible SQL injection” error is returned.

You can grab the detect_sql_injection.lua script at

http://www.suspekt.org/downloads/detect_sql_injection.lua.gz

If you are interested in this and german speaking you might also be interested in next week’s MySQL webinar “Bau sicherer LAMP Anwendungen” where I will not only discuss this little Lua script but also another one that implements SQL injection detection by query structure learning.

Today I start with announcing the Switch Table Extension that I released yesterday with a short announcement on the PHP Internals mailinglist. The purpose of this experimental extension is to speed up the execution of repeated switch() statements. To understand how this achieved and why this is necessary read the documentation here.