Bug 699686 - MuPDF 1.13.0 erro in pdf_get_xref_entry at pde-xref.c
Summary: MuPDF 1.13.0 erro in pdf_get_xref_entry at pde-xref.c
Status: RESOLVED FIXED
Alias: None
Product: MuPDF
Classification: Unclassified
Component: apps (show other bugs)
Version: master
Hardware: PC Linux
: P4 normal
Assignee: MuPDF bugs
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-08-29 06:27 UTC by Krace
Modified: 2019-03-15 22:01 UTC (History)
3 users (show)

See Also:
Customer:
Word Size: ---


Attachments
the poc file (78.53 KB, application/pdf)
2018-08-29 06:27 UTC, Krace
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Krace 2018-08-29 06:27:25 UTC
Created attachment 15534 [details]
the poc file

In Mupdf 1.13,the pdf_get_xref_entry function in source/pdf/pdf-xref.c allows remote attackers to cause a denial of service(segmentation fault)via a crafted pdf file.
The main cause is that the pdf_get_xref_entry function will return a pdf_xref_entry *entry which the entry->stm_buf->data is pointed to 0x10.It will cause the memcpy in fz_write_data function at source/fitz/output.c to crash.

In fz_write_data:412  `memcpy(out->wp,data,size)` ,the data is pointed to 0x10

Here is the backtrace:
```
#0  __memcpy_sse2_unaligned () at ../sysdeps/x86_64/multiarch/memcpy-sse2-unaligned.S:35
#1  0x0000000000497452 in fz_write_data (ctx=0x29de010, out=0x2a05840, data_=0x10, size=0x73) at source/fitz/output.c:412
#2  0x00000000004fc64d in write_data (ctx=0x29de010, arg=0x2a05840,
    data=0x10 <error: Cannot access memory at address 0x10>, len=0x73) at source/pdf/pdf-write.c:1665
#3  0x00000000004d2abb in pdf_encrypt_data (ctx=0x29de010, crypt=0x0, num=0x46, gen=0x0, write_data=0x4fc61c <write_data>,
    arg=0x2a05840, s=0x10 <error: Cannot access memory at address 0x10>, n=0x73) at source/pdf/pdf-crypt.c:1080
#4  0x00000000004fc8ff in copystream (ctx=0x29de010, doc=0x29f53d0, opts=0x7fffffffdb20, obj_orig=0x2be6b60, num=0x46,
    gen=0x0, do_deflate=0x0) at source/pdf/pdf-write.c:1716
#5  0x00000000004fd573 in writeobject (ctx=0x29de010, doc=0x29f53d0, opts=0x7fffffffdb20, num=0x46, gen=0x0,
    skip_xrefs=0x1, unenc=0x0) at source/pdf/pdf-write.c:1923
#6  0x00000000004fe5ba in dowriteobject (ctx=0x29de010, doc=0x29f53d0, opts=0x7fffffffdb20, num=0x46, pass=0x0)
    at source/pdf/pdf-write.c:2226
#7  0x00000000004fe794 in writeobjects (ctx=0x29de010, doc=0x29f53d0, opts=0x7fffffffdb20, pass=0x0)
    at source/pdf/pdf-write.c:2258
#8  0x0000000000501108 in do_pdf_save_document (ctx=0x29de010, doc=0x29f53d0, opts=0x7fffffffdb20, in_opts=0x29f5340)
    at source/pdf/pdf-write.c:3024
#9  0x00000000005016e3 in pdf_save_document (ctx=0x29de010, doc=0x29f53d0, filename=0x29f53b0 "out.pdf", in_opts=0x29f5340)
    at source/pdf/pdf-write.c:3167
#10 0x0000000000501a41 in pdf_writer_close_writer (ctx=0x29de010, wri_=0x29f5310) at source/pdf/pdf-write.c:3334
#11 0x00000000004c01a9 in fz_close_document_writer (ctx=0x29de010, wri=0x29f5310) at source/fitz/writer.c:168
#12 0x00000000004033f8 in muconvert_main (argc=0x4, argv=0x7fffffffde30) at source/tools/muconvert.c:190
#13 0x0000000000402a79 in main (argc=0x5, argv=0x7fffffffde28) at source/tools/mutool.c:132
#14 0x00007ffff7507830 in __libc_start_main (main=0x4027ef <main>, argc=0x5, argv=0x7fffffffde28, init=<optimized out>,
    fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fffffffde18) at ../csu/libc-start.c:291
#15 0x00000000004026b9 in _start ()
```

how:
./mutool convert -o out.pdf poc2.pdf
Comment 1 Tor Andersson 2018-11-07 14:30:07 UTC
commit 351c99d8ce23bbf7099dbd52771a095f67e45a2c
Author: Sebastian Rasmussen <sebras@gmail.com>
Date:   Mon Oct 1 15:13:13 2018 +0800

    Avoid being smart about keeping only a single reference to the buffer.
    
    When pdf_dev_pop() is called it will drop the reference to the buffer.
    pdf_dev_push_new_buf() will either create a new buffer reference or take a reference to the existing buffer.
    When pdf_dev_pop() is called unbalance this creates a problem as the
    top level buffer will be unreferenced too many times.
Comment 2 Salvatore Bonaccorso 2019-03-15 21:47:19 UTC
Hi

When build with -O2 apparently the fix is ineffective. See https://bugs.debian.org/924351 . What is missing apart of cherry-picking 351c99d8ce23bbf7099dbd52771a095f67e45a2c to address CVE-2018-16647?

Regards,
Comment 3 Salvatore Bonaccorso 2019-03-15 22:01:29 UTC
Ok ignore the last comment, the issue seen was caused by the missing commit fa4cdfca9ec3034dbe54e1cb08c8b97e9ebed46d