Created attachment 13323 [details] POC to trigger heap out of bounds read (mutool) After some fuzz testing I found a crashing test case. Git HEAD: 8eea208e099614487e4bd7cc0d67d91489dae642 To reproduce: mutool draw -F svg mupdf_null_ptr_dodrawpage -o /dev/null ASAN: ==32184==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x60300000e534 at pc 0x0000005c94fc bp 0x7ffc96aeaf50 sp 0x7ffc96aeaf48 READ of size 1 at 0x60300000e534 thread T0 #0 0x5c94fb in fz_subsample_pixmap XYZ/mupdf/source/fitz/pixmap.c:1260:12 #1 0x5a0940 in fz_get_pixmap_from_image XYZ/mupdf/source/fitz/image.c:685:3 #2 0x5ff1dc in fz_draw_fill_image XYZ/mupdf/source/fitz/draw-device.c:1287:11 #3 0x54e941 in fz_fill_image XYZ/mupdf/source/fitz/device.c:319:3 #4 0x61d2e5 in fz_run_display_list XYZ/mupdf/source/fitz/list-device.c:1651:6 #5 0x4f241b in drawband XYZ/mupdf/source/tools/mudraw.c:420:4 #6 0x4f042d in dodrawpage XYZ/mupdf/source/tools/mudraw.c:776:6 #7 0x4f38ad in drawpage XYZ/mupdf/source/tools/mudraw.c:1031:3 #8 0x4edab6 in drawrange XYZ/mupdf/source/tools/mudraw.c:1060:6 #9 0x4eb2c9 in mudraw_main XYZ/mupdf/source/tools/mudraw.c:1635:7 #10 0x4e6943 in main XYZ/mupdf/source/tools/mutool.c:112:12 #11 0x7f62f2ad482f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2082f) #12 0x41a218 in _start (XYZ/mupdf/build/debug/mutool+0x41a218) AddressSanitizer can not describe address in more detail (wild memory access suspected). SUMMARY: AddressSanitizer: heap-buffer-overflow XYZ/mupdf/source/fitz/pixmap.c:1260:12 in fz_subsample_pixmap Shadow bytes around the buggy address: 0x0c067fff9c50: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c067fff9c60: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c067fff9c70: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c067fff9c80: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c067fff9c90: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa =>0x0c067fff9ca0: fa fa fa fa fa fa[fa]fa fa fa fa fa fa fa fa fa 0x0c067fff9cb0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa 00 00 0x0c067fff9cc0: 00 06 fa fa 00 00 00 fa fa fa 00 00 00 fa fa fa 0x0c067fff9cd0: 00 00 00 fa fa fa 00 00 00 00 fa fa 00 00 00 fa 0x0c067fff9ce0: fa fa 00 00 00 fa fa fa 00 00 00 00 fa fa 00 00 0x0c067fff9cf0: 00 fa fa fa 00 00 00 fa fa fa 00 00 00 00 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 ==32184==ABORTING
Sorry, wrong command to reproduce. Should be: mutool draw -F svg mutool_hoobr_fz_subsample_pixmap -o /dev/null
This is reproducible with the current stable with the following testcase: https://github.com/asarubbo/poc/blob/master/00148-mupdf-heapoverflow-fz_subsample_pixmap SUMMARY: AddressSanitizer: heap-buffer-overflow /tmp/portage/app-text/mupdf-1.10a/work/mupdf-1.10a-source/source/fitz/pixmap.c:1210:12 in fz_subsample_pixmap
this is CVE-2017-5896
(In reply to Kamil Frankowicz from comment #0) > To reproduce: mutool draw -F svg mupdf_null_ptr_dodrawpage -o /dev/null This is not a valid invocation of MuPDF. You need to specify the -o before the input file. This used to trigger a SEGV due to the output pointer being uninitialised. This would have happened for any input file, not just this fuzzed one. This bug was fixed in: commit 40ac85bfb676bb4373bda4b18f9fd90268c9f1e9 Author: Sebastian Rasmussen <sebras@gmail.com> Date: Sat Feb 4 06:21:20 2017 +0100 Bug 697514: Write SVG output to stdout if no output specified. So, I am proceeding to check with the latest version of the source (commit 24bfb2d) on 64bit Ubuntu, using: mutool draw -F svg -o /dev/null mupdf_null_ptr_dodrawpage As far as I can tell, this invocation NEVER calls fz_subsample_pixmap...
(In reply to Agostino Sarubbo from comment #2) > This is reproducible with the current stable with the following testcase: "current stable" is unhelpful. A git SHA or an exact release name please. Also, on what platform? > https://github.com/asarubbo/poc/blob/master/00148-mupdf-heapoverflow- > fz_subsample_pixmap Please always attach files to the bug. External links have a way of disappearing at inopportune moments.
(In reply to Agostino Sarubbo from comment #3) > this is CVE-2017-5896 On Ubuntu 64bit, using commit 24bfb2d798c12c3da44547054331cedb1dcac683, and the command: mutool draw -F svg -o /dev/null mupdf_null_ptr_dodrawpage I cannot see problems with address sanitizer, nor with valgrind. In addition the code never calls fz_subsample_pixmap. I am therefore closing this bug. Feel free to reopen it if you can give me more information as to how to reproduce it.
Awww... Sorry for the inconvenience. Once again wrong command... Should be: mutool draw -F png -o /dev/null mutool_hoobr_fz_subsample_pixmap I checked it on 90fa6203ad032fe161d85a3e580941ce3d1216f0 and still exists.
(In reply to Robin Watts from comment #5) > "current stable" is unhelpful. A git SHA or an exact release name please. Your current stable is 1.10a, so 1.10a (which is visible from the asan summary) > Also, on what platform? Gentoo x86_64 the command I used was: mutool draw $PDF
(In reply to Agostino Sarubbo from comment #8) > (In reply to Robin Watts from comment #5) > > "current stable" is unhelpful. A git SHA or an exact release name please. > Your current stable is 1.10a, so 1.10a (which is visible from the asan > summary) > > > > Also, on what platform? > Gentoo x86_64 > > the command I used was: > mutool draw $PDF I can confirm that I have now reproduced this. Looking into it now.
Fixed in: commit 2c4e5867ee699b1081527bc6c6ea0e99a35a5c27 Author: Robin Watts <Robin.Watts@artifex.com> Date: Thu Feb 9 07:12:16 2017 -0800 bug 697515: Fix out of bounds read in fz_subsample_pixmap Pointer arithmetic for final special case was going wrong. Thanks!