| Summary: | MuPDF 1.0 Integer Overflow | ||
|---|---|---|---|
| Product: | MuPDF | Reporter: | Fernando M <xbefordx> |
| Component: | mupdf | Assignee: | MuPDF bugs <mupdf-bugs> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | robin.watts, tor.andersson |
| Priority: | P4 | ||
| Version: | 1.0 | ||
| Hardware: | PC | ||
| OS: | Windows 7 | ||
| Customer: | Word Size: | --- | |
| Attachments: | Test case for this bug. | ||
Created attachment 8992 [details]
Test case for this bug.
ObjStm was modified to reproduce the integer overflow and write access violation.
CVE-2012-5340 was requested and assigned for this issue. So, what is required of us here? A rebuild of an up to date version for iOS? That would be perfect. I wasn't sure about reporting the issue but since some software maybe still using the previous library it's better to let them know it. I've already contacted the SumatraPDF author because the current stable version still uses MuPDF 1.0. I will wait some weeks before making the public announcement of the flaw. |
MuPDF 1.0 Integer Overflow ======================================= This flaw was fixed on MuPDF 1.1, see details at bottom. There is an integer overflow on the MuPDF in the lex_number() function which can be triggered using a corrupt PDF file with ObjStm. This flaw was classified as EXPLOITABLE by !Exploitable. Attached a file that reproduces the problem. Affected products ================= MuPDF 1.0 (previous release) Sumatra 2.1.1 (current release) Current version of MuPDF for iOS seems to be still affected. Flaw details ============ On the FIXME line occurs an integer overflow: static int lex_number(fz_stream *f, pdf_lexbuf *buf, int c) (file: pdf_lex.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; } } .... static void pdf_repair_obj_stm(pdf_document *xref, int num, int gen) (file: pdf_repair.c) { .... 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; // Write access violation occurs xref->table[n].gen = i; xref->table[n].stm_ofs = 0; !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 (debug info): 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. Fixed in this commit ==================== MuPDF: http://git.ghostscript.com/?p=mupdf.git;a=commitdiff;h=f919270b6a732ff45c3ba2d0c105e2b39e9c9bc9 Sumatra: Current Version seems to be vulnerable.