CESA-2005-003 - rev 2 [See all my vulnerabilities at http://scary.beasts.org/security] xpdf (and derivatives) buffer and integer overflows =================================================== Programs affected: xpdf, gpdf, kpdf, pdftohtml, probably others. Severity: Probable arbitrary code execution with some of the individual points. Vendor notified date: Dec 11th 2005 Note: Some of these vulnerabilities overlap with some independently noted vulnerabilities such as http://www.idefense.com/intelligence/vulnerabilities/display.php?id=342 http://www.idefense.com/intelligence/vulnerabilities/display.php?id=343 http://www.idefense.com/intelligence/vulnerabilities/display.php?id=344 The PDF format presents a somewhat large attack surface. Previous advisories such as CESA-2004-002 and CESA-2004-007 dealt with attacks against the PDF framework which defines a series of objects and their relations. This advisory demonstrates attacks against the binary (and other) encodings used for some objects in PDF files. xpdf and derivatives support approaching 10 different encodings. Details ======= 1) Out-of-bounds heap accesses with large or negative parameters to "FlateDecode" stream. User-supplied integers (negative or large) are not checked for overflow or underflow in buffer size calculations in Stream.cc:StreamPredictor::StreamPredictor(). Demo pdf: http://scary.beasts.org/misc/pending/bad7.pdf On a system with a modern glibc, this will cause xpdf to exit: *** glibc detected *** double free or corruption (out): 0x0818a038 *** 2) Out-of-bounds heap accesses with large or negative parameters to "CCITTFaxDecode" stream. User-supplied integers (negative or large) are not checked for overflow or underflow in buffer size calculations in Stream.cc::CCITTFaxStream::CCITTFaxStream(). Demo pdf: http://scary.beasts.org/misc/pending/bad8.pdf Causes a segfault. 3) Infinite CPU spins in various places when stream ends unexpectedly. Probably repeated at various locations in the code. The following demos trigger issues in the "CCITTFaxDecode" and "DCTDecode" streams. Demo pdf: http://scary.beasts.org/misc/pending/bad9.pdf Demo pdf: http://scary.beasts.org/misc/pending/bad10.pdf 4) NULL pointer crash in the "FlateDecode" stream. Although a crash in client software is more of a reliability issue than a security issue, it still denotes a lack of robustness. Demo pdf: http://scary.beasts.org/misc/pending/bad6.pdf 5) Overflows of compInfo array in "DCTDecode" stream. User-supplied "number of components" value not checked against maximum of 4 in Stream.cc:DCTStream::readBaselineSOF() and Stream.cc:DCTStream::readProgressiveSOF(). Demo pdf: http://scary.beasts.org/misc/pending/bad11.pdf (readBaselineSOF) Demo pdf: http://scary.beasts.org/misc/pending/bad12.pdf (readProgressiveSOF) Note - demos don't produce crashes. Haven't tuned them yet. Have validated in the debugger that writes are occurring outside the intended array. The overflow amount is limited, and the structure being overflowed is followed by some very large structures, so what can be overwritten may be limited. However, there are some very interesting things to overwrite such as the actual count driving the loop which is doing the overwriting! This should unlimit the amount of the overflow. 6) Possible to use index past end of array in "DCTDecode" stream. User-supplied "Huffman table index" value not always checked against maximum size in Stream.cc:DCTStream::readHuffmanTables(). Demo pdf: http://scary.beasts.org/misc/pending/bad13.pdf Again, demo does not cause crash - it is untuned. Possible caveats along the lines of point 5) too. 7) More possible out-of-bounds indexing trouble in "DCTDecode" stream. See usage of scanInfo.numComps in Stream.cc:DCTStream::readScanInfo(). CESA-2005-003 - rev 2 Chris Evans chris@scary.beasts.org