Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sat, 24 Jan 2015 14:28:51 -0500 (EST)
Subject: Re: CVE Request: PHP

Hash: SHA1

> Date: Thu, 08 Jan 2015 22:11:09 +1100
> I'm requesting multiple CVE-ID's for multiple vulnerabilities in PHP
> that I found:

> Use after free in 'opcache' component of PHP

Use CVE-2015-1351.

(requests 2 and 3 are skipped because of the post)

> Null Pointer Dereference in pgsql

Use CVE-2015-1352 for this issue in which a return value isn't

> Null Pointer Dereference in ereg(regex)

Because of an unusual process step on MITRE's end, there was also some
communication about these bugs that was only between MITRE and Joshua
Rogers, without a Cc to oss-security. For Bug #68740, the additional
discussion sent to us was (more or less) was that code in between
lines 140 and 167 wouldn't change g->setbits to a non-NULL value. This
is also essentially implied by the reasoning used in the Description
section of Bug #68740. (We didn't want to send the private e-mail
here, but Joshua Rogers is free to send it if he wants.)

MITRE doesn't have a full code analysis and isn't confident about
whether the "explicit null dereference" exists or not. All we can
offer is that the "wouldn't change g->setbits to a non-NULL value"
seems somewhat implausible because it means that significant intended
functionality of the code wouldn't have worked at all.

As an example, this sequence of function calls seems possible:

  p_str - ordinary - bothcases - p_bracket - allocset

where allocset contains:

  p->g->setbits = (uch *)malloc(nbytes);
and a memset (and the code before the line-140 "g->setbits = NULL"
includes a "p->g = g").

We're going to defer a CVE assignment for Bug #68740 until someone
outside MITRE offers additional analysis. It might be worthwhile to
update Bug #68740 so that the "explicit null dereference" term isn't
used. Although maybe a code path with a NULL pointer dereference can
be found, it's apparently not the case that g->setbits is explicitly
guaranteed to be NULL on line 1279.

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


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.