The new S: data type added to PHP 5.2.1's serialisation format is completely broken. The new feature it is supposed to add, the handling of escaped strings does not work at all and leads to disclosure of heap memory content. With PHP 5.2.1 the new S: data type was added to unserialize(). It is meant as compatibility layer for exchange of serialized data with future PHP 6. The data type itself is similar to the normal s: string data type with the exception that simple escaped bytes are supported. The following string is an example. S:10:"\55\44APXY" Unfortunately the unserialization of such escaped strings is completely broken and does not work as advertised at all. Instead of returning a string of 6 bytes , when deserialized, the above example will always return 10 bytes or error out, because it does not stop when 10 input bytes are processed but when 10 output bytes are written. In cases where the next byte is a " character this will leak the memory between the last real output byte and the ". This is demonstrated in the attached POC. Proof of concept, exploit or instructions to reproduce When the attached exploit is executed it will try to create the necessary memory layout, leak some heap data into a PHP variable and output is as hexdump. If the attempt is successfull the memory dump will contain a memory header with memory cookie and a Hashtable bucket. From this heap adresses (or the secret cookie) can be extracted for other exploits. Heapdump --------- 00000000: 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 aaaaaaaaaaaaaaaa 00000010: 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 aaaaaaaaaaaaaaaa 00000020: 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 aaaaaaaaaaaaaaaa 00000030: 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 aaaaaaaaaaaaaaaa 00000040: 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 aaaaaaaaaaaaaaaa 00000050: 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 aaaaaaaaaaaaaaaa 00000060: 61 61 61 61 22 00 00 00 00 63 da 58 21 fd 00 00 aaaa"....c.X!... 00000070: 00 45 01 00 00 26 bb b9 7e ca 00 00 00 b0 72 91 .E...&..~.....r. 00000080: b7 18 6f 91 b7 a0 73 91 b7 00 00 00 00 00 00 00 ..o...s......... 00000090: 00 00 00 00 00 22 22 22 22 22 22 22 22 22 22 22 .....""""""""""" 000000a0: 22 22 22 22 22 22 22 22 22 22 22 22 22 22 22 22 """""""""""""""" 000000b0: 22 22 22 22 22 22 22 22 22 22 22 22 22 22 22 22 """""""""""""""" 000000c0: 22 22 22 22 22 22 22 22 22 22 22 22 22 22 22 22 """""""""""""""" 000000d0: 22 22 22 22 22 22 22 22 22 22 22 22 22 22 22 22 """""""""""""""" 000000e0: 22 22 22 22 22 22 22 22 22 22 22 22 22 22 22 22 """""""""""""""" 000000f0: 22 22 22 22 22 22 22 22 22 22 22 22 22 22 22 22 """""""""""""""" 00000100: 22 22 22 22 22 22 22 22 22 22 22 22 22 22 22 22 """""""""""""""" 00000110: 22 22 22 22 22 22 22 22 22 22 22 22 22 22 22 22 """""""""""""""" 00000120: 22 22 22 22 22 22 22 22 22 22 22 22 .. .. .. .. """""""""""".... Notes For us it is a mystery why completely untested code goes into a final PHP release. The new S: data type does not work at all and can only be used by an information leak exploit, therefore the most basic test should have revealed that it is broken. Additionally it is a mystery for us why the PHP developers add compatibility layers for the exchange of serialized data between PHP 5 and PHP 6. Whenever a security vulnerability in unserialize() comes up you will hear them say that you don't use unserialize() on user supplied data anyway. So why implement a hack that is supposed to make data exchange (which is exactly user supplied data) easier? MOPB NEWS: No the MOPB is not dead yet, the bugs that were supposed to be released during the last 2 days will just be added to the daily bugs of the next days. SecurityReason Note : Exploit - http://securityreason.com/exploitalert/2218