Out-of-bounds array write in Xpdf 4.06 and earlier, due to incorrect validation of the "N" field in ICCBased color spaces.

In Xpdf 4.05 (and earlier), a PDF object loop in a CMap, via the "UseCMap" entry, leads to infinite recursion and a stack overflow.

Out-of-bounds array write in Xpdf 4.05 and earlier, triggered by an invalid VerticesPerRow value in a PDF shading dictionary.

Out-of-bounds array write in Xpdf 4.05 and earlier, due to incorrect integer overflow checking in the PostScript function interpreter code.

Out-of-bounds array write in Xpdf 4.05 and earlier, due to missing object type check in AcroForm field reference.

In Xpdf 4.05 (and earlier), a PDF object loop in the PDF resources leads to infinite recursion and a stack overflow.

Out-of-bounds array write in Xpdf 4.05 and earlier, triggered by an invalid character code in a Type 1 font. The root problem was a bounds check that was being optimized away by modern compilers.

Out-of-bounds array write in Xpdf 4.05 and earlier, triggered by long Unicode sequence in ActualText.

In Xpdf 4.05 (and earlier), a PDF object loop in the attachments leads to infinite recursion and a stack overflow.

In Xpdf 4.05 (and earlier), a PDF object loop in an object stream leads to infinite recursion and a stack overflow.

Out-of-bounds array write in Xpdf 4.05 and earlier, triggered by negative object number in indirect reference in the input PDF file.

An insufficient escape sequences sanitization flaw was found in the way xpdf, a PDF file viewer for the X window system, and poppler, a PDF rendering library, performed sanitization of certain characters to be displayed in the error messages, which arose during presentation of certain PDF files. A remote attacker could use this flaw to modify a window's title, or, possibly execute arbitrary commands or overwrite files, via a specially-crafted PDF file containing an escape sequence for a terminal emulator if local, unsuspecting user opened such crafted PDF file in xpdf or in an application linked against poppler library (for example evince).

Sauli Pahlman of CERT-FI provided us with fuzzed PDF file which causes xpdf / poppler PDF parser to crash.

The crash is caused by an attempt to dereference uninitialized Gfx::parser pointer in Gfx::getPos(), which assumes parser is either NULL or valid Parser pointer.

http://cgit.freedesktop.org/poppler/poppler/tree/poppler/Gfx.cc?id=71063d51#n879

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.

Xpdf is an X Window System based viewer for Portable Document Format (PDF)files.Multiple integer overflow flaws were found in Xpdf. An attacker couldcreate a malicious PDF file that would cause Xpdf to crash or, potentially,execute arbitrary code when opened. (CVE-2009-0791, CVE-2009-3604,CVE-2009-3606, CVE-2009-3609)Red Hat would like to thank Adam Zabrocki for reporting the CVE-2009-3604issue.Users are advised to upgrade to this updated package, which contains abackported patch to correct these issues.

Integer overflow was discovered in SplashBitmap::SplashBitmap when computing memory allocation requirements. This issue was previously reported as CVE-2009-1188 / bug #495907 and addressed in poppler via gmalloc -> gmallocn change via: http://cgit.freedesktop.org/poppler/poppler/commit/?id=9cf2325fb2

However, such fix is not sufficient, as overflow can occur even during rowSize calculation.

Splash output device is not present in xpdf 2.x, it's also not in the xpdf code embedded in CUPS or tetex.

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.

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.

xpdf's PSOutputDev::doImageL1Sep contains an integer overflow in the lineBuf buffer allocation:

4303 // allocate a line buffer 4304 lineBuf = (Guchar )gmalloc(4 width);

width is read from the input PDF file and can integer overflow / wrap when multiplied by 4, resulting in an insufficient memory allocation, leading to heap overflow.

Impact of this flaw is, however, quite limited. This affects PSOutputDev class used to write / convert PDF input to PS (PostScript) output. For GUI viewers, this is done e.g. when trying to print the file. Additionally, this requires non-default Level 1 separable PostScript language level to be used for the output file (specified via e.g. -level1sep command line option for pdftops, or psLevel configuration option in xpdfrc).

oCERT reported an integer overflow flaw during the C++ object allocation leading to a heap overflow discovered by Chris Rohlf, affecting xpdf's / poppler's ObjectStream::ObjectStream (XRef.cc).

objs = new Object[nObjects];

As new[] as implemented in gcc / libstdc++ does not perform integer overflow check [1], sufficiently large nObjects value (read from the input PDF file) can cause integer overflow / wrap when multiplied by sizeof(Object) resulting in insufficient memory allocation.

Affected code was introduced in Xpdf 3.00, packages including / based on this version are affected by this flaw. In Red Hat Enterprise Linux, that means: - xpdf - el4 - gpdf - el4 - poppler - el5 - kdegraphics - el4, el5 - cups - el5 - tetex - el5

Patch attempting to address this was previously added to poppler, but it incorrectly used sizeof(int) instead of sizeof(Object) [2] and hence was insufficient.

[1] http://gcc.gnu.org/bugzilla/showbug.cgi?id=19351 [2] http://cgit.freedesktop.org/poppler/poppler/commit/?id=c36d8afc http://cgit.freedesktop.org/poppler/poppler/commit/?id=f41fa9ee

Acknowledgements:

Red Hat would like to thank Chris Rohlf for reporting this issue.

An infinite loop flaw was found in xpdf's JBIG2 MMR decoder. If a carefully crafted PDF file is opened, it could cause xpdf to stop responding.

Will Dormann of the CERT/CC created the extensive testsuite for the JBIG2 decoder in various PDF libraries that found this flaw.

Acknowledgements:

Red Hat would like to thank Will Dormann of the CERT/CC for responsibly reporting this flaw.

Multiple buffer overflow flaws were found in xpdf's JBIG2 MMR decoder. A carefully crafted PDF file could result in arbitrary code execute with the permissions of the user running xpdf.

Will Dormann of the CERT/CC created the extensive testsuite for the JBIG2 decoder in various PDF libraries that found this flaw.

Acknowledgements:

Red Hat would like to thank Will Dormann of the CERT/CC for responsibly reporting these flaws.

Multiple NULL derefernce flaws were found in xpdf's JBIG2 decoder. A carefully crafted PDF file could cause xpdf to crash when opened.

Will Dormann of the CERT/CC created the extensive testsuite for the JBIG2 decoder in various PDF libraries that found this flaw.

Acknowledgements:

Red Hat would like to thank Will Dormann of the CERT/CC for responsibly reporting these flaws.

An invalid free() flaw was found in xpdf's JBIG2 decoder. If a malicious PDF file could free() attacker controlled data, it may be possible to execute arbitrary code with the permissions of the user running xpdf.

Will Dormann of the CERT/CC created the extensive testsuite for the JBIG2 decoder in various PDF libraries that found this flaw.

Acknowledgements:

Red Hat would like to thank Will Dormann of the CERT/CC for responsibly reporting this flaw.

An integer overflow flaw was found in xpdf's JBIG2 decoder. This flaw could result in arbitrary code execute with the permissions of the user running xpdf.

Will Dormann of the CERT/CC created the extensive testsuite for the JBIG2 decoder in various PDF libraries that found this flaw.

Acknowledgements:

Red Hat would like to thank Will Dormann of the CERT/CC for responsibly reporting this flaw.

Multiple input validation flaws were discovered in xpdf's JBIG2 decoder. These flaws could lead to arbitrary code execute with the permissions of the user running xpdf.

Will Dormann of the CERT/CC created the extensive testsuite for the JBIG2 decoder in various PDF libraries that found this flaw.

Acknowledgements:

Red Hat would like to thank Will Dormann of the CERT/CC for responsibly reporting these flaws.

Array index error in the DCTStream::readProgressiveDataUnit method in xpdf/Stream.cc in Xpdf 3.02pl1, as used in poppler, teTeX, KDE, KOffice, CUPS, and other products, allows remote attackers to trigger memory corruption and execute arbitrary code via a crafted PDF file.

Heap-based buffer overflow in the CCITTFaxStream::lookChar method in xpdf/Stream.cc in Xpdf 3.02p11 allows remote attackers to execute arbitrary code via a PDF file that contains a crafted CCITTFaxDecode filter.

Integer overflow in the DCTStream::reset method in xpdf/Stream.cc in Xpdf 3.02p11 allows remote attackers to execute arbitrary code via a crafted PDF file, resulting in a heap-based buffer overflow.

The Adobe PDF specification 1.3, as implemented by (a) xpdf 3.0.1 patch 2, (b) kpdf in KDE before 3.5.5, (c) poppler before 0.5.4, and other products, allows remote attackers to have an unknown impact, possibly including denial of service (infinite loop), arbitrary code execution, or memory corruption, via a PDF file with a (1) crafted catalog dictionary or (2) a crafted Pages attribute that references an invalid page tree node.