[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sat, 28 Nov 2015 23:01:03 -0500 (EST)
From: cve-assign@...re.org
To: hanno@...eck.de
Cc: cve-assign@...re.org, oss-security@...ts.openwall.com
Subject: Re: Heap Overflow in PCRE
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
This is a somewhat complex situation for several reasons, including
previously assigned CVE IDs that may be related to duplicate
discoveries, and the nature of the findings themselves.
Most PCRE findings have a requirement that the attacker is able to
provide an arbitrary regular expression in a way that crosses a
privilege boundary.
http://www.pcre.org/current/doc/html/pcre2pattern.html implies that
this is relevant to the PCRE security model, i.e., the reference to
"applications that allow their users to supply patterns." We've
mentioned this before in
http://www.openwall.com/lists/oss-security/2015/09/08/8 but we're
still unaware of any specific application that meets this requirement
(the closest we found was http://stackoverflow.com/questions/2371445).
Also, these PCRE problems are not the same as a "regex injection"
problem within an application (see IDS08-J on the
securecoding.cert.org web site); they are cases where the legitimate
user is supposed to know what a regular expression is, and is expected
to construct a useful one. Accordingly, CVE IDs might have little
practical value.
Because mitigating the CVEs is rarely necessary, it might be reasonable
to restrict CVE ID assignments to cases with certain types of impacts.
Another factor that is relevant here is that some PCRE CVEs have been
based on information that wasn't public at the time of CVE ID
assignments.
> https://blog.fuzzing-project.org/29-Heap-Overflow-in-PCRE.html
This report relates to the PCRE changelog:
http://vcs.pcre.org/pcre/code/trunk/ChangeLog?view=markup
> Fuzzing the pcretest tool uncovered an input leading to a heap
> overflow in the function pcre_exec. This bug was found with
> the help of american fuzzy lop and address sanitizer.
> Upstream bug #1637
This seems to be changelog item 10 in 8.38.
> Apart from that a couple of other vulnerabilities found by
> other people have been fixed in this release:
> Heap overflow in compile_regex (bug #1667)
> Heap overflow in compile_regex (bug #1672)
Both of these seem to be changelog item 7 in 8.38.
> Stack overflow in compile_regex (bug #1515)
Another one from a similar time was bug #1503.
Although 8.38 has these fixed, it seems that they are earlier bugs
that were originally fixed in 8.36: 1503 is changelog item 19 in 8.36,
whereas 1515 is changelog item 20 in 8.36. MITRE happens to have
received multiple credible reports of discovering these issues. 1503
was assigned CVE-2015-2327 months ago, and 1515 was assigned
CVE-2015-2328 at the same time. These CVE IDs are used, at least, in:
http://www.fortiguard.com/advisory/FG-VD-15-010/
http://www.fortiguard.com/advisory/FG-VD-15-014/
Several other 8.38 changelog entries appear to meet an arbitrary
cutoff of impact specificity that might be reasonable for this type of
the-input-might-be-untrusted-but-usually-isn't scenario:
3, 4, 5, 6, 8, 18, 21, 22, 23, 27, 28, 31, 36
28 is unlike the others. A possible threat model is that "pcregrep -q"
is called from a CGI script, and the attacker is able to provide a
binary file in an attempt to learn details about what the script is
looking for. (This isn't expected to be very common, but may be more
common than an attacker who is able to provide an arbitrary regular
expression.)
Finally, here are two other PCRE issues that have been discussed on
oss-security recently:
- https://bugs.exim.org/show_bug.cgi?id=1537 (this is changelog item
1 in 8.37)
- https://bugs.php.net/bug.php?id=70345 [2015-08-25 11:10 UTC] says
"the PCRE dev does not consider this a bug. So it probably hasn't
been/won't be changed in PCRE."
We think what would be reasonable is for us to assign CVE IDs soon so
that there is coverage of all of the PCRE issues listed above, i.e.,
8.38 changelog items: 3, 4, 5, 6, 7, 8, 10, 18, 21, 22, 23, 27, 28, 31, 36
8.37 changelog item: 1
(It is possible that we may need to change the strategy for PCRE CVE
coverage in the future.) If there's something wrong -- especially if
1503 or 1515 wasn't fixed in 8.36 -- please let us know.
- --
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
iQIcBAEBCAAGBQJWWndbAAoJEL54rhJi8gl5Ki8QAMXLzwar3Bn+C8nCnU6WNgKg
QyeOOXjnDrXxUAFlw5SsMgKMecEPBLyXjav6Zr7d4b29VmvT3Y1lbiimXC1Funkd
dtT/UOlMmrWhcW8PvetbgS4YMc/YOIa+XDHoEka+fUafzEdXOQXilNH5xoMQJb0+
uoFNjrtoo/sXzG9tuuZ6NxGNsUrC3c/sdGboAImQWhFBG3pl98dHyJdIkURNVVaY
iYH+m+wDuija8tcq0U+sX7SKyh/gGOho07oYK7Cpe2grXQpbeEU+bhrTD4BL//SQ
f+hvXJMrdVUVdvd6/owMvDVOdGMN9WBq/+azRY3sN8de+nGxpNv3yy7NcDyScDQg
SUevQbp9WyPJWJOtvvB0Dsx9XL0EWgW0wMqBFx/35CtSxbgVwEJczd1T6sqDE3w7
6EUCmxirhjJFE+ppgr9Q17E4V5Jtsh3Wf7L+R8dVvRMMFmFvIjtqHmbAu9MkDukP
/trl//ApdrntKykhVxrkqROTmTS5OZX3nQ3G49VR+eAHwWXfHLIV09DXOi9YbEo6
efmaB1cLyN6C6vvLHewwytpFzLdjX9Mtd1mCaCETDCKd/m4ak425XHfQIVd9OOPv
gVsGSETPyI3wNyginhnqnUe9QY8ygI9Til9HSl58Q3zX3L+95ZGiTjICPagO1guL
MoiX6BkJiBSD+aCt3Olh
=HdYk
-----END PGP SIGNATURE-----
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.
