#29399 [Csd]: Unserialize() really doesn't like some input strings...

ID: 29399 User updated by: AxelLuttgens at swing dot be Reported By: AxelLuttgens at swing dot be Status: Closed Bug Type: Reproducible crash Operating System: Mac OS 10.3.4 PHP Version: 4.3.8 New Comment: Thanks a lot for the follow-up. Sincerely, Axel Previous Comments: ------------------------------------------------------------------------ [2004-10-04 04:22:24] iliaa@php.net This bug has been fixed in CVS. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. ------------------------------------------------------------------------ [2004-07-28 16:52:32] AxelLuttgens at swing dot be First of all, sorry for the inaccuracy of my previous information. I forgot to use the compiled CLI, so that I used the stock install one (which I leave in place for maintaining compatibility with Apple's upgrades, if any). In a word, both my compiled CLI and apache module fail in the same way. Fortunately, in a sense ;-) Same crash in var_unserializer.c at line 320. So, I reviewed what I wrote at the time of another report (Bug #26078), which had been classified as "Won't Fix". Since then, some slight differences have been introduced in the code of var_unserializer.re, so that the potential problems I noticed at that time may now have turned into real problems. So, I just tried this change in the code of var_unserializer.c: 309 if(yych <= '}') goto yy13; 310 /* if(yych <= '\277') goto yy15; */ 311 if(yych <= 255) goto yy15; 312 goto yy2; Of course, the compile warning now goes as "comparison always true". All tests (make test) concerning serialize/unserialize pass. (they did before too, so that I didn't notice anything at that level) The resulting CLI and module now both accept something like this: <?php for ($i = 0; $i < 256; $i++) { $str = chr($i); unserialize($str); } ?> without crashing. And I didn't encounter crashes with my real work php codings any more. Of course, these are not extensive testings. But there is good hope to be on the right way. HTH, Axel ------------------------------------------------------------------------ [2004-07-27 18:48:49] iliaa@php.net Please leave at feedback until more information is available. ------------------------------------------------------------------------ [2004-07-27 17:09:39] AxelLuttgens at swing dot be Thanks for the reply! I downloaded the cvs, and noticed that var_unserializer.c has not been modified since the version I have compiled (files 100% identical). Do you really think the problem could be solved with the cvs? I ask because I'm really busy at the moment, and possibly a bit lazy too... :-) But your reply of course made me think a bit further. So, executing the short sample file through the CLI doesn't trigger the exception. I also performed some other quick tests, that could lead to the conclusion that my compile has some flaws :-( I'll investigate further, and hope to be able to keep you informed as soon as possible. In the meantime, sorry for what could prove to be just noise, Axel ------------------------------------------------------------------------ [2004-07-27 02:10:56] iliaa@php.net Please try using this CVS snapshot: http://snaps.php.net/php4-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-STABLE-latest.zip I've tried the sample script and I got the expected FALSE output as well as E_NOTICE saying: unserialize(): Error at offset 0 of 1 bytes ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/29399 -- Edit this bug report at http://bugs.php.net/?id=29399&edit=1