Bug 526877 (CVE-2009-3606) - CVE-2009-3606 xpdf/poppler: PSOutputDev::doImageL1Sep integer overflow
Summary: CVE-2009-3606 xpdf/poppler: PSOutputDev::doImageL1Sep integer overflow
Keywords:
Status: CLOSED ERRATA
Alias: CVE-2009-3606
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
URL:
Whiteboard:
Depends On: 527456 527457 527468 527469 527470 530890 833916
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-10-02 09:22 UTC by Tomas Hoger
Modified: 2019-09-29 12:32 UTC (History)
10 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2010-07-08 16:27:49 UTC
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2009:1500 0 normal SHIPPED_LIVE Important: xpdf security update 2009-10-15 08:37:08 UTC
Red Hat Product Errata RHSA-2009:1501 0 normal SHIPPED_LIVE Important: xpdf security update 2009-10-15 08:34:24 UTC
Red Hat Product Errata RHSA-2009:1502 0 normal SHIPPED_LIVE Important: kdegraphics security update 2009-10-15 08:26:05 UTC

Description Tomas Hoger 2009-10-02 09:22:30 UTC
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 09:46:14 UTC
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 08:26:20 UTC
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 08:34:35 UTC
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 08:37:33 UTC
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-21 00:47:41 UTC
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-21 00:54:24 UTC
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 12:18:55 UTC
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 12:20:21 UTC
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 07:04:57 UTC
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 07:15:00 UTC
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 18:31:54 UTC
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 11:54:53 UTC
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-20 00:11:28 UTC
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-20 00:23:46 UTC
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-20 00:25:25 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.