Re: Bug#858230: reproducing the recent PCRE issues
Hi Matthew,
On Sat, Mar 25, 2017 at 05:00:35PM +0000, Matthew Vernon wrote:
> Hi,
>
> > I've tried to reproduce the PCRE3 issues from CVE-2017-7186.
> > CVE-2017-7244, CVE-2017-7245 and CVE-2017-7246 are similar fuzzing
> > attacks so this probably applies to those as well.
>
> Thanks for looking at these. I fixed CVE-2017-7186 with upstream's patch in
> sid. It's unfortunate that upstream don't seem keen on referring to CVE
> numbers, but I think they correspond roughly thus:
>
> CVE-2017-7186 - 2052 https://bugs.exim.org/show_bug.cgi?id=2052
> CVE-2017-7244 - 2054 (upstream thinks duplicate of 2052 or 2044
> CVE-2017-7245 - 2055
> CVE-2017-7246 - 2057
>
> So 2054 is either a duplicate of 2052 which we have fixed or 2044, which is
> in pcretest which we don't ship from PCRE3.
>
I did research those yesterday for the current version in testing and
opened corresponding bugs. I will review that again.
> The latter 2 upstream describe as "fixed by recent patches", although it's
> not entirely clear to me which patches upstream means - pcre_get.c hasn't
> changed since r1651 if svn log is to be believed. And there aren't many
> plausible-looking commits since 8.40 was released - so I think upstream
> thinks these issues apply only to pcretest (which has had some patches since
> 8.40, but we don't ship in any case).
I did look at those as well, and I think indeed those two are yet
unfixed, at least the reproducer still show the issues with the
current revision in VCS.
[...]
==7050==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7ffea6199f00 at pc 0x557d501f35bd bp 0x7ffea6199250 sp 0x7ffea6199248
WRITE of size 4 at 0x7ffea6199f00 thread T0
#0 0x557d501f35bc in pcre32_copy_substring /root/pcre/pcre_get.c:358
#1 0x557d50072e1b in main /root/pcre/pcretest.c:5342
#2 0x7f182189a2b0 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x202b0)
#3 0x557d50060de9 in _start (/root/pcre/pcretest+0x1bde9)
Address 0x7ffea6199f00 is located in stack of thread T0 at offset 2336 in frame
#0 0x557d50066fa5 in main /root/pcre/pcretest.c:2987
This frame has 35 object(s):
[32, 36) 'erroroffset'
[96, 100) 'first_char'
[160, 164) 'need_char'
[224, 228) 'match_limit'
[288, 292) 'recursion_limit'
[352, 356) 'count'
[416, 420) 'backrefmax'
[480, 484) 'first_char_set'
[544, 548) 'need_char_set'
[608, 612) 'okpartial'
[672, 676) 'jchanged'
[736, 740) 'hascrorlf'
[800, 804) 'maxlookbehind'
[864, 868) 'match_empty'
[928, 932) 'callout_data'
[992, 996) 'count'
[1056, 1060) 'd'
[1120, 1128) 'cn32ptr'
[1184, 1192) 'gn32ptr'
[1248, 1256) 'cn16ptr'
[1312, 1320) 'gn16ptr'
[1376, 1384) 'cn8ptr'
[1440, 1448) 'gn8ptr'
[1504, 1512) 'error'
[1568, 1576) 'markptr'
[1632, 1640) 'get_options'
[1696, 1704) 'size'
[1760, 1768) 'nametable'
[1824, 1832) 'sbuf'
[1888, 1904) 'rlim'
[1952, 1976) 'lockout'
[2016, 2040) 'preg'
[2080, 2336) 'copybuffer' <== Memory access at offset 2336 overflows this variable
[2368, 6464) 'copynames'
[6496, 10592) 'getnames'
HINT: this may be a false positive if your program uses some custom stack unwind mechanism or swapcontext
(longjmp and C++ exceptions *are* supported)
SUMMARY: AddressSanitizer: stack-buffer-overflow /root/pcre/pcre_get.c:358 in pcre32_copy_substring
Shadow bytes around the buggy address:
0x100054c2b390: 00 f4 f4 f4 f2 f2 f2 f2 00 f4 f4 f4 f2 f2 f2 f2
0x100054c2b3a0: 00 f4 f4 f4 f2 f2 f2 f2 00 00 f4 f4 f2 f2 f2 f2
0x100054c2b3b0: 00 00 00 f4 f2 f2 f2 f2 00 00 00 f4 f2 f2 f2 f2
0x100054c2b3c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x100054c2b3d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x100054c2b3e0:[f2]f2 f2 f2 00 00 00 00 00 00 00 00 00 00 00 00
0x100054c2b3f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x100054c2b400: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x100054c2b410: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x100054c2b420: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x100054c2b430: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
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
Intra object redzone: bb
ASan internal: fe
Left alloca redzone: ca
Right alloca redzone: cb
==7050==ABORTING
*But* we should mix the individual issues here in this bugreport I
think. So I will followup individually on the already opened.
Let me know if you think I'm wrong on the reports.
Regards,
Salvatore
Reply to: