Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sat, 28 Nov 2015 23:01:03 -0500 (EST)
Subject: Re: Heap Overflow in PCRE

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. 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 but we're
still unaware of any specific application that meets this requirement
(the closest we found was
Also, these PCRE problems are not the same as a "regex injection"
problem within an application (see IDS08-J on the 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


This report relates to the PCRE changelog:

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

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

Finally, here are two other PCRE issues that have been discussed on
oss-security recently:

 - (this is changelog item
   1 in 8.37)

 - [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 ]
Version: GnuPG v1


Powered by blists - more mailing lists

Your e-mail address:

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

Powered by Openwall GNU/*/Linux - Powered by OpenVZ