Hi, the following vulnerabilities were published for pcre: 1) heap buffer overflow in pcre_compile2() / compile_regex() Latest version of PCRE is prone to a Heap Overflow vulnerability which could caused by the following regular expression. /^(?P=B)((?P=B)(?J:(?P<B>c)(?P<B>a(?P=B)))>WGXCREDITS)/ To reproduce the problem, we could use pcretest provide by PCRE library or applications which is wrapped with PCRE such as PHP. Information: https://bugs.exim.org/show_bug.cgi?id=1636 CVE: CVE-2015-3210 2) PCRE Library Call Stack Overflow Vulnerability in match() Latest version of PCRE is prone to a Stack Overflow vulnerability which could caused by the following regular expression. /^(?:(?(1)\\.|([^\\\\W_])?)+)+$/ To reproduce the problem, we could use pcretest provide by PCRE library or applications which is wrapped with PCRE such as PHP. Information: https://bugs.exim.org/show_bug.cgi?id=1638 CVE: CVE-2015-3217 3) PCRE Library Stack Overflow Vulnerability (1) PCRE library is prone to a vulnerability which leads to Stack Overflow. Without enough bound checking inside compile_regex(), the stack memory could be overflowed via a crafted regular expression. Since PCRE library is widely used, this vulnerability should affect many applications. An attacker may exploit this issue to execute arbitrary code in the context of the user running the affected application. Information: https://bugs.exim.org/show_bug.cgi?id=1503 CVE-Request: http://www.openwall.com/lists/oss-security/2015/05/31/5 4) PCRE Library Stack Overflow Vulnerability (2) PCRE library is prone to a vulnerability which leads to Stack Overflow. Without enough bound checking inside compile_regex(), the stack memory could be overflowed via a crafted regular expression. Since PCRE library is widely used, this vulnerability should affect many applications. An attacker may exploit this issue to DOS the user running the affected application. Information: https://bugs.exim.org/show_bug.cgi?id=1515 CVE-Request: http://www.openwall.com/lists/oss-security/2015/05/31/4 Reproducible: Always
Thanks for the report, as far as I can see there has been no single release fixing all issues yet, but there are some possible patches referenced in the various bug reports in the initial report that can possibly backported so setting an upstream/ebuild status
Summary for maintainer(s): Upstream bug 1636 (CVE-2015-3210) is fixed in the source repo. Upstream bug 1638 (CVE-2015-3217) is fixed in 10.10 Upstream bug 1503 (CVE N/A) is fixed in 8.35 Upstream bug 1515 (CVE N/A) is fixed in 8.35
FYI, I have a test ebuild of libpcre2-10.10 in poly-c overlay. I can add it to the tree if necessary.
Looks like 8.38 won't be released in the next days. Can somebody please release dev-libs/libpcre-8.37-r2 with https://svnweb.freebsd.org/ports?view=revision&revision=388777 ? FreeBSD took this road already, see https://svnweb.freebsd.org/ports/head/devel/pcre/Makefile?view=log
Another one: Title: PCRE Library Heap Overflow Vulnerability in find_fixedlength() PCRE library is prone to a vulnerability which leads to Heap Overflow. During subpattern calculation of a malformed regular expression, an offset that is used as an array index is fully controlled and can be large enough so that unexpected heap memory regions are accessed. One could at least exploit this issue to read objects nearby of the affected application's memory. Such information disclosure may also be used to bypass memory protection method such as ASLR. Upstream bug: https://bugs.exim.org/show_bug.cgi?id=1651 Fix: http://vcs.pcre.org/pcre?diff_format=l&view=revision&revision=1571 CVE: CVE-2015-5073 (http://www.openwall.com/lists/oss-security/2015/06/26/3)
CVE-2015-5073 is tracked in bug 553300 already
looking through the upstream svn for libpcre and redhat's bugzilla, it doesn't seem like a fix is needed for CVE-2015-3217 in the older code base. only in the newer libpcre2 was a fix deployed. if that turns out to not be the case, we can file/track in a new bug.
Commit message: Add backport from upstream for CVE-2015-3210 http://sources.gentoo.org/dev-libs/libpcre/files/libpcre-8.37-CVE-2015-3210.patch?rev=1.1 http://sources.gentoo.org/dev-libs/libpcre/libpcre-8.37-r2.ebuild?rev=1.1
So we are still missing http://vcs.pcre.org/pcre?diff_format=l&view=revision&revision=1555 http://vcs.pcre.org/pcre?diff_format=l&view=revision&revision=1556 http://vcs.pcre.org/pcre?diff_format=l&view=revision&revision=1557 http://vcs.pcre.org/pcre?diff_format=l&view=revision&revision=1559 http://vcs.pcre.org/pcre?diff_format=l&view=revision&revision=1560 http://vcs.pcre.org/pcre?diff_format=l&view=revision&revision=1561 At least 4/6 commit messages contain "buffer overflow".
(In reply to Thomas D. from comment #9) it makes no sense to backport every single revision. this bug is specifically about CVE-2015-3210 which is now fixed. i don't want this to explode into analyzing/tracking each upstream commit.
Setting depend to 553300 for stabilization
Arches and Maintainer(s), Thank you for your work. Cleanup as part of Bug 553300 Added to an existing GLSA Request.
This issue was resolved and addressed in GLSA 201607-02 at https://security.gentoo.org/glsa/201607-02 by GLSA coordinator Aaron Bauman (b-man).
