I’ll point this info to the guys who are working with the php Serializer. I think we also need to detect the versions of php with exploitable bugs in unserialize and refuse to run.

First Javascript has a different concept of string length, being smarter than PHP in that area. What it means is if people attempt to send multi byte characters from Javascript to PHP, they will get errors from PHP’s unserialize. I described the problem a little here: http://www.sitepoint.com/blogs/2004/10/31/how-long-is-a-piece-of-string/ - in JPSpan finally gave up on trying to support multibyte charaters via this approach, warned people off and had the PHP serializer strip anything non-ASCII. See the encodeString function here: http://cvs.sourceforge.net/viewcvs.py/jpspan/jpspan/JPSpan/js/encode/php.js?view=markup

Second and more serious is, on the PHP side it’s blindly unserializing whatever it receives. Where that’s a problem is someone could “inject” class names via the serialized string and PHP’s unserialize will create an object from them, meaning the class constructor get’s executed.

Whether that’s a danger is will depend on the class itself - in PHP4 the risk / impact is probably quite low. You also can’t pass arguments to the constructor. But in PHP5, where there are now alot of built-in classes registered by default, the chances of finding something where the constructor is “dangerous” is much higher plus autoload potentially widens the net.

Described that problem here http://www.php.net/manual/en/function.unserialize.php#45503 along with solution that pulls out class names from a serialized string which hasn’t yet been unserialized. You’ll find unit tests for that function in the “TestOfJPSpan_Unserializer_PHP_getClasses” class here: http://cvs.sourceforge.net/viewcvs.py/jpspan/jpspan/tests/php/unserializer_php.test.php?view=auto