{"id":1492,"date":"2017-03-20T12:12:39","date_gmt":"2017-03-20T10:12:39","guid":{"rendered":"http:\/\/blogs.gentoo.org\/ago\/?p=1492"},"modified":"2017-03-20T12:41:21","modified_gmt":"2017-03-20T10:41:21","slug":"libpcre-heap-based-bufffer-overflow-in-regexflip8_or_16-pcretest-c","status":"publish","type":"post","link":"https:\/\/blogs.gentoo.org\/ago\/2017\/03\/20\/libpcre-heap-based-bufffer-overflow-in-regexflip8_or_16-pcretest-c\/","title":{"rendered":"libpcre: heap-based buffer overflow in regexflip8_or_16 (pcretest.c)"},"content":{"rendered":"

Description<\/strong>:
\nlibpcre<\/a> is a perl-compatible regular expression library.<\/p>\n

A fuzz on libpcre1 through the pcretest utility revealed an heap overflow in the utility itself. Will follow a feedback from upstream.<\/p>\n

I am not going to do anything about this one. (a) It is concerned with a feature of pcretest that has been dropped from pcre2test, and (b) the input contains binary zeros, which are not supported in pcretest input. This is documented for pcre2test but not, I see for pcretest. I have added a paragraph to the documentation.<\/p><\/blockquote>\n

However, it does not cost much for me inform the community that this bug exists.
\nIn any case, if you have a web application that calls directly the pcretest utility to parse untrusted data, then you are affected.
\nAlso, it is important share the details because some distros\/packagers may want to patch this issue instead of follow the upstream’s way.<\/p>\n

The complete ASan output:<\/p>\n

# pcretest -16 -d $FILE\r\n==30352==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x60b00000b000 at pc 0x00000053cef0 bp 0x7ffd02dccb90 sp 0x7ffd02dccb88\r\nREAD of size 2 at 0x60b00000b000 thread T0\r\n    #0 0x53ceef in regexflip8_or_16 \/tmp\/portage\/dev-libs\/libpcre-8.40\/work\/pcre-8.40\/pcretest.c:2552:24\r\n    #1 0x53ceef in regexflip \/tmp\/portage\/dev-libs\/libpcre-8.40\/work\/pcre-8.40\/pcretest.c:2792\r\n    #2 0x53ceef in main \/tmp\/portage\/dev-libs\/libpcre-8.40\/work\/pcre-8.40\/pcretest.c:4425\r\n    #3 0x7fb6693d678f in __libc_start_main \/tmp\/portage\/sys-libs\/glibc-2.23-r3\/work\/glibc-2.23\/csu\/..\/csu\/libc-start.c:289\r\n    #4 0x41b438 in _init (\/usr\/bin\/pcretest+0x41b438)\r\n\r\n0x60b00000b000 is located 0 bytes to the right of 112-byte region [0x60b00000af90,0x60b00000b000)\r\nallocated by thread T0 here:\r\n    #0 0x4d41f8 in malloc \/tmp\/portage\/sys-devel\/llvm-3.9.1-r1\/work\/llvm-3.9.1.src\/projects\/compiler-rt\/lib\/asan\/asan_malloc_linux.cc:64\r\n    #1 0x53e883 in new_malloc \/tmp\/portage\/dev-libs\/libpcre-8.40\/work\/pcre-8.40\/pcretest.c:2372:15\r\n    #2 0x7fb66a9473a1 in pcre16_compile2 \/tmp\/portage\/dev-libs\/libpcre-8.40\/work\/pcre-8.40\/pcre_compile.c:9393:19\r\n    #3 0x5335d9 in main \/tmp\/portage\/dev-libs\/libpcre-8.40\/work\/pcre-8.40\/pcretest.c:4034:5\r\n    #4 0x7fb6693d678f in __libc_start_main \/tmp\/portage\/sys-libs\/glibc-2.23-r3\/work\/glibc-2.23\/csu\/..\/csu\/libc-start.c:289\r\n\r\nSUMMARY: AddressSanitizer: heap-buffer-overflow \/tmp\/portage\/dev-libs\/libpcre-8.40\/work\/pcre-8.40\/pcretest.c:2552:24 in regexflip8_or_16\r\n<\/font><\/pre>\n
Affected version:<\/strong>
\n8.40<\/p>\n
Commit fix:<\/strong>
\nN\/A<\/p>\n
Fixed version:<\/strong>
\nN\/A<\/p>\n
Credit:<\/strong>
\nThis bug was discovered by Agostino Sarubbo of Gentoo.<\/p>\n
Reproducer:<\/strong>
\nhttps:\/\/github.com\/asarubbo\/poc\/blob\/master\/00196-pcre-heapoverflow-regexflip8_or_16<\/a><\/p>\n
Timeline:<\/strong>
\n2017-02-22: bug discovered and reported to upstream
\n2017-03-20: blog post about the issue<\/p>\n
Note:<\/strong>
\nThis bug was found with American Fuzzy Lop<\/a>.<\/p>\n
Permalink:<\/strong><\/p>\n
libpcre: heap-based bufffer overflow in regexflip8_or_16 (pcretest.c)<\/a><\/p><\/blockquote>\n