The PHP WDDX extension comes with a serialization handler that adds support for the WDDX data format to PHP's session handling. When this data contains a numerical key the key_length variable is not properly initialized which will leak an arbitrary amount of stack data into the session array keys This can lead to the disclosure of sensitive information stored on the stack, like offsets of variables and code (useful for further attacks that require exact offsets), stack canaries, etc. The handling of numerical keys inside the WDDX deserializer is broken switch (hash_type) { case HASH_KEY_IS_LONG: sprintf(tmp, "%ld", idx); key = tmp; /* fallthru */ case HASH_KEY_IS_STRING: php_set_session_var(key, key_length-1, *ent, NULL TSRMLS_CC); PS_ADD_VAR(key); } The numerical key is written into a 128 byte stackbuffer and then (because of the fallthru) the variable is added to the session. Unfortunately the key_length variable is not properly initialized in the numerical key case. Therefore only the beginning of the variable name is initialised and the rest of the key_length bytes comes directly from stack data. An attacker can control how many bytes are leaked by placing a variable with a string name infront of the numerical index variable. In that case the key_length is equal to the length of the variable name and therefore completely under control of the attacker. Proof of concept, exploit or instructions to reproduce The attached proof of concept exploit will leak 8192 bytes of stack data into PHP variables and produce a hexdump. Stackdump --------- 00000000: 31 00 00 00 74 4f 9e bf b1 b7 e5 b7 2c 38 31 65 1...tO......,81e 00000010: 39 66 65 63 b6 01 00 00 19 00 00 00 00 30 fd b7 9fec.........0.. 00000020: f4 8f f2 b7 f4 8f f2 b7 00 35 1f 08 0a 00 00 00 .........5...... 00000030: 80 0e 1f 08 90 08 00 00 4c ef f1 b7 d1 84 e5 b7 ........L....... 00000040: b4 4f 9e bf 69 68 e5 b7 d1 84 e5 b7 00 30 fd b7 .O..ih.......0.. 00000050: 20 00 00 00 40 04 00 00 20 00 00 00 00 30 fd b7 ...@... ....0.. 00000060: f4 8f f2 b7 20 0d 1f 08 45 90 19 08 cc 4f 9e bf .... ...E....O.. 00000070: 6b 95 e5 b7 20 0d 1f 08 f4 8f f2 b7 80 a8 f2 b7 k... ........... 00000080: 01 00 00 00 01 20 00 00 48 4f 9e bf 68 e8 1e 08 ..... ..HO..h... 00000090: 0c a0 1e 08 0c 0d 1f 08 d4 a9 1e 08 ec 9f 1e 08 ................ 000000a0: 08 50 9e bf 8a 98 09 08 74 c7 1e 08 99 20 00 00 .P......t.... .. 000000b0: 18 50 9e bf 24 51 9e bf 00 00 00 00 ec 9f 1e 08 .P..$Q.......... 000000c0: 38 50 9e bf b9 99 09 08 01 00 00 00 28 50 9e bf 8P..........(P.. 000000d0: 0c 00 00 00 ec 9f 1e 08 2c c2 1e 08 68 46 ff 08 ........,...hF.. 000000e0: d4 a9 1e 08 24 51 9e bf 00 00 00 00 60 50 9e bf ....$Q......`P.. 000000f0: f8 59 9e bf 44 f4 15 08 01 00 00 00 ec 9f 1e 08 .Y..D........... ... Notes This is one of the many vulnerabilities of the MOPB that were previously disclosed by us to the vendor and is therefore fixed in their latest updates. We therefore recommend updating PHP atleast PHP 4.4.5 or PHP 5.2.1 to fix this issue. SecurityReason Note : Exploit - http://securityreason.com/exploitalert/2055