Bug 526877 (CVE-2009-3606)

Summary: CVE-2009-3606 xpdf/poppler: PSOutputDev::doImageL1Sep integer overflow
Product: [Other] Security Response Reporter: Tomas Hoger <thoger>
Component: vulnerabilityAssignee: Red Hat Product Security <security-response-team>
Status: CLOSED ERRATA QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: unspecifiedCC: jlieskov, jnovy, jrb, kreilly, mkasik, rdieter, tcallawa, than, twaugh, yoyzhang
Target Milestone: ---Keywords: Security
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard: impact=moderate,source=redhat,reported=20090603,public=20091014,cvss2=3.7/AV:L/AC:H/Au:N/C:P/I:P/A:P,cwe=CWE-190[auto]
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2010-07-08 12:27:49 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Bug Depends On: 527456, 527457, 527468, 527469, 527470, 530890, 833916    
Bug Blocks:    

Description Tomas Hoger 2009-10-02 05:22:30 EDT
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).
Comment 1 Tomas Hoger 2009-10-02 05:46:14 EDT
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.
Comment 8 errata-xmlrpc 2009-10-15 04:26:20 EDT
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
Comment 9 errata-xmlrpc 2009-10-15 04:34:35 EDT
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
Comment 10 errata-xmlrpc 2009-10-15 04:37:33 EDT
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
Comment 11 Fedora Update System 2009-10-20 20:47:41 EDT
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.
Comment 12 Fedora Update System 2009-10-20 20:54:24 EDT
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.
Comment 14 Fedora Update System 2009-10-26 08:18:55 EDT
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
Comment 15 Fedora Update System 2009-10-26 08:20:21 EDT
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
Comment 16 Fedora Update System 2009-10-27 03:04:57 EDT
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.
Comment 17 Fedora Update System 2009-10-27 03:15:00 EDT
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.
Comment 18 Fedora Update System 2009-11-06 13:31:54 EST
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.
Comment 19 Jan Lieskovsky 2009-12-12 06:54:53 EST
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.
Comment 20 Fedora Update System 2010-02-19 19:11:28 EST
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.
Comment 21 Fedora Update System 2010-02-19 19:23:46 EST
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.
Comment 22 Fedora Update System 2010-02-19 19:25:25 EST
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.