Edit report at https://bugs.php.net/bug.php?id=73900&edit=1
ID: 73900
Updated by: [email protected]
Reported by: rossa dot milan at gmail dot com
Summary: Use After Free in unserialize() SplFixedArray
Status: Assigned
-Type: Security
+Type: Bug
Package: SPL related
Operating System: ALL
PHP Version: 7.*
Assigned To: nikic
Block user comment: N
Private report: Y
Previous Comments:
------------------------------------------------------------------------
[2017-04-03 21:11:57] [email protected]
Well, in both cases it requires specially crafted code, so unless I hear objections soon I will reclassify it.
------------------------------------------------------------------------
[2017-04-02 11:56:59] [email protected]
Stas - the reverse is actually true :)
(if it's related to unserialize, then it's not a security issue!)
------------------------------------------------------------------------
[2017-03-31 23:57:58] [email protected]
If it's not related to unserialize I assume it's not a security issue?
------------------------------------------------------------------------
[2017-03-30 20:42:25] [email protected]
Here is a patch against master which fixes the issue: https://gist.github.com/nikic/79b9b55d325373d4b39903a82027064e
------------------------------------------------------------------------
[2017-03-30 20:29:28] [email protected]
The use of unserialize() here is a red herring -- what is actually causing the memory errors is the attempt to acquire a reference into the SplFixedArray. A reduced reproduce script is the following (run under valgrind):
<?php
$a = new stdClass;
$b = new SplFixedArray(1);
$b[0] = $a;
$c = &$b[0];
As such, I do not believe this qualifies as a security issue under https://wiki.php.net/security: The issue cannot be triggered through user input. Instead, what triggers the issue is specific and atypical local code, namely the "$c = &$b[0]" line (it is atypical because ArrayAccess objects do not support references).
I believe the cause of this issue is the code at https://github.com/php/php-src/blob/f07e4c033cf4edda8dcbf14c5a964e4d283fa8a8/Zend/zend_execute.c#L1637, which seems to assume that result is already in retval (which happens to be the case for non-internal implementations of offsetGet()).
------------------------------------------------------------------------
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
https://bugs.php.net/bug.php?id=73900
--
Edit this bug report at https://bugs.php.net/bug.php?id=73900&edit=1
lmpx.com only provides a reader for public news (NNTP) servers. It is not
affiliated with the servers or forums shown here and is not responsible for
the content of articles, which is written by their respective authors.