Fixed bug (AddressSanitizer: negative-size-param (-1) in mbflstrcut). (CVE-2016-4073)

An invalid write vulnerability causing segmentation fault in phar on filename with \0 inside its name was found.

Vulnerable code (pharanalyzepath):

if (!(realpath = expandfilepath(filename, NULL))) { efree(filename); return FAILURE; } #ifdef PHPWIN32 pharunixifypathseparators(realpath, strlen(realpath)); #endif slash = strstr(realpath, filename); if (slash) { slash += ((ext - fname) + extlen); slash = '\0'; }

If fname and thus filename contain \0's, realpath would not contain those parts and thus slash would point past the end of the realpath buffer.

To exploit this, application has to allow attacker to create phar files with arbitrary filenames.

Upstream bug:

https://bugs.php.net/bug.php?id=71860

Upstream patch:

https://gist.github.com/smalyshev/80b5c2909832872f2ba2 https://git.php.net/?p=php-src.git;a=commit;h=1e9b175204e3286d64dfd6c9f09151c31b5e099a

The following issue was reported in PHP:

PHP process crashes when processing an invalid file with the "phar" extension.

CVE assignment: http://seclists.org/oss-sec/2015/q3/147 Upstream bug: https://bugs.php.net/bug.php?id=69958 Upstream commit: http://git.php.net/?p=php-src.git;a=commit;h=bf58162ddf970f63502837f366930e44d6a992cf

A format string vulnerability was found in phpsnmperror() in ext/snmp/snmp.c, possibly leading to code execution. snmpobject->snmperrstr is passed directly to zendthrowexceptionex() without a "%s".

Upstream bug:

https://bugs.php.net/bug.php?id=71704

Upstream patch:

https://git.php.net/?p=php-src.git;a=commit;h=6e25966544fb1d2f3d7596e060ce9c9269bbdcf8

Last updated 24 July 2024

Multiple use-after-free vulnerabilities in PHP before 5.4.45, 5.5.x before 5.5.29, and 5.6.x before 5.6.13 allow remote attackers to execute arbitrary code via vectors related to (1) the Serializable interface, (2) the SplObjectStorage class, and (3) the SplDoublyLinkedList class, which are mishandled during unserialization.

A use-after-free vulnerability was found in session deserializer. When session deserializer (php/phpbinary) is deserializing multiple data, it will call phpvarunserialize() multiple times. We can create ZVAL and free it via the phpvarunserialize() with a crafted serialized string. Then the next call phpvarunserialize() will still allow to use R: or r: to set references to that already freed memory. It is possible to use-after-free attack and execute arbitrary code remotely.

Upstream report:

https://bugs.php.net/bug.php?id=70219

Upstream patch:

http://git.php.net/?p=php-src.git;a=commitdiff;h=df4bf28f9f104ca3ef78ed94b497859f15b004e5

The SoapClient implementation in PHP before 5.4.40, 5.5.x before 5.5.24, and 5.6.x before 5.6.8 allows remote attackers to cause a denial of service (application crash) or possibly execute arbitrary code via an unexpected data type, related to "type confusion" issues in the (1) SoapClient::getLastRequest, (2) SoapClient::getLastResponse, (3) SoapClient::getLastRequestHeaders, (4) SoapClient::getLastResponseHeaders, (5) SoapClient::getCookies, and (6) SoapClient::setCookie methods.

A type confusion issue was found in exception::getTraceAsString(). If a specially crafted input is unserialized, it could lead to information leak and possibly code execution.

The issue was reported upstream in:

https://bugs.php.net/bug.php?id=69152#1425357025

and was corrected in:

http://git.php.net/?p=php-src.git;a=commitdiff;h=a894a8155fab068d68a04bf181dbaddfa01ccbb0

See also bug 1222538 comment 7.

A type confusion issue was found in the way PHP performed unserialization of incomplete class. If a specially crafted input is unserialized, it could lead to information leak and possibly code execution.

The issue was reported upstream in:

https://bugs.php.net/bug.php?id=69152#1426863482

and was corrected in:

http://git.php.net/?p=php-src.git;a=commitdiff;h=fb83c76deec58f1fab17c350f04c9f042e5977d1

See also bug 1222538 comment 7.

PHP versions 5.4.40, 5.5.24, and 5.6.8 provide a fix for type confusion vulnerability in unserialize() function used on a various SOAP methods.

Copy-paste description of the issue from the upstream bug: """ PHPMETHOD(SoapFault, toString) { ... faultcode = zendreadproperty(soapfaultclassentry, thisptr, "faultcode", sizeof("faultcode")-1, 1 TSRMLSCC); faultstring = zendreadproperty(soapfaultclassentry, thisptr, "faultstring", sizeof("faultstring")-1, 1 TSRMLSCC); file = zendreadproperty(soapfaultclassentry, thisptr, "file", sizeof("file")-1, 1 TSRMLSCC); line = zendreadproperty(soapfaultclassentry, thisptr, "line", sizeof("line")-1, 1 TSRMLSCC); ... len = spprintf(&str, 0, "SoapFault exception: [%s] %s in %s:%ld\nStack trace:\n%s", ZSTRVALP(faultcode), ZSTRVALP(faultstring), ZSTRVALP(file), ZLVALP(line), ZSTRLENP(trace) ? ZSTRVALP(trace) : "#0 {main}\n");

zvalptrdtor(&trace);

RETURNSTRINGL(str, len, 0); ｝

The ZSTRVALP macro lead to looking up an arbitrary valid memory address, and return a string via a integer-type zval that start from this memory address. If the memory address is an invalid memory position, it should result in a crash. The ZLVALP macro lead to leaking memory address via a string-type zval that string value stored.

The following code should leak arbitrary memory or crash PHP:

<?php

$data = 'O:9:"SoapFault":4:{s:9:"faultcode";i:4298448493;s:11:"faultstring";i:4298448543;s:7:"'."\0\0".'file";i:4298447319;s:7:"'."\0\0".'line";s:4:"ryat";}'; echo unserialize($data);

?>

Result (Test on standard MacOSX 10.10.2 installation of PHP 5.6.6.):

SoapFault exception: [UH??AWAVSPI??I??H???? in UH??AWAVAUATSH???:4307253992 ] UH??SPD????????t"H? Stack trace: #0 test.php(4): unserialize('O:9:"SoapFault"...') #1 {main} """

Upstream bug: https://bugs.php.net/bug.php?id=69152

Upstream commits: http://git.php.net/?p=php-src.git;a=commitdiff;h=0c136a2abd49298b66acb0cad504f0f972f5bfe8 http://git.php.net/?p=php-src.git;a=commitdiff;h=51856a76f87ecb24fe1385342be43610fb6c86e4 http://git.php.net/?p=php-src.git;a=commitdiff;h=fb83c76deec58f1fab17c350f04c9f042e5977d1