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).
This code is present even in xpdf 0.9x versions, so is likely to be used in other applications forking or embedding xpdf. Current upstream xpdf version 3.02pl3 is affected, as well as xpdf versions shipped in EL3 and EL4. poppler has this problem fixed already and uses gmallocn. This was fixed in the last round of xpdf fixes earlier this year as preventive fix, while other integer overflow fixes were addressed. Upstream commit: http://cgit.freedesktop.org/poppler/poppler/diff/poppler/PSOutputDev.cc?id=7b2d314a61 This patch is already used in the latest poppler packages version in EL5 and gpdf version in EL4. CUPS does contain this code, but it is not reachable, as pdftops in CUPS never uses level1Sep PS level. It initializes level as: 119 level = psLevel2; and later possibly changes that based on the info from the PPD file: 143 level = ppd->language_level == 1 ? psLevel1 : psLevel2; Even though pdftops in CUPS reads xpdfrc-like configuration file pdftops.conf, PS output level is always set to one of the above values after reading the configuration file. Additionally, latest CUPS packages in EL3 and EL4 have this changed to use gmallocn. kdegraphics' kpdf program only contains PSOutputDev in the version shipped in EL5 and is used to convert PDF to PS for printing. kpdf does not change PS level from the default level2. However, it does read xpdfrc configuration file used by xpdf. Additionally, it is affected by the problem as described here: http://bugs.gentoo.org/show_bug.cgi?id=242930 GlobalParams::GlobalParams tries to read an xpdfrc file, either one specified as its argument (kpdf passes empty string), user's local ~/.xpdfrc (xpdfUserConfigFile) or global xpdfc (xpdfUserConfigFile). But as SYSTEM_XPDFRC is not defined, kpdf tries to open (global) xpdfrc from the current directory, instead of the expected /etc/xpdfrc. Unlike Gentoo's xpdf case, kpdf does not seem to process xpdfrc options than can lead to command execution (psFile, urlCommand, movieCommand), so does not offer a way to execute commands without exploiting some other flaw. We should still fix this in the next kdegraphics update, possibly by completely removing an attempt to read global xpdfrc, as that never worked for kpdf. xpdf copy embedded in tetex contains this code too, I've not looked yet if it may be reachable though.
Fixed now in xpdf 3.02pl4: ftp://ftp.foolabs.com/pub/xpdf/xpdf-3.02pl4.patch https://bugzilla.redhat.com/show_bug.cgi?id=526637#c14
This issue has been addressed in following products: Red Hat Enterprise Linux 5 Via RHSA-2009:1502 https://rhn.redhat.com/errata/RHSA-2009-1502.html
This issue has been addressed in following products: Red Hat Enterprise Linux 4 Via RHSA-2009:1501 https://rhn.redhat.com/errata/RHSA-2009-1501.html
This issue has been addressed in following products: Red Hat Enterprise Linux 3 Via RHSA-2009:1500 https://rhn.redhat.com/errata/RHSA-2009-1500.html
xpdf-3.02-15.fc11 has been pushed to the Fedora 11 stable repository. If problems still persist, please make note of it in this bug report.
xpdf-3.02-15.fc10 has been pushed to the Fedora 10 stable repository. If problems still persist, please make note of it in this bug report.
poppler-0.8.7-7.fc10 has been submitted as an update for Fedora 10. http://admin.fedoraproject.org/updates/poppler-0.8.7-7.fc10
poppler-0.10.7-3.fc11 has been submitted as an update for Fedora 11. http://admin.fedoraproject.org/updates/poppler-0.10.7-3.fc11
poppler-0.8.7-7.fc10 has been pushed to the Fedora 10 stable repository. If problems still persist, please make note of it in this bug report.
poppler-0.10.7-3.fc11 has been pushed to the Fedora 11 stable repository. If problems still persist, please make note of it in this bug report.
xpdf-3.02-15.el5 has been pushed to the Fedora EPEL 5 stable repository. If problems still persist, please make note of it in this bug report.
Duplicate CVE identifier of CVE-2009-3906 has been also assigned to this issue: Name: CVE-2009-3906 Status: Candidate URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-3906 Final-Decision: Interim-Decision: Modified: Proposed: Assigned: 20091109 Category: ** REJECT ** DO NOT USE THIS CANDIDATE NUMBER. ConsultIDs: CVE-2009-3606. Reason: This candidate is a duplicate of CVE-2009-3606. A typo caused the wrong ID to be used. Notes: All CVE users should reference CVE-2009-3606 instead of this candidate. All references and descriptions in this candidate have been removed to prevent accidental usage.
pdfedit-0.4.3-4.fc13 has been pushed to the Fedora 13 stable repository. If problems still persist, please make note of it in this bug report.
pdfedit-0.4.3-4.fc11 has been pushed to the Fedora 11 stable repository. If problems still persist, please make note of it in this bug report.
pdfedit-0.4.3-4.fc12 has been pushed to the Fedora 12 stable repository. If problems still persist, please make note of it in this bug report.