Bug 693371 - MuPDF 1.0 Integer Overflow
Summary: MuPDF 1.0 Integer Overflow
Status: RESOLVED FIXED
Alias: None
Product: MuPDF
Classification: Unclassified
Component: mupdf (show other bugs)
Version: 1.0
Hardware: PC Windows 7
: P4 normal
Assignee: MuPDF bugs
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-10-09 01:56 UTC by Fernando M
Modified: 2014-05-06 07:13 UTC (History)
2 users (show)

See Also:
Customer:
Word Size: ---


Attachments
Test case for this bug. (314.59 KB, application/pdf)
2012-10-09 01:57 UTC, Fernando M
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Fernando M 2012-10-09 01:56:18 UTC
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.
Comment 1 Fernando M 2012-10-09 01:57:43 UTC
Created attachment 8992 [details]
Test case for this bug.

ObjStm was modified to reproduce the integer overflow and write access violation.
Comment 2 Fernando M 2012-10-09 03:34:31 UTC
CVE-2012-5340 was requested and assigned for this issue.
Comment 3 Robin Watts 2012-10-09 13:59:25 UTC
So, what is required of us here? A rebuild of an up to date version for iOS?
Comment 4 Fernando M 2012-10-09 16:11:42 UTC
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.