Fixed bug (applied upstream patch for CVE-2016-1283).

It was discovered that pcrecompile function in pcrecompile.c in PCRE before 8.38 mishandles certain [: nesting, which allows remote attackers to cause a denial of service (CPU consumption) or possibly have unspecified other impact via a crafted regular expression.

The compilebranch function in pcrecompile.c in PCRE 8.x before 8.39 and pcre2compile.c in PCRE2 before 10.22 mishandles patterns containing an (ACCEPT) substring in conjunction with nested parentheses, which allows remote attackers to execute arbitrary code or cause a denial of service (stack-based buffer overflow) via a crafted regular expression, as demonstrated by a JavaScript RegExp object encountered by Konqueror, aka ZDI-CAN-3542.

Heap-based buffer overflow in PCRE 8.34 through 8.37 and PCRE2 10.10 allows remote attackers to execute arbitrary code via a crafted regular expression, as demonstrated by /^(?P=B)((?P=B)(?J:(?P<B>c)(?P<B>a(?P=B)))>WGXCREDITS)/, a different vulnerability than CVE-2015-8384.

Heap-based buffer overflow in the findfixedlength function in pcrecompile.c in PCRE before 8.38 allows remote attackers to cause a denial of service (crash) or obtain sensitive information from heap memory and possibly bypass the ASLR protection mechanism via a crafted regular expression with an excess closing parenthesis.

In PCRE 8.41, the OPKETRMAX feature in the match function in pcreexec.c allows stack exhaustion (uncontrolled recursion) when processing a crafted regular expression.

The compilebranch function in PCRE before 8.37 allows context-dependent attackers to compile incorrect code, cause a denial of service (out-of-bounds heap read and crash), or possibly have other unspecified impact via a regular expression with a group containing a forward reference repeated a large number of times within a repeated outer group that has a zero minimum quantifier.

PCRE before 8.36 mishandles the /((?(R)a|(?1)))+/ pattern and related patterns with certain recursion, which allows remote attackers to cause a denial of service (segmentation fault) or possibly have unspecified other impact via a crafted regular expression, as demonstrated by a JavaScript RegExp object encountered by Konqueror.

PCRE 7.8 and 8.32 through 8.37, and PCRE2 10.10 mishandle group empty matches, which might allow remote attackers to cause a denial of service (stack-based buffer overflow) via a crafted regular expression, as demonstrated by /^(?:(?(1)\\.|([^\\\\W])?)+)+$/.

Heap-based buffer overflow in pcrecompile.c in the Perl-Compatible Regular Expression (PCRE) library 7.7 allows context-dependent attackers to cause a denial of service (crash) or possibly execute arbitrary code via a regular expression that begins with an option and contains multiple branches.

Buffer overflow in PCRE before 7.6 allows remote attackers to execute arbitrary code via a regular expression containing a character class with a large number of characters with Unicode code points greater than 255.

The pcrecompile2 function in PCRE before 8.37 allows context-dependent attackers to compile incorrect code and cause a denial of service (out-of-bounds read) via regular expression with a group containing both a forward referencing subroutine call and a recursive back reference, as demonstrated by "((?+1)(\1))/".

DISPUTED In PCRE 8.41, after compiling, a pcretest load test PoC produces a crash overflow in the function match() in pcreexec.c because of a self-recursive call. NOTE: third parties dispute the relevance of this report, noting that there are options that can be used to limit the amount of stack that is used.

Heap buffer overflow issue was reported in PCRE when processing a specially crafted regular expressions: http://bugs.exim.org/showbug.cgi?id=1546

Upstream patch for this: http://www.exim.org/viewvc/pcre2?view=rev&revision=154

The next upstream release that will contain the above fix is likely to be around Feb/Mar next year (2015).

A denial of service flaw was found in the way syslog-ng processed certain log patterns, when 'global' flag was speficied and PCRE backend was used for matching. A remote attacker could use this flaw to cause excessive memory use by the syslog-ng process via specially-crafted pattern.

References: [1] http://www.securityfocus.com/bid/47800/info [2] https://lists.balabit.hu/pipermail/syslog-ng/2011-May/016576.html

Upstream patch: [3] http://git.balabit.hu/?p=bazsi/syslog-ng-3.2.git;a=commit;h=09710c0b105e579d35c7b5f6c66d1ea5e3a3d3ff

CVE-2006-7224 initially described several integer overflows in pcre, all described here: http://scary.beasts.org/security/CESA-2007-006.html

This id should be used to describe issue #2 in that advisory:

3) More possible integer overflow trouble.

pcrecompile: --- if (min == 0) { length++; if (max > 0) length += (max - 1) (duplength + 3 + 2LINKSIZE); } ... else { length += (min - 1) duplength; if (max > min) / Need this test as max=-1 means no limit / length += (max - min) (duplength + 3 + 2LINKSIZE) - (2 + 2LINKSIZE); } ---

In both these cases, I see no reason why a malicious regexp pattern couldn't cause an integer overflow by using large min / max / duplength values. This will really mess up the critical "length" value.

CVE-2006-7224 initially described several integer overflows in pcre, all described here: http://scary.beasts.org/security/CESA-2007-006.html

This id should be used to describe issue #1 in that advisory:

1) Integer overflow leading to buffer overflow.

pcrecompile: --- / Compute the size of data block needed and get it, either from malloc or externally provided function. /

size = length + sizeof(realpcre) + namecount (maxnamesize + 3); re = (realpcre )(pcremalloc)(size); ---

Unfortunately, a malicious regex can easily cause large "namecount" and "maxnamesize" such that this calculation overflows. Demo:

(?P)(?P<0>)(?P<1>)...fill in this sequence...(?P<4293>)

CVE-2006-7224 initially described several integer overflows in pcre, all described here: http://scary.beasts.org/security/CESA-2007-006.html

This id should be used to describe issue #2 in that advisory:

2) Uncharacterized crash researching item #1 above: Demo:

(?P<0>)(?P<1>)...fill in this sequence...(?P<3999>)

This does not trigger the integer overflow present in #1 above, but still crashes with a serious-looking memory error of some kind - possibly a buffer overflow.

Tavis Ormandy of the Google Security Team reported multiple pcre regular expressions flaws. Here are the details pasted from Tavis' mail:

CVE-2007-1660: multiple forms of character class had their sizes miscalculated on initial passes, resulting in too little memory being allocated, this was also inadvertently fixed in version 7.0, where the compile phase was entirely re-engineered (and much improved, from a security standpoint).

Acknowledgements:

Red Hat would like to thank Tavis Ormandy and Will Drewry for properly disclosing these issues.

PCRE is a Perl-compatible regular expression library.Flaws were discovered in the way PCRE handles certain malformed regularexpressions. If an application linked against PCRE parses a maliciousregular expression, it may have been possible to run arbitrary code as theuser running the application. (CVE-2006-7228, CVE-2007-1660)Users of PCRE are advised to upgrade to these updated packages, whichcontain backported patches to resolve these issues.Red Hat would like to thank Ludwig Nussel for reporting these issues.

PCRE is a Perl-compatible regular expression library.Flaws were discovered in the way PCRE handles certain malformed regularexpressions. If an application linked against PCRE, such as Konqueror,parsed a malicious regular expression, it may have been possible to runarbitrary code as the user running the application. (CVE-2006-7228,CVE-2007-1660)Users of PCRE are advised to upgrade to these updated packages, whichcontain backported patches to resolve these issues.Red Hat would like to thank Ludwig Nussel for reporting these issues.