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