[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

reproducing the recent PCRE issues


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:


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

==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

$ ./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

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.


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

Reply to: