Re: CVE Request: PHP remote exploits (even more)

[cve-assign () mitre org]

-----BEGIN PGP SIGNED MESSAGE-----
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.


>         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 (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);
  +      }

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

- -- 
CVE assignment team, MITRE CVE Numbering Authority
M/S M300
202 Burlington Road, Bedford, MA 01730 USA
[ PGP key available through http://cve.mitre.org/cve/request_id.html ]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBCAAGBQJV7xy6AAoJEL54rhJi8gl5pxYP+wQBwYyvuTbVMDi7pPoyMJjI
I6h2kkEDQ7GxE6Tc5kC9wF2AeyWcNbs5/PuBzAIcKr7YCaRuxX/tlHqZ68gYmlwN
q1vUGOM23InUSuIFYz0em9vXAw22Y1sujKZRj00v2R2/dxi1vonJehVdXM9ft5cu
zx6v63oLe23loLrHNVID9IcAAwnBPmB8aa1m3fGx5vbbL35CPzXR8rNLeWjG++JP
CMYlRQdCMnCPiT9gH5EqwABjwP/NDvh0gKYZM25KQ2GaUkRNHYFQOKNAdB/KAEys
fhyYtfYhUS7rwBfQ0cU6nmZm1AeGoZ7o0/I4jgT/ANiYDfRFYsIEuAwIM+ubumpl
JtrI6ocDySZVvAC2yh+n9z1jAuJw8lsSSaNy+8fD/JdDJ080OXEYSJ8e81pMFbde
Ngj282U8M+n8P9FueP61O0U5jbHwlKxhCyXmVePuiB8xf8JYRD+OMWxBXbRtzSCC
lo7GbaHrzk6q70rQdEFxZWk+6CCPmNP9iNxPCZSvYhq62Nbh3Vh4LiqB9bIk1PVV
6NN+uXiaBvH+OUNpA96HaG913fGhE3SzPbqY+fCSj+QOPUf/ZjEf1J6fa9GiMuxU
GFFqzKTLTwhW8IQqFYQ86dYBFt2+fUUSltWPuxSoMsbOn1ChC2OThgC6xfCmYOqt
yClKtAjpIOMDRaivspjp
=ha5T
-----END PGP SIGNATURE-----