reproducing the recent PCRE issues
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
Reply to: