Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Tue,  8 Sep 2015 13:45:53 -0400 (EDT)
Subject: Re: CVE Request: PHP remote exploits (even more)

Hash: SHA256

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.

>   Use After Free Vulnerability in unserialize()
>                 Given attacker input to unserialize() we should consider this a security issue.

>   yet another use-after-free vulnerability in unserialize() with SplObjectStorage
>                 I would also say this can be attacker driven, so needs a CVE.
>   yet another use-after-free vulnerability in unserialize() with SplDoublyLinkedL
>                 Same.

Use CVE-2015-6834 for this set of
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

   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); */

>   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."

>   SOAP serialize_function_call() type confusion / RCE
>                 Definitely, even the summary has enough indication for me.

Use CVE-2015-6836 for this discovery.
>   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;a=blob;f=ext/xsl/xsltprocessor.c
code (i.e.,;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);
  +      }


Use CVE-2015-6838 for the vulnerability fixed by the:
  -   if (obj->stringval == 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);
  +      }


(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:
>   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.

>   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.)

>         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 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 page).

- -- 
CVE assignment team, MITRE CVE Numbering Authority
M/S M300
202 Burlington Road, Bedford, MA 01730 USA
[ PGP key available through ]
Version: GnuPG v1


Powered by blists - more mailing lists

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.