libpcre: invalid memory read in _pcre32_xclass (pcre_xclass.c)

Description:
libpcre is a perl-compatible regular expression library.

A fuzz on libpcre1 through the pcretest utility revealed an invalid memory read. Upstream says that this bug is fixed by one of the previous commit. However I’m providing as usual the stacktrace and the reproducer, so if you are not running the latest upstream release, like happen on debian/rhel based distros, you may want to check better the status of this bug.

The complete ASan output:

# pcretest -32 -d $FILE
==27914==ERROR: AddressSanitizer: SEGV on unknown address 0x7f3f580efe04 (pc 0x7f3f577b8048 bp 0x7ffcb035b390 sp 0x7ffcb035b320 T0)
==27914==The signal is caused by a READ memory access.
    #0 0x7f3f577b8047 in _pcre32_xclass /tmp/portage/dev-libs/libpcre-8.40/work/pcre-8.40/pcre_xclass.c:135:30
    #1 0x7f3f576137ca in match /tmp/portage/dev-libs/libpcre-8.40/work/pcre-8.40/pcre_exec.c:3203:16
    #2 0x7f3f575e7226 in pcre32_exec /tmp/portage/dev-libs/libpcre-8.40/work/pcre-8.40/pcre_exec.c:6936:8
    #3 0x527d6c in main /tmp/portage/dev-libs/libpcre-8.40/work/pcre-8.40/pcretest.c:5218:9
    #4 0x7f3f565b478f in __libc_start_main /tmp/portage/sys-libs/glibc-2.23-r3/work/glibc-2.23/csu/../csu/libc-start.c:289
    #5 0x41b438 in _init (/usr/bin/pcretest+0x41b438)

AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV /tmp/portage/dev-libs/libpcre-8.40/work/pcre-8.40/pcre_xclass.c:135:30 in _pcre32_xclass
==27914==ABORTING

Affected version:
8.40

Fixed version:
8.41 (not released atm)

Commit fix:
N/A

Credit:
This bug was discovered by Agostino Sarubbo of Gentoo.

CVE:
CVE-2017-7244

Reproducer:
https://github.com/asarubbo/poc/blob/master/00206-pcre-invalidread-_pcre32_xclass

Timeline:
2017-02-24: bug discovered and reported to upstream
2017-03-20: blog post about the issue
2017-03-23: CVE assigned

Note:
This bug was found with American Fuzzy Lop.

Permalink:

libpcre: invalid memory read in _pcre32_xclass (pcre_xclass.c)

Posted in advisories, security | Leave a comment

libpcre: heap-based buffer overflow in regexflip8_or_16 (pcretest.c)

Description:
libpcre is a perl-compatible regular expression library.

A fuzz on libpcre1 through the pcretest utility revealed an heap overflow in the utility itself. Will follow a feedback from upstream.

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.

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

The complete ASan output:

# pcretest -16 -d $FILE
==30352==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x60b00000b000 at pc 0x00000053cef0 bp 0x7ffd02dccb90 sp 0x7ffd02dccb88
READ of size 2 at 0x60b00000b000 thread T0
    #0 0x53ceef in regexflip8_or_16 /tmp/portage/dev-libs/libpcre-8.40/work/pcre-8.40/pcretest.c:2552:24
    #1 0x53ceef in regexflip /tmp/portage/dev-libs/libpcre-8.40/work/pcre-8.40/pcretest.c:2792
    #2 0x53ceef in main /tmp/portage/dev-libs/libpcre-8.40/work/pcre-8.40/pcretest.c:4425
    #3 0x7fb6693d678f in __libc_start_main /tmp/portage/sys-libs/glibc-2.23-r3/work/glibc-2.23/csu/../csu/libc-start.c:289
    #4 0x41b438 in _init (/usr/bin/pcretest+0x41b438)

0x60b00000b000 is located 0 bytes to the right of 112-byte region [0x60b00000af90,0x60b00000b000)
allocated by thread T0 here:
    #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
    #1 0x53e883 in new_malloc /tmp/portage/dev-libs/libpcre-8.40/work/pcre-8.40/pcretest.c:2372:15
    #2 0x7fb66a9473a1 in pcre16_compile2 /tmp/portage/dev-libs/libpcre-8.40/work/pcre-8.40/pcre_compile.c:9393:19
    #3 0x5335d9 in main /tmp/portage/dev-libs/libpcre-8.40/work/pcre-8.40/pcretest.c:4034:5
    #4 0x7fb6693d678f in __libc_start_main /tmp/portage/sys-libs/glibc-2.23-r3/work/glibc-2.23/csu/../csu/libc-start.c:289

SUMMARY: AddressSanitizer: heap-buffer-overflow /tmp/portage/dev-libs/libpcre-8.40/work/pcre-8.40/pcretest.c:2552:24 in regexflip8_or_16

Affected version:
8.40

Commit fix:
N/A

Fixed version:
N/A

Credit:
This bug was discovered by Agostino Sarubbo of Gentoo.

Reproducer:
https://github.com/asarubbo/poc/blob/master/00196-pcre-heapoverflow-regexflip8_or_16

Timeline:
2017-02-22: bug discovered and reported to upstream
2017-03-20: blog post about the issue

Note:
This bug was found with American Fuzzy Lop.

Permalink:

libpcre: heap-based bufffer overflow in regexflip8_or_16 (pcretest.c)

Posted in advisories, security | Leave a comment

libpcre: two stack-based buffer overflow write in pcre32_copy_substring (pcre_get.c)

Description:
libpcre is a perl-compatible regular expression library.

A fuzz on libpcre1 through the pcretest utility revealed two stack overflow write. Upstream says that these bugs are fixed by one of the previous commit. However I’m providing as usual the stacktrace and the reproducer, so if you are not running the latest upstream release, like happen on debian/rhel based distros, you may want to check better the status of this bug.

The complete ASan output:

# pcretest -32 -d $FILE
==29686==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7f58f32026a0 at pc 0x7f58f6f90a24 bp 0x7ffea3aa3b30 sp 0x7ffea3aa3b28
WRITE of size 4 at 0x7f58f32026a0 thread T0
    #0 0x7f58f6f90a23 in pcre32_copy_substring /tmp/portage/dev-libs/libpcre-8.40/work/pcre-8.40/pcre_get.c:358:15
    #1 0x528220 in main /tmp/portage/dev-libs/libpcre-8.40/work/pcre-8.40/pcretest.c:5333:13
    #2 0x7f58f5ea778f in __libc_start_main /tmp/portage/sys-libs/glibc-2.23-r3/work/glibc-2.23/csu/../csu/libc-start.c:289
    #3 0x41b438 in _init (/usr/bin/pcretest+0x41b438)

Reproducer:
https://github.com/asarubbo/poc/blob/master/00207-pcre-stackoverflow-pcre32_copy_substring
CVE:
CVE-2017-7245

# pcretest -32 -d $FILE
==21399==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7f83734026a0 at pc 0x0000004bd2ac bp 0x7ffdda673b30 sp 0x7ffdda6732e0
WRITE of size 268 at 0x7f83734026a0 thread T0
    #0 0x4bd2ab in __asan_memcpy /tmp/portage/sys-devel/llvm-3.9.1-r1/work/llvm-3.9.1.src/projects/compiler-rt/lib/asan/asan_interceptors.cc:413
    #1 0x7f8377118925 in pcre32_copy_substring /tmp/portage/dev-libs/libpcre-8.40/work/pcre-8.40/pcre_get.c:357:1
    #2 0x528220 in main /tmp/portage/dev-libs/libpcre-8.40/work/pcre-8.40/pcretest.c:5333:13
    #3 0x7f837602f78f in __libc_start_main /tmp/portage/sys-libs/glibc-2.23-r3/work/glibc-2.23/csu/../csu/libc-start.c:289
    #4 0x41b438 in _init (/usr/bin/pcretest+0x41b438)

Reproducer:
https://github.com/asarubbo/poc/blob/master/00209-pcre-stackoverflow2-read_capture_name32
CVE:
CVE-2017-7246

Affected version:
8.40

Fixed version:
8.41 (not released atm)

Commit fix:
N/A

Credit:
This bug was discovered by Agostino Sarubbo of Gentoo.

Timeline:
2017-02-24: bug discovered and reported to upstream
2017-03-20: blog post about the issue

Note:
This bug was found with American Fuzzy Lop.

Permalink:

libpcre: two stack-based buffer overflow write in pcre32_copy_substring (pcre_get.c)

Posted in advisories, security | Leave a comment

libpcre: invalid memory read in match (pcre_exec.c)

Description:
libpcre is a perl-compatible regular expression library.

A fuzz on libpcre1 through the pcretest utility revealed an invalid read in the library. For who is interested in a detailed description of the bug, will follow a feedback from 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.

The complete ASan output:

# pcretest -32 -d $FILE
==14788==ERROR: AddressSanitizer: SEGV on unknown address 0x7f1bbffed4df (pc 0x7f1bbee3fe6b bp 0x7fff8b50d8c0 sp 0x7fff8b50d3a0 T0)
==14788==The signal is caused by a READ memory access.
    #0 0x7f1bbee3fe6a in match /tmp/portage/dev-libs/libpcre-8.40/work/pcre-8.40/pcre_exec.c:5473:18
    #1 0x7f1bbee09226 in pcre32_exec /tmp/portage/dev-libs/libpcre-8.40/work/pcre-8.40/pcre_exec.c:6936:8
    #2 0x527d6c in main /tmp/portage/dev-libs/libpcre-8.40/work/pcre-8.40/pcretest.c:5218:9
    #3 0x7f1bbddd678f in __libc_start_main /tmp/portage/sys-libs/glibc-2.23-r3/work/glibc-2.23/csu/../csu/libc-start.c:289
    #4 0x41b438 in _init (/usr/bin/pcretest+0x41b438)

AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV /tmp/portage/dev-libs/libpcre-8.40/work/pcre-8.40/pcre_exec.c:5473:18 in match
==14788==ABORTING

Affected version:
8.40 and 10.23

Fixed version:
8.41 and 10.24 (not released atm)

Commit fix for libpcre1:
https://vcs.pcre.org/pcre/code/trunk/pcre_internal.h?r1=1649&r2=1688&sortby=date
https://vcs.pcre.org/pcre/code/trunk/pcre_ucd.c?r1=1490&r2=1688&sortby=date

Commit fix for libpcre2:
https://vcs.pcre.org/pcre2/code/trunk/src/pcre2_ucd.c?r1=316&r2=670&sortby=date
https://vcs.pcre.org/pcre2/code/trunk/src/pcre2_internal.h?r1=600&r2=670&sortby=date

Credit:
This bug was discovered by Agostino Sarubbo of Gentoo.

CVE:
CVE-2017-7186

Reproducer:
https://github.com/asarubbo/poc/blob/master/00204-pcre-invalidread1-pcre_exec

Timeline:
2017-02-23: bug discovered and reported to upstream
2017-02-24: upstream released a patch
2017-03-14: blog post about the issue
2017-03-19: CVE assigned

Note:
This bug was found with American Fuzzy Lop.

Permalink:

libpcre: invalid memory read in match (pcre_exec.c)

Posted in advisories, security | Leave a comment

libpcre: NULL pointer dereference in main (pcretest.c)

Description:
libpcre is a perl-compatible regular expression library.

A fuzz on libpcre1 through the pcretest utility revealed a null pointer dereference in the utility itself. For the nature of the crash, it is not security relevant because the library is not affected but if you have a web application that calls directly the pcretest utility to parse untrusted data, then you are affected.
Also, it is important share the details because some distros/packagers may want to take the patch in their repository.

The complete ASan output:

# pcretest -16 -d $FILE
==26399==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000 (pc 0x00000052db1c bp 0x7ffc7de68070 sp 0x7ffc7de67ba0 T0)                                                                                                                                            
==26399==The signal is caused by a READ memory access.                                                                                                                                                                                                                         
==26399==Hint: address points to the zero page.                                                                                                                                                                                                                                
    #0 0x52db1b in main /tmp/portage/dev-libs/libpcre-8.40/work/pcre-8.40/pcretest.c:5083:25                                                                                                                                                                                   
    #1 0x7f70603bc78f in __libc_start_main /tmp/portage/sys-libs/glibc-2.23-r3/work/glibc-2.23/csu/../csu/libc-start.c:289                                                                                                                                                     
    #2 0x41b438 in _init (/usr/bin/pcretest+0x41b438) 

Affected version:
8.40

Fixed version:
8.41 (not released atm)

Commit fix:
https://vcs.pcre.org/pcre/code/trunk/pcretest.c?r1=1685&r2=1686&sortby=date

Credit:
This bug was discovered by Agostino Sarubbo of Gentoo.

CVE:
N/A

Reproducer:
https://github.com/asarubbo/poc/blob/master/00195-pcre-nullptr-main

Timeline:
2017-02-22: bug discovered and reported to upstream
2017-02-23: upstream released a patch
2017-03-14: blog post about the issue

Note:
This bug was found with American Fuzzy Lop.

Permalink:

libpcre: NULL pointer dereference in main (pcretest.c)

Posted in advisories, security | Leave a comment

libpcre: invalid memory read in phar (pcretest.c)

Description:
libpcre is a perl-compatible regular expression library.

A fuzz on libpcre1 through the pcretest utility revealed an invalid read in the utility itself. For the nature of the crash, it is not security relevant because the library is not affected but if you have a web application that calls directly the pcretest utility to parse untrusted data, then you are affected.
Also, it is important share the details because some distros/packagers may want to take the patch in their repository.

The complete ASan output:

# pcretest -16 -d $FILE
==28444==ERROR: AddressSanitizer: SEGV on unknown address 0x7f3c2de3e2dd (pc 0x0000005409dd bp 0x7fff0423db40 sp 0x7fff0423dac0 T0)
==28444==The signal is caused by a READ memory access.
    #0 0x5409dc in pchar /tmp/portage/dev-libs/libpcre-8.40/work/pcre-8.40/pcretest.c:1986:5
    #1 0x54006f in pchars16 /tmp/portage/dev-libs/libpcre-8.40/work/pcre-8.40/pcretest.c:2115:12
    #2 0x52e3e1 in main /tmp/portage/dev-libs/libpcre-8.40/work/pcre-8.40/pcretest.c:5092:15
    #3 0x7f3c2dc3878f in __libc_start_main /tmp/portage/sys-libs/glibc-2.23-r3/work/glibc-2.23/csu/../csu/libc-start.c:289
    #4 0x41b438 in _init (/usr/bin/pcretest+0x41b438)

Affected version:
8.40

Fixed version:
8.41 (not released atm)

Commit fix:
https://vcs.pcre.org/pcre/code/trunk/pcretest.c?r1=1665&r2=1685&sortby=date

Credit:
This bug was discovered by Agostino Sarubbo of Gentoo.

CVE:
N/A

Reproducer:
https://github.com/asarubbo/poc/blob/master/00194-pcre-invalidread-phar

Timeline:
2017-02-22: bug discovered and reported to upstream
2017-02-22: upstream released a patch
2017-03-14: blog post about the issue

Note:
This bug was found with American Fuzzy Lop.

Permalink:

libpcre: invalid memory read in phar (pcretest.c)

Posted in advisories, security | Leave a comment

potrace: heap-based buffer overflow in bm_readbody_bmp (bitmap_io.c) (incomplete fix for CVE-2016-8698)

Description:
potrace is a utility that transforms bitmaps into vector graphics.

A fuzz on 1.14 showed that an overflow previously reported as CVE-2016-8698 was not really fixed. Since there isn’t a public git repository, I uploaded the patch on my ‘poc’ repository on github. The patch was sent from the upstream maintainer, Mr. Peter Selinger.

The complete ASan output:

# potrace $FILE
==7325==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x60200000efd0 at pc 0x00000051dc51 bp 0x7ffc766b1a30 sp 0x7ffc766b1a28
READ of size 8 at 0x60200000efd0 thread T0
    #0 0x51dc50 in bm_readbody_bmp /tmp/portage/media-gfx/potrace-1.14/work/potrace-1.14/src/bitmap_io.c:754:4
    #1 0x51dc50 in bm_read /tmp/portage/media-gfx/potrace-1.14/work/potrace-1.14/src/bitmap_io.c:138
    #2 0x510a45 in process_file /tmp/portage/media-gfx/potrace-1.14/work/potrace-1.14/src/main.c:1058:9
    #3 0x50dd56 in main /tmp/portage/media-gfx/potrace-1.14/work/potrace-1.14/src/main.c:1214:7
    #4 0x7f6c7333e78f in __libc_start_main /tmp/portage/sys-libs/glibc-2.23-r3/work/glibc-2.23/csu/../csu/libc-start.c:289
    #5 0x419b68 in getenv (/usr/bin/potrace+0x419b68)

0x60200000efd1 is located 0 bytes to the right of 1-byte region [0x60200000efd0,0x60200000efd1)
allocated by thread T0 here:
    #0 0x4d2b25 in calloc /tmp/portage/sys-devel/llvm-3.9.1-r1/work/llvm-3.9.1.src/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:72
    #1 0x519776 in bm_new /tmp/portage/media-gfx/potrace-1.14/work/potrace-1.14/src/bitmap.h:121:30
    #2 0x519776 in bm_readbody_bmp /tmp/portage/media-gfx/potrace-1.14/work/potrace-1.14/src/bitmap_io.c:574
    #3 0x519776 in bm_read /tmp/portage/media-gfx/potrace-1.14/work/potrace-1.14/src/bitmap_io.c:138
    #4 0x510a45 in process_file /tmp/portage/media-gfx/potrace-1.14/work/potrace-1.14/src/main.c:1058:9
    #5 0x50dd56 in main /tmp/portage/media-gfx/potrace-1.14/work/potrace-1.14/src/main.c:1214:7
    #6 0x7f6c7333e78f in __libc_start_main /tmp/portage/sys-libs/glibc-2.23-r3/work/glibc-2.23/csu/../csu/libc-start.c:289

SUMMARY: AddressSanitizer: heap-buffer-overflow /tmp/portage/media-gfx/potrace-1.14/work/potrace-1.14/src/bitmap_io.c:754:4 in bm_readbody_bmp
Shadow bytes around the buggy address:
  0x0c047fff9da0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c047fff9db0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c047fff9dc0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c047fff9dd0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c047fff9de0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
=>0x0c047fff9df0: fa fa fa fa fa fa fa fa fa fa[01]fa fa fa 04 fa
  0x0c047fff9e00: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c047fff9e10: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c047fff9e20: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c047fff9e30: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c047fff9e40: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
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
==7325==ABORTING

Affected version:
1.14

Fixed version:
1.15

Commit fix:
https://github.com/asarubbo/poc/blob/master/00219-potrace-heapoverflow-bm_readbody_bmp-PATCH

Credit:
This bug was discovered by Agostino Sarubbo of Gentoo.

CVE:
N/A

Reproducer:
https://github.com/asarubbo/poc/blob/master/00210-potrace-heapoverflow-bm_readbody_bmp

Timeline:
2017-02-26: bug discovered and reported to upstream
2017-02-28: upstream released a patch
2017-03-03: blog post about the issue

Note:
This bug was found with American Fuzzy Lop.

Permalink:
https://blogs.gentoo.org/ago/2017/03/03/potrace-heap-based-buffer-overflow-in-bm_readbody_bmp-bitmap_io-c-incomplete-fix-for-cve-2016-8698

Posted in advisories, security | Leave a comment

podofo: NULL pointer dereference in PoDoFo::PdfColorGray::~PdfColorGray (PdfColor.cpp)

Description:
podofo is a C++ library to work with the PDF file format.

A fuzz on it discovered a null pointer dereference. The upstream project denies me to open a new ticket. So, I just will forward this on the -users mailing list.

The complete ASan output:

# podofocolor dummy $FILE foo
==5815==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000 (pc 0x7f025d243787 bp 0x7ffe33517c50 sp 0x7ffe33517be0 T0)
==5815==The signal is caused by a READ memory access.
==5815==Hint: address points to the zero page.
    #0 0x7f025d243786 in PoDoFo::PdfColorGray::~PdfColorGray() /tmp/portage/app-text/podofo-0.9.4/work/podofo-0.9.4/src/base/PdfColor.cpp:435:1
    #1 0x52c9b2 in GraphicsStack::TGraphicsStackElement::~TGraphicsStackElement() /tmp/portage/app-text/podofo-0.9.4/work/podofo-0.9.4/tools/podofocolor/graphicsstack.h:29:11
    #2 0x52c9b2 in __gnu_cxx::new_allocator::destroy(GraphicsStack::TGraphicsStackElement*) /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.3/include/g++-v4/ext/new_allocator.h:133
    #3 0x52c9b2 in std::deque<GraphicsStack::TGraphicsStackElement, std::allocator >::_M_pop_back_aux() /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.3/include/g++-v4/bits/deque.tcc:515
    #4 0x52c9b2 in std::deque<GraphicsStack::TGraphicsStackElement, std::allocator >::pop_back() /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.3/include/g++-v4/bits/stl_deque.h:1459
    #5 0x52c9b2 in std::stack<GraphicsStack::TGraphicsStackElement, std::deque<GraphicsStack::TGraphicsStackElement, std::allocator > >::pop() /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.3/include/g++-v4/bits/stl_stack.h:218
    #6 0x52c9b2 in GraphicsStack::Pop() /tmp/portage/app-text/podofo-0.9.4/work/podofo-0.9.4/tools/podofocolor/graphicsstack.cpp:48
    #7 0x522031 in ColorChanger::ReplaceColorsInPage(PoDoFo::PdfCanvas*) /tmp/portage/app-text/podofo-0.9.4/work/podofo-0.9.4/tools/podofocolor/colorchanger.cpp:190:35
    #8 0x51ed8e in ColorChanger::start() /tmp/portage/app-text/podofo-0.9.4/work/podofo-0.9.4/tools/podofocolor/colorchanger.cpp:120:15
    #9 0x51c06d in main /tmp/portage/app-text/podofo-0.9.4/work/podofo-0.9.4/tools/podofocolor/podofocolor.cpp:116:12
    #10 0x7f025bd2e61f in __libc_start_main /var/tmp/portage/sys-libs/glibc-2.22-r4/work/glibc-2.22/csu/libc-start.c:289
    #11 0x428718 in _start (/usr/bin/podofocolor+0x428718)

AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV /tmp/portage/app-text/podofo-0.9.4/work/podofo-0.9.4/src/base/PdfColor.cpp:435:1 in PoDoFo::PdfColorGray::~PdfColorGray()
==5815==ABORTING

Affected version:
0.9.4

Fixed version:
N/A

Commit fix:
N/A

Credit:
This bug was discovered by Agostino Sarubbo of Gentoo.

CVE:
CVE-2017-6849

Reproducer:
https://github.com/asarubbo/poc/blob/master/00175-podofo-nullptr-PoDoFo-PdfColorGray-PdfColorGray

Timeline:
2017-02-13: bug discovered
2017-03-02: bug reported to upstream
2017-03-02: blog post about the issue
2017-03-12: CVE assigned

Note:
This bug was found with American Fuzzy Lop.

Permalink:

podofo: NULL pointer dereference in PoDoFo::PdfColorGray::~PdfColorGray (PdfColor.cpp)

Posted in advisories, security | Leave a comment

podofo: NULL pointer dereference in PoDoFo::PdfXObject::PdfXObject (PdfXObject.cpp)

Description:
podofo is a C++ library to work with the PDF file format.

A fuzz on it discovered a null pointer dereference. The upstream project denies me to open a new ticket. So, I just will forward this on the -users mailing list.

The complete ASan output:

# podofocolor dummy $FILE foo
==21036==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000 (pc 0x7fc5cfd94743 bp 0x7ffc1eaffe50 sp 0x7ffc1eaffd40 T0)
==21036==The signal is caused by a READ memory access.
==21036==Hint: address points to the zero page.
    #0 0x7fc5cfd94742 in PoDoFo::PdfXObject::PdfXObject(PoDoFo::PdfObject*) /tmp/portage/app-text/podofo-0.9.5/work/podofo-0.9.5/src/doc/PdfXObject.cpp:264:74
    #1 0x529308 in ColorChanger::start() /tmp/portage/app-text/podofo-0.9.5/work/podofo-0.9.5/tools/podofocolor/colorchanger.cpp:137:28
    #2 0x523b8d in main /tmp/portage/app-text/podofo-0.9.5/work/podofo-0.9.5/tools/podofocolor/podofocolor.cpp:116:12
    #3 0x7fc5cd8d178f in __libc_start_main /tmp/portage/sys-libs/glibc-2.23-r3/work/glibc-2.23/csu/../csu/libc-start.c:289
    #4 0x4300e8 in _start (/usr/bin/podofocolor+0x4300e8)

AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV /tmp/portage/app-text/podofo-0.9.5/work/podofo-0.9.5/src/doc/PdfXObject.cpp:264:74 in PoDoFo::PdfXObject::PdfXObject(PoDoFo::PdfObject*)
==21036==ABORTING

Affected version:
0.9.5

Fixed version:
N/A

Commit fix:
N/A

Credit:
This bug was discovered by Agostino Sarubbo of Gentoo.

CVE:
CVE-2017-6848

Reproducer:
https://github.com/asarubbo/poc/blob/master/00214-podofo-nullptr-PdfXObject-cpp

Timeline:
2017-03-01: bug discovered
2017-03-02: bug reported upstream
2017-03-02: blog post about the issue
2017-03-12: CVE assigned

Note:
This bug was found with American Fuzzy Lop.

Permalink:

podofo: NULL pointer dereference in PoDoFo::PdfXObject::PdfXObject (PdfXObject.cpp)

Posted in advisories, security | Leave a comment

podofo: NULL pointer dereference in PoDoFo::PdfVariant::DelayedLoad (PdfVariant.h)

Description:
podofo is a C++ library to work with the PDF file format.

A fuzz on it discovered a null pointer dereference. The upstream project denies me to open a new ticket. So, I just will forward this on the -users mailing list.

The complete ASan output:

# podofocolor dummy $FILE foo
==5768==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000018 (pc 0x7f6504f1742c bp 0x7fffc41a0df0 sp 0x7fffc41a0d00 T0)
==5768==The signal is caused by a READ memory access.
==5768==Hint: address points to the zero page.
    #0 0x7f6504f1742b in PoDoFo::PdfVariant::DelayedLoad() const /tmp/portage/app-text/podofo-0.9.4/work/podofo-0.9.4/src/base/PdfVariant.h:545:10
    #1 0x7f6504f1742b in PoDoFo::PdfVariant::GetArray() /tmp/portage/app-text/podofo-0.9.4/work/podofo-0.9.4/src/base/PdfVariant.h:795
    #2 0x7f6504f1742b in PoDoFo::PdfXObject::PdfXObject(PoDoFo::PdfObject*) /tmp/portage/app-text/podofo-0.9.4/work/podofo-0.9.4/src/doc/PdfXObject.cpp:264
    #3 0x51ff55 in ColorChanger::start() /tmp/portage/app-text/podofo-0.9.4/work/podofo-0.9.4/tools/podofocolor/colorchanger.cpp:137:28
    #4 0x51c06d in main /tmp/portage/app-text/podofo-0.9.4/work/podofo-0.9.4/tools/podofocolor/podofocolor.cpp:116:12
    #5 0x7f650358c61f in __libc_start_main /var/tmp/portage/sys-libs/glibc-2.22-r4/work/glibc-2.22/csu/libc-start.c:289
    #6 0x428718 in _start (/usr/bin/podofocolor+0x428718)

AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV /tmp/portage/app-text/podofo-0.9.4/work/podofo-0.9.4/src/base/PdfVariant.h:545:10 in PoDoFo::PdfVariant::DelayedLoad() const
==5768==ABORTING

Affected version:
0.9.4

Fixed version:
N/A

Commit fix:
N/A

Credit:
This bug was discovered by Agostino Sarubbo of Gentoo.

CVE:
CVE-2017-6847

Reproducer:
https://github.com/asarubbo/poc/blob/master/00174-podofo-nullptr-PoDoFo-PdfVariant-DelayedLoad

Timeline:
2017-02-13: bug discovered
2017-03-02: bug reported to upstream
2017-03-02: blog post about the issue
2017-03-12: CVE assigned

Note:
This bug was found with American Fuzzy Lop.

Permalink:

podofo: NULL pointer dereference in PoDoFo::PdfVariant::DelayedLoad (PdfVariant.h)

Posted in advisories, security | Leave a comment