Multiple integer overflows in xpdf 3.0, and other packages that use xpdf code such as CUPS, allow remote attackers to cause a denial of service (crash) and possibly execute arbitrary code, a different set of vulnerabilities than those identified by CVE-2004-0888.

Multiple integer overflows in xpdf 2.0 and 3.0, and other packages that use xpdf code such as CUPS, gpdf, and kdegraphics, allow remote attackers to cause a denial of service (crash) and possibly execute arbitrary code, a different set of vulnerabilities than those identified by CVE-2004-0889.

Xpdf, as used in products such as gpdf, kpdf, pdftohtml, poppler, teTeX, CUPS, libextractor, and others, allows attackers to cause a denial of service (infinite loop) via streams that end prematurely, as demonstrated using the (1) CCITTFaxDecode and (2) DCTDecode streams, aka "Infinite CPU spins."

Xpdf, as used in products such as gpdf, kpdf, pdftohtml, poppler, teTeX, CUPS, libextractor, and others, allows attackers to cause a denial of service (crash) via a crafted FlateDecode stream that triggers a null dereference.

The CCITTFaxStream::CCITTFaxStream function in Stream.cc for xpdf, gpdf, kpdf, pdftohtml, poppler, teTeX, CUPS, libextractor, and others allows attackers to corrupt the heap via negative or large integers in a CCITTFaxDecode stream, which lead to integer overflows and integer underflows.

xpdf and kpdf do not properly validate the "loca" table in PDF files, which allows local users to cause a denial of service (disk consumption and hang) via a PDF file with a "broken" loca table, which causes a large temporary file to be created when xpdf attempts to reconstruct the information.

The patch for integer overflow vulnerabilities in Xpdf 2.0 and 3.0 (CVE-2004-0888) is incomplete for 64-bit architectures on certain Linux distributions such as Red Hat, which could leave Xpdf users exposed to the original vulnerabilities.

SuSE reported a buffer overflow in FoFiType1::parse affecting older xpdf versions. Code snippets from fofi/FoFiType1.cc:

133 void FoFiType1::parse() { ... 163 line = getNextLine(line); 164 for (j = 0; j < 300 && line; ++j) { 165 line1 = getNextLine(line); 166 if ((n = line1 - line) > 255) { 167 n = 255; 168 } 169 strncpy(buf, line, n);

getNextLine can, however, return NULL:

117 char FoFiType1::getNextLine(char line) { 118 while (line < (char )file + len && line != '\x0a' && line != '\x0d') { 119 ++line; 120 } 121 if (line < (char )file + len && line == '\x0d') { 122 ++line; 123 } 124 if (line < (char )file + len && line == '\x0a') { 125 ++line; 126 } 127 if (line >= (char )file + len) { 128 return NULL; 129 }

Therefore, (line1 - line) is not defined / results in negative value n. That value is later passed to strncpy, causing overflow of buf buffer.

Integer overflow in the PSOutputDev::doImageL1Sep function in Xpdf before 3.02pl4, and Poppler 0.x, as used in kdegraphics KPDF, might allow remote attackers to execute arbitrary code via a crafted PDF document that triggers a heap-based buffer overflow.

An integer overflow flaw exists in xpdf's ImageStream::ImageStream (Stream.cc) when calculating size of the imgLine buffer:

320 nVals = width nComps; 321 if (nBits == 1) { 322 imgLineSize = (nVals + 7) & ~7; 323 } else { 324 imgLineSize = nVals; 325 } 326 imgLine = (Guchar )gmallocn(imgLineSize, sizeof(Guchar));

width and nComps used go compute nVals value come from the input PDF file. Their multiplication may overflow / wrap, resulting in smaller imgLine buffer allocation than expected.

ImageStream always uses nVals as an upper bound when writing data into imgLine. Therefore, no buffer overflow occurs in ImageStream, but NULL pointer dereference may occur (gmallocn returns NULL when called with imgLineSize 0).

Pointer to imgLine is also returned out of ImageStream class instance from ImageStream::getLine() method. Callers of the method may later over-read allocated buffer, but no caller over-writing it was identified.

This code was introduced in xpdf in some early versions (exists in 0.9x), so is likely to appear in all applications embedding / forking xpdf.

Integer overflow in the ObjectStream::ObjectStream function in XRef.cc in Xpdf 3.x before 3.02pl4 and Poppler before 0.12.1, as used in GPdf, kdegraphics KPDF, CUPS pdftops, and teTeX, might allow remote attackers to execute arbitrary code via a crafted PDF document that triggers a heap-based buffer overflow.

Adam Zabrocki reported flaws in xpdf's Splash::drawImage function related to buffer memory allocations:

2220 // allocate pixel buffers 2221 colorBuf = (SplashColorPtr)gmalloc((yp + 1) w nComps); 2222 if (srcAlpha) { 2223 alphaBuf = (Guchar )gmalloc((yp + 1) w); 2224 } else { 2225 alphaBuf = NULL; 2226 }

Values used to compute argument passed to gmalloc come from input PDF file. Properly chosen values will cause gmalloc to return NULL or buffer of insufficient size, leading to NULL pointer dereference or heap buffer overflow later.

Affected Splash output device is not available in xpdf 2.x versions and earlier. It is also not used in xpdf embedded in CUPS or tetex.

This was already fixed in poppler as part of preventive gmalloc -> gmallocn changes: http://cgit.freedesktop.org/poppler/poppler/commit/?id=9cf2325fb2

This fix is also present in the EL5 poppler packages.

Acknowledgements:

Red Hat would like to thank Adam Zabrocki for reporting this issue.