PHP :: Bug #29399 :: Unserialize() really doesn't like some input strings...

Bug #29399	Unserialize() really doesn't like some input strings...
Submitted:	2004-07-26 23:42 UTC	Modified:	2004-10-09 11:42 UTC
From:	AxelLuttgens at swing dot be	Assigned:
Status:	Closed	Package:	Reproducible crash
PHP Version:	4.3.8	OS:	Mac OS 10.3.4
Private report:	No	CVE-ID:	None

View Add Comment Developer Edit

[2004-07-26 23:42 UTC] AxelLuttgens at swing dot be

Description:
------------
It took me a long time to locate the source of seemingly random crashes I was experiencing these days.

But I now believe to have found a very clean example of crashing code on my system.
Of course, my real code handles more interesting strings than the one used in the example ;-)

This could help to explain some other bug reports related to unserialize(), but that remained rather elusive or without a clear conclusion.

Could also be related to another note of mine (Bug #26078).

HTH,
Axel

Reproduce code:
---------------
<?php
	$str = chr(236);
	print_r(unserialize($str));
?>



Expected result:
----------------
According to the docs, I would have expected unserialize() to return FALSE, as the input string clearly doesn't result from a prior serialize().

Actual result:
--------------
Here follows an excerpt of the resulting crash log:

	Date/Time:      2004-07-26 17:56:11 +0200
	OS Version:     10.3.4 (Build 7H63)
	Report Version: 2
	
	Command: httpd
	Path:    /usr/sbin/httpd
	PID:     1237
	Thread:  0
	
	Exception:  EXC_BAD_ACCESS (0x0001)
	Codes:      KERN_PROTECTION_FAILURE (0x0002) at 0x00000002
	
	Thread 0 Crashed:
	0   libphp4.so 	0x020eccc8 php_var_unserialize + 0x180 (var_unserializer.c:320)
	1   libphp4.so 	0x020e5418 zif_unserialize + 0xa4 (var.c:681)
	2   libphp4.so 	0x0214bc68 execute + 0x1b58 (zend_execute.c:1635)
	3   libphp4.so 	0x0213db34 zend_execute_scripts + 0xd8 (zend.c:892)
	4   libphp4.so 	0x02113064 php_execute_script + 0x258 (main.c:1736)
	5   libphp4.so 	0x0214f958 apache_php_module_main + 0xb8 (sapi_apache.c:59)
	6   libphp4.so 	0x02150618 send_php + 0x294 (mod_php4.c:623)
	7   httpd      	0x0000d05c ap_invoke_handler + 0xe8
	[...]

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports

[2004-07-27 02:10 UTC] 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

[2004-07-27 17:09 UTC] 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 18:48 UTC] iliaa@php.net

Please leave at feedback until more information is 
available.

[2004-07-28 16:52 UTC] 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-10-04 04:22 UTC] 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-10-09 11:42 UTC] AxelLuttgens at swing dot be

Thanks a lot for the follow-up.

Sincerely,
Axel

	php.net \| support \| documentation \| report a bug \| advanced search \| search howto \| statistics \| random bug \| login
go to bug id or search bugs for


Copyright © 2001-2024 The PHP Group All rights reserved.	Last updated: Fri May 17 21:01:33 2024 UTC