Hide Forgot
** DISPUTED ** In PCRE 8.41, after compiling, a pcretest load test PoC produces a crash overflow in the function match() in pcre_exec.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. References: http://www.openwall.com/lists/oss-security/2017/11/01/11 http://www.openwall.com/lists/oss-security/2017/11/01/3 http://www.openwall.com/lists/oss-security/2017/11/01/7 http://www.openwall.com/lists/oss-security/2017/11/01/8 https://seclists.org/oss-sec/2017/q4/164 https://seclists.org/fulldisclosure/2018/Dec/33 https://bugs.exim.org/show_bug.cgi?id=2047 POC: https://github.com/followboy1999/poc/tree/master/CVE-2017-16231 https://packetstormsecurity.com/files/150897/PCRE-8.41-Buffer-Overflow.html
Created mingw-pcre tracking bugs for this issue: Affects: epel-7 [bug 1700395] Affects: fedora-28 [bug 1700393] Affects: fedora-29 [bug 1700394]
This is a known feature of any recursive algorithm that process an untrusted input. A user can limit a recursion limit or increase a stack size. Upstream always rejects these stack-exhausted bugs as this is a limitation of the architecture.
This vulnerability is out of security support scope for the following products: * Red Hat Enterprise Application Platform 6 * Red Hat Enterprise Application Platform 5 Please refer to https://access.redhat.com/support/policy/updates/jboss_notes for more details.
Analyzing the pcre code it's possible to notice it have a few ways to control and limit the recursion depth on match() function: 1) The caller from pcre_exec() can limit its stack usage via rlimit related calls; 2) There's a default built-in max recursion depth on pcre; 3) The caller can set the max recursion depth via pcre configuration calls from its API; Although the default built-in max depth may not be enough to avoid stack overflow there's still other two ways to avoid it. Given the information above it doesn't seems a security issue on pcre.
Statement: Red Hat Product Security determined that this flaw was not a security vulnerability. See the Bugzilla link for more details.