SumatraPDF 2.1.1/MuPDF 1.0 - Integer Overflow

EDB-ID:

23246


Author:

beford

Type:

dos


Platform:

Windows

Date:

2012-12-09


Sumatra 2.1.1/MuPDF 1.0 Integer Overflow
=======================================

There is an integer overflow on the MuPDF in the lex_number() function
which can be triggered using a corrupt PDF file with ObjStm.

I'm attaching a file that reproduces the problem with the original
unmodified file. The ObjStm was modified to include big numbers.

The easy way to fix is to update to the latest version of MuPDF library.

Affected products
=================

MuPDF 1.0 (previous release)
MuPDF for iOS 1.1 (current release)
Sumatra 2.1.1 (current stable release)

Fixed
=====

MuPDF 1.1
http://git.ghostscript.com/?p=mupdf.git;a=commitdiff;h=f919270b6a732ff45c3ba2d0c105e2b39e9c9bc9
Sumatra Pre-release version:
http://blog.kowalczyk.info/software/sumatrapdf/prerelease.html

CVE
====
CVE-2012-5340

Flaw details
============

On the FIXME line occurs an integer overflow, which can be later abused to
write to memory:

File: pdf_lex.c
static int lex_number(fz_stream *f, pdf_lexbuf *buf, int c)
{
        .....

        while (1)
        {
                int c = fz_read_byte(f);
                switch (c)
                {
                case '.':
                        goto loop_after_dot;
                case RANGE_0_9:
                        i = 10*i + c - '0';
                        /* FIXME: Need overflow check here; do we care? */
                        break;
                default:
                        fz_unread_byte(f);
                        /* Fallthrough */
                case EOF:
                        if (neg)
                                i = -i;
                        buf->i = i;
                        return PDF_TOK_INT;
                }
        }
       ....


file: pdf_repair.c
static void pdf_repair_obj_stm(pdf_document *xref, int num, int gen)
{
      ....

        for (i = 0; i < count; i++)
        {
                tok = pdf_lex(stm, &buf);
                if (tok != PDF_TOK_INT)
                        fz_throw(ctx, "corrupt object stream (%d %d R)",
num, gen);

                n = buf.i; // n can take negative values when an integer
overflow occurs
                if (n >= xref->len)
                        pdf_resize_xref(xref, n + 1);

                xref->table[n].ofs = num; // Writes
                xref->table[n].gen = i;
                xref->table[n].stm_ofs = 0;

POC
====
Attached proof of concept.
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/23246.tar.gz

!Exploitable output
===================

MuPDF:

Description: User Mode Write AV
Short Description: WriteAV
Exploitability Classification: EXPLOITABLE
Recommended Bug Title: Exploitable - User Mode Write AV starting at
mupdf+0x000000000003e1a6 (Hash=0x0e1a1f61.0x5f702654)

User mode write access violations that are not near NULL are exploitable.

Sumatra:

SumatraPDF!pdf_repair_obj_stms+0x94
SumatraPDF!pdf_open_document_with_stream+0x2c3
SumatraPDF!PdfEngineImpl::LoadFromStream+0xaa
SumatraPDF!PdfEngineImpl::Load+0x179
SumatraPDF!PdfEngine::CreateFromFile+0x80
SumatraPDF!EngineManager::CreateEngine+0x82
SumatraPDF!LoadDocIntoWindow+0x266
SumatraPDF!LoadDocumentOld+0x41f
SumatraPDF!LoadDocument+0xc
SumatraPDF!LoadOnStartup+0x89
SumatraPDF!WinMain+0x57c
SumatraPDF!__tmainCRTStartup+0x142
SumatraPDF!WinMainCRTStartup+0xf
kernel32!BaseThreadInitThunk+0x12
ntdll32!RtlInitializeExceptionChain+0x63
ntdll32!RtlInitializeExceptionChain+0x36
Instruction Address: 0x00000000775315de

Description: User Mode Write AV
Short Description: WriteAV
Exploitability Classification: EXPLOITABLE
Recommended Bug Title: Exploitable - User Mode Write AV starting at
ntdll32!ZwRaiseException+0x0000000000000012
(Hash=0x16621b14.0x14396738)

User mode write access violations that are not near NULL are exploitable.