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 Developer Edit

Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If you forgot your password, you can retrieve your password here.

Password:

Status:
Package:
Bug Type:
Summary:
From:	AxelLuttgens at swing dot be
New email:
PHP Version:		OS:

New Comment:

[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

Pull Requests

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-2025 The PHP Group All rights reserved.	Last updated: Thu Jul 10 18:01:34 2025 UTC