Bug 697515

Summary: Heap out of bounds read in fz_subsample_pixmap()
Product: MuPDF Reporter: Kamil Frankowicz <kamil.frankowicz>
Component: mupdfAssignee: MuPDF bugs <mupdf-bugs>
Status: RESOLVED FIXED    
Severity: normal CC: ago, robin.watts
Priority: P4    
Version: master   
Hardware: PC   
OS: Linux   
Customer: Word Size: ---
Attachments: POC to trigger heap out of bounds read (mutool)

Description Kamil Frankowicz 2017-01-30 06:13:34 UTC
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
Comment 1 Kamil Frankowicz 2017-01-30 06:15:27 UTC
Sorry, wrong command to reproduce.

Should be: mutool draw -F svg mutool_hoobr_fz_subsample_pixmap -o /dev/null
Comment 2 Agostino Sarubbo 2017-02-06 03:33:13 UTC
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
Comment 3 Agostino Sarubbo 2017-02-06 23:45:26 UTC
this is CVE-2017-5896
Comment 4 Robin Watts 2017-02-08 02:39:05 UTC
(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...
Comment 5 Robin Watts 2017-02-08 02:58:05 UTC
(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.
Comment 6 Robin Watts 2017-02-08 03:00:17 UTC
(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.
Comment 7 Kamil Frankowicz 2017-02-08 08:23:12 UTC
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.
Comment 8 Agostino Sarubbo 2017-02-09 01:14:37 UTC
(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
Comment 9 Robin Watts 2017-02-09 05:19:15 UTC
(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.
Comment 10 Robin Watts 2017-02-09 07:17:35 UTC
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!