Bugzilla – Bug 1546
Heap buffer overflow in pcregrep
Last modified: 2014-11-20 16:02:10 GMT
echo "a" | /tmp/pcre-8.36/pcregrep "((?=(?(?=(?(?=(?(?=())))*))))){2}" - ================================================================= ==29857==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x61000000fb94 at pc 0x7faf416f0dc6 bp 0x7fff9c91d3b0 sp 0x7fff9c91d3a8 READ of size 1 at 0x61000000fb94 thread T0 #0 0x7faf416f0dc5 in match /tmp/pcre-8.36/pcre_exec.c:1410:9 #1 0x7faf416dfe35 in match /tmp/pcre-8.36/pcre_exec.c:1538:7 #2 0x7faf416e46de in match /tmp/pcre-8.36/pcre_exec.c:1399:7 #3 0x7faf416dfe35 in match /tmp/pcre-8.36/pcre_exec.c:1538:7 #4 0x7faf416ee260 in match /tmp/pcre-8.36/pcre_exec.c:983:9 #5 0x7faf416dcd49 in pcre_exec /tmp/pcre-8.36/pcre_exec.c:6923:8 #6 0x4a4580 in match_patterns /tmp/pcre-8.36/pcregrep.c:1449:10 #7 0x4a13ca in pcregrep /tmp/pcre-8.36/pcregrep.c:1679:11 #8 0x4a3624 in grep_or_recurse /tmp/pcre-8.36/pcregrep.c:2122:10 #9 0x49efbf in main /tmp/pcre-8.36/pcregrep.c:3251:13 #10 0x7faf405b7ec4 in __libc_start_main /build/buildd/eglibc-2.19/csu/libc-start.c:287 #11 0x4172a6 in _start (/tmp/pcre-8.36/.libs/lt-pcregrep+0x4172a6) AddressSanitizer can not describe address in more detail (wild memory access suspected). SUMMARY: AddressSanitizer: heap-buffer-overflow /tmp/pcre-8.36/pcre_exec.c:1410 match Shadow bytes around the buggy address: 0x0c207fff9f20: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c207fff9f30: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c207fff9f40: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c207fff9f50: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c207fff9f60: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa =>0x0c207fff9f70: fa fa[fa]fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c207fff9f80: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c207fff9f90: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c207fff9fa0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c207fff9fb0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c207fff9fc0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07 Heap left redzone: fa Heap right redzone: fb Freed heap region: fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 Stack partial redzone: f4 Stack after return: f5 Stack use after scope: f8 Global redzone: f9 Global init order: f6 Poisoned by user: f7 Container overflow: fc Array cookie: ac ASan internal: fe ==29857==ABORTING ___________ Thanks, Michele Spagnuolo
Thank you for this report. The bug was actually in the PCRE library, not in pcregrep. It was provoked by the use of an assertion with a zero minimum repeat as the condition in a conditional group. (I always thought allowing quantifiers on assertions was crazy, but Perl allows them, so PCRE does - though I see that Perl does not allow this particular case. Sigh.) The fix is a simple one-line-of-code patch to pcre_exec.c. I have committed this patch to the repository. --- pcre_exec.c (revision 1512) +++ pcre_exec.c (working copy) @@ -1404,8 +1404,11 @@ condition = TRUE; /* Advance ecode past the assertion to the start of the first branch, - but adjust it so that the general choosing code below works. */ - + but adjust it so that the general choosing code below works. If the + assertion has a quantifier that allows zero repeats we must skip over + the BRAZERO. This is a lunatic thing to do, but somebody did! */ + + if (*ecode == OP_BRAZERO) ecode++; ecode += GET(ecode, 1); while (*ecode == OP_ALT) ecode += GET(ecode, 1); ecode += 1 + LINK_SIZE - PRIV(OP_lengths)[condcode];
*** Bug 1548 has been marked as a duplicate of this bug. ***
> I have committed this patch to the repository. I cannot find it there. Are you sure? And where you able to reproduce it?
> I cannot find it there. Are you sure? https://lists.exim.org/lurker/message/20141119.111722.e9325273.en.html
Aha. That's pcre2 repository. I think the reporter was reporting pcre 8.36. This Bugzilla instance does not list PCRE2 product. Handling bug reports this way will be confusing.
I confirm this is in 8.36. Will this be fixed in the next release? Thanks.
On Wed, 19 Nov 2014, Michele Spagnuolo wrote: > I confirm this is in 8.36. Will this be fixed in the next release? Thanks. My apologies. I thought I had committed the patch for this, but obviously I had only committed the patch for PCRE2, not PCRE1. I have now committed the patch for PCRE1. Yes, it is in 8.36 and many previous releases. The fix will be in the next release, but normally we don't put out releases too frequently, and 8.36 was out only last September. Of course if people feel this sufficiently important an earlier release could be made. Otherwise the next release is likely to be around Feb/Mar next year. PCRE2 version numbers will start at 10.00 in an attempt to avoid too much confusion. Philip
Thank you. If you can, please reference CVE-2014-8964 as a CVE for this potential security vulnerability.