php: multiple vulnerabilities (CVE-2015-6834, CVE-2015-6835, CVE-2015-6836, CVE-2015-6837, CVE-2015-6838)
The CVE IDs in this message apply to PHP before 5.4.45, 5.5.x before 5.5.29, and 5.6.x before 5.6.13.
https://bugs.php.net/bug.php?id=70172 Use After Free Vulnerability in
unserialize()
Given attacker input to unserialize() we should consider this a security
issue.
https://bugs.php.net/bug.php?id=70365 yet another use-after-free
vulnerability in unserialize() with SplObjectStorage
I would also say this can be attacker driven, so needs a CVE.
https://bugs.php.net/bug.php?id=70366 yet another use-after-free
vulnerability in unserialize() with SplDoublyLinkedL
Same.
Use CVE-2015-6834 for this set of taoguangchen () icloud com
use-after-free discoveries. Note that the scope of CVE-2015-6834 does
not include any subsequent work on these bugs after the release of
5.6.13. For example, 70172 has an apparently pending “2015-09-04
08:50” comment. The code as shipped in 5.6.13 has ext/standard/var.c
with:
var_push_dtor_no_addref(&var_hash, &return_value);
/* FIXME: old_rval is not freed in some scenarios, see bug #70172
var_push_dtor_no_addref(&var_hash, &old_rval); */
https://bugs.php.net/bug.php?id=70219 Use after free vulnerability in
session deserializer
Same.
Our feeling is that this discovery is somewhat specific to the
implementation details of session_decode, and that the use-after-free
is resultant. Use CVE-2015-6835. Also, note the “2015-08-17 01:07”
comment of “Also I understand that this requires control over the
session content, which for most applications would mean the security is
already overridden, as session usually contains all security data.”
https://bugs.php.net/bug.php?id=70388 SOAP serialize_function_call() type confusion / RCE Definitely, even the summary has enough indication for me.
Use CVE-2015-6836 for this andrea.palazzo () truel it discovery.
https://bugs.php.net/bug.php?id=69782 NULL pointer dereference Denial of service, these queries might be fed from remote.
It appears that some copies of ext/xsl/xsltprocessor.c have one of the
cases fixed, but not the other. We would like to assign, and maintain,
two separate CVE IDs for this, regardless of ultimate cause. The PHP
5.6.13 release has a check for a NULL return value both in the “if
(error 1)" code block and on the later "if (obj NULL ||
obj->stringval == NULL)” line. However, the current
http://git.php.net/?p=php-src.git;a=blob;f=ext/xsl/xsltprocessor.c code
(i.e.,
http://git.php.net/?p=php-src.git;a=blob;f=ext/xsl/xsltprocessor.c;h=ee52336c4ebd46b2a42046a00b938dcff5461308;hb=HEAD)
has the former but not the latter.
Use CVE-2015-6837 for the vulnerability fixed by the:
- xmlXPathFreeObject(obj);
+
- if (obj) {
- xmlXPathFreeObject(obj);
- }
patch.
Use CVE-2015-6838 for the vulnerability fixed by the:
- if (objstringval NULL) {
-
php\_error\_docref(NULL, E\_WARNING, "Handler name must be a string");
-
xmlXPathFreeObject(obj);
- if (obj NULL || obj>stringval NULL) {
-
if (obj && obj->stringval NULL) {
- php_error_docref(NULL, E_WARNING, “Handler name must be a string”);
- xmlXPathFreeObject(obj);
- }
patch.
(Also, neither copy of the code made a change related to “obj =
valuePop(ctxt); switch (obj->type)” — if this is a remaining
vulnerability, it would have its own CVE ID.)
Perhaps CVEs also for:
https://bugs.php.net/bug.php?id=70385 Buffer over-read in
exif_read_data with TIFF IFD tag byte value of 32 bytes
Questionable. It seems no crash was observed, so no denial of service.
At most a information leak.
It says “potential data leak” but there’s no example of a plausible PHP application in which a client user may obtain private information.
https://bugs.php.net/bug.php?id=70312 HAVAL gives wrong hashes in
specific cases
Questionable. I am not sure this is attacker driveable or if an attacker
could do anything with this.
This might be primarily an interoperability bug. 70312 doesn’t attempt
to show that the hashes produced by PHP’s HAVAL implementation had
weaker security properties than those produced by a correct
implementation. (One might also argue that applications requiring
especially good hash properties should not be using HAVAL at all.)
https://bugs.php.net/bug.php?id=70345
Various PCRE issues caused by the regexp string. There has been a tendency to either declare this CVE worthy or declare that its not attacker driven usually.
There is related discussion at the end of the http://www.openwall.com/lists/oss-security/2015/03/11/8 post. A regular expression can be untrusted input from an attacker, but in a typical PHP application it is not. Also, 70345 doesn’t have much impact analysis beyond “exploitation to achieve arbitrary code execution might be possible, but not trivial.” In addition, there is an overlap with the security fixes available in the unreleased PCRE 8.38 (see the http://vcs.pcre.org/pcre/code/trunk/ChangeLog?view=markup page).
Reference:
(from redmine: issue id 4622, created on 2015-09-09, closed on 2015-09-10)
- Relations:
- child #4623 (closed)
- child #4624 (closed)
- child #4625 (closed)
- child #4626 (closed)