pcre3: CVE-2017-7186

Debian Bug report logs - #858230
pcre3: CVE-2017-7186

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Salvatore Bonaccorso <carnil@debian.org>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: pcre3: CVE-2017-7186

Date: Mon, 20 Mar 2017 07:04:17 +0100

Source: pcre3
Version: 2:8.39-2.1
Severity: important
Tags: patch security upstream fixed-upstream

Hi,

the following vulnerability was published for pcre3.

CVE-2017-7186[0]:
| libpcre1 in PCRE 8.40 and libpcre2 in PCRE2 10.23 allow remote
| attackers to cause a denial of service (segmentation violation for read
| access, and application crash) by triggering an invalid Unicode
| property lookup.

The bug is in the 32-bit library. Quoting upstream:

This was a genuine bug in the 32-bit library. Thanks for finding it.
The crash was caused by trying to find a Unicode property for a code
value greater than 0x10ffff, the Unicode maximum, when running in
non-UTF mode (where character values can be up to 0xffffffff). The bug
was in both PCRE1 and PCRE2. I have fixed both of them.

I have not yet checked if pcre2 in the version in unstable is as well
affected, but I guess so and will open a separate bug for it.

If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2017-7186
    https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-7186

Please adjust the affected versions in the BTS as needed. Older version
yet unchecked.

Regards,
Salvatore

Message #10 received at 858230@bugs.debian.org (full text, mbox, reply):

From: Salvatore Bonaccorso <carnil@debian.org>

To: 858230@bugs.debian.org

Subject: Re: Bug#858230: pcre3: CVE-2017-7186

Date: Mon, 20 Mar 2017 07:16:28 +0100

Control: clone -1 -2
Control: reassign -2 src:pcre2 10.22-2
Control: retitle -2 pcre2: CVE-2017-7186
Control: notfound -2 2:8.39-2.1
Control: forwarded -1 https://bugs.exim.org/show_bug.cgi?id=2052

On Mon, Mar 20, 2017 at 07:04:17AM +0100, Salvatore Bonaccorso wrote:
> Source: pcre3
> Version: 2:8.39-2.1
> Severity: important
> Tags: patch security upstream fixed-upstream
> 
> Hi,
> 
> the following vulnerability was published for pcre3.
> 
> CVE-2017-7186[0]:
> | libpcre1 in PCRE 8.40 and libpcre2 in PCRE2 10.23 allow remote
> | attackers to cause a denial of service (segmentation violation for read
> | access, and application crash) by triggering an invalid Unicode
> | property lookup.
> 
> The bug is in the 32-bit library. Quoting upstream:
> 
> This was a genuine bug in the 32-bit library. Thanks for finding it.
> The crash was caused by trying to find a Unicode property for a code
> value greater than 0x10ffff, the Unicode maximum, when running in
> non-UTF mode (where character values can be up to 0xffffffff). The bug
> was in both PCRE1 and PCRE2. I have fixed both of them.
> 
> I have not yet checked if pcre2 in the version in unstable is as well
> affected, but I guess so and will open a separate bug for it.

Ack, seems present. Cloning and reassigning.

Regards,
Salvatore

Message #21 received at 858230-done@bugs.debian.org (full text, mbox, reply):

From: Matthew Vernon <matthew@debian.org>

To: 858230-done@bugs.debian.org

Subject: Re: Bug#858230: pcre3: CVE-2017-7186

Date: Tue, 21 Mar 2017 22:40:39 +0000

version: 2:8.39-3

Fixed in this upload (where I typod in the changelog). Changelog:

pcre3 (2:8.39-3) unstable; urgency=high

  * CVE-2017-7186: invalid Unicode property lookup may cause denial of
    service (Closes: #858238)

 -- Matthew Vernon <matthew@debian.org>  Tue, 21 Mar 2017 22:03:19 +0000

Regards,

Matthew

Message #26 received at 858230@bugs.debian.org (full text, mbox, reply):

From: anarcat@orangeseeds.org (Antoine Beaupré)

To: debian-lts@lists.debian.org, Matthew Vernon <matthew@debian.org>

Cc: 858230@bugs.debian.org, team@security.debian.org

Subject: reproducing the recent PCRE issues

Date: Fri, 24 Mar 2017 13:19:12 -0400

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.

So far, i haven't been successful. It *seems* the reproducer requires
the binaries to be compiled with -fsanitize=address because the
"stacktrace" from the upstream bug includes some "AddressSanitizer"
output, but this is available only in clang and gcc from jessie:

        https://en.wikipedia.org/wiki/AddressSanitizer

The `pcretest` command gives out so much garbage that it's also pretty
hard to tell what's going on. In stretch (and sid as well, I am
guessing), the issue is fixed and the output is similar to that of
wheezy. However, if the the library is rebuilt with
DEB_CFLAGS_APPEND=-fsanitize=address, the test suite in the package now
fail:

=================================================================
==8231==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 216 byte(s) in 2 object(s) allocated from:
    #0 0x7fcd78542d28 in malloc (/lib/x86_64-linux-gnu/libasan.so.3+0xc1d28)
    #1 0x558af900f34d in new_malloc pcretest.c:2369

SUMMARY: AddressSanitizer: 216 byte(s) leaked in 2 allocation(s).
FAIL RunTest (exit status: 1)

I also get false positive, possibly because I screwed up instrumentation
somewhere there:

==6773==ASan runtime does not come first in initial library list; you should either link runtime to your application or manually preload it with LD_PRELOAD.

It would seem interesting to add the address sanitization checks from
the compiler in the build chain to find and fix those issues earlier.

In jessie, the command provided to reproduce the issue just aborts with
this:

$ ./pcretest -32 -d 00204-pcre-invalidread1-pcre_exec\?raw=true 
** This version of PCRE was built without 32-bit support

.... presumably this is because pcre is not built with `--enable-pcre32`
until 2:8.35-4.

So this all makes it pretty hard to test the reproducer... 

Therefore, I have still backported the patch for CVE-2017-7186 and
tested the PoC before and after. The results of the tests with or
without the patch are pretty similar, and neither show an obvious
crash.

My guess, however, is that the code for CVE-2017-7186 is simply not
compiled into wheezy. In fact, 8.3.30 doesn't seem to have PCRE32
support even into the upstream package.

I *assume* that the other three CVEs should also be similarly tested and
backported, so I'll do this next. But I figured I would share my first
results in case other people were working on this for sid/stable.

A.

-- 
Software gets slower faster than hardware gets faster.
                         - Wirth's law

Message #39 received at 858230@bugs.debian.org (full text, mbox, reply):

From: Matthew Vernon <matthew@debian.org>

To: Antoine Beaupré <anarcat@orangeseeds.org>, debian-lts@lists.debian.org

Cc: 858230@bugs.debian.org, team@security.debian.org

Subject: Re: reproducing the recent PCRE issues

Date: Sat, 25 Mar 2017 17:00:35 +0000

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.

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).

*If* that's correct, then we don't need to do any more for sid's pcre3, 
I think.

Regards,

Matthew

Message #44 received at 858230@bugs.debian.org (full text, mbox, reply):

From: Salvatore Bonaccorso <carnil@debian.org>

To: Matthew Vernon <matthew@debian.org>, 858230@bugs.debian.org

Cc: Antoine Beaupré <anarcat@orangeseeds.org>, debian-lts@lists.debian.org, team@security.debian.org

Subject: Re: Bug#858230: reproducing the recent PCRE issues

Date: Sat, 25 Mar 2017 20:08:24 +0100

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

Send a report that this bug log contains spam.