Xpdf » Xpdf » 3.0_pl3 : Security Vulnerabilities, CVEs,

Unspecified vulnerability in certain versions of xpdf after 3.00, as used in various products including (a) pdfkit.framework, (b) gpdf, (c) pdftohtml, and (d) libextractor, has unknown impact and user-assisted attack vectors, possibly involving errors in (1) gmem.c, (2) SplashXPathScanner.cc, (3) JBIG2Stream.cc, (4) JPXStream.cc, and/or (5) Stream.cc. NOTE: this description is based on Debian advisory DSA 979, which is based on changes that were made after other vulnerabilities such as CVE-2006-0301 and CVE-2005-3624 through CVE-2005-3628 were fixed. Some of these newer fixes appear to be security-relevant, although it is not clear if they fix specific issues or are defensive in nature.

Heap-based buffer overflow in the JPXStream::readCodestream function in the JPX stream parsing code (JPXStream.c) for xpdf 3.01 and earlier, as used in products such as (1) Poppler, (2) teTeX, (3) KDE kpdf, (4) CUPS, and (5) libextractor allows user-assisted attackers to cause a denial of service (heap corruption) and possibly execute arbitrary code via a crafted PDF file with large size values that cause insufficient memory to be allocated.

Multiple heap-based buffer overflows in the (1) DCTStream::readProgressiveSOF and (2) DCTStream::readBaselineSOF functions in the DCT stream parsing code (Stream.cc) in xpdf 3.01 and earlier, as used in products such as (a) Poppler, (b) teTeX, (c) KDE kpdf, (d) pdftohtml, (e) KOffice KWord, (f) CUPS, and (g) libextractor allow user-assisted attackers to cause a denial of service (heap corruption) and possibly execute arbitrary code via a crafted PDF file with an out-of-range number of components (numComps), which is used as an array index.

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.