Over at Zone-h is a new post that talks about how the PHP 5 branch of the PHP source code lacks the protection against possible integer overflows inside ecalloc() that is present in the PHP4 branch and also for several years part of the Hardening-Patch and the new Suhosin-Patch. It was discovered that such an integer overflow can be triggered when user input is passed to the unserialize() function. Earlier vulnerabilities in PHP's unserialize() that were also discovered by one of the audits in December 2004 are unrelated to the newly discovered flaw, but they have shown, that the unserialize() function is exposed to user-input in many PHP applications. Examples for applications that use the content of COOKIE variables with unserialize() are phpBB and Serendipity. The successful exploitation of this integer overflow will result in arbitrary code execution, the author explains.

According to the author, several years ago when integer overflows inside the calloc() function-family became popular in the security industry, many function libraries that contained similar allocation functions were hardened against the possible multiplication overflow. The ecalloc() function used in the Zend Engine 1 was one of the functions that were hardened against this kind of attack. Unfortunately the PHP developers never bothered merging this protection into the code of the Zend Engine 2, which powers PHP 5. However when Hardened-PHP was created by in 2004 a similar protection of ecalloc() was added to the patch. Therefore users are safe from the problem described here.

unserialize() is a PHP function that allows deserialisation of previously serialised PHP variables. Many applications use it to store PHP variables in an easy accessible data format. Some of them even put serialised strings into COOKIEs and later unserialize() them again. Unfortunately passing user-input to unserialize() is a bad idea because it also supports the deserialisation of objects, which might influence the application. Additionally it is trivial to crash PHP with a large amount of nested arrays, the author explains.

Furthermore the author discovered that storing a large value for the number of array elements into the serialised string will trigger an integer overflow inside ecalloc(), resulting in the allocation of 0 bytes (plus the Zend Memory Manager management headers). When this happens unserialize() will continue working with a small bucket array. When the string is parsed for the array elements the HashTable functions will operate on memory not allocated for this purpose. This can lead to several different memory corruption attacks, the author warns.

A carefully crafted string can use this to execute arbitrary code. In the proof of concept exploit this is achieved by storing a HashTable with the destructor into the PHP array. When the PHP variable is destroyed this will result in the execution of shellcode, the author concludes.