oCERT reported an integer overflow flaw during the C++ object allocation leading to a heap overflow discovered by Chris Rohlf, affecting xpdf's / poppler's ObjectStream::ObjectStream (XRef.cc). objs = new Object[nObjects]; As new[] as implemented in gcc / libstdc++ does not perform integer overflow check [1], sufficiently large nObjects value (read from the input PDF file) can cause integer overflow / wrap when multiplied by sizeof(Object) resulting in insufficient memory allocation. Affected code was introduced in Xpdf 3.00, packages including / based on this version are affected by this flaw. In Red Hat Enterprise Linux, that means: - xpdf - el4 - gpdf - el4 - poppler - el5 - kdegraphics - el4, el5 - cups - el5 - tetex - el5 Patch attempting to address this was previously added to poppler, but it incorrectly used sizeof(int) instead of sizeof(Object) [2] and hence was insufficient. [1] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19351 [2] http://cgit.freedesktop.org/poppler/poppler/commit/?id=c36d8afc http://cgit.freedesktop.org/poppler/poppler/commit/?id=f41fa9ee Acknowledgements: Red Hat would like to thank Chris Rohlf for reporting this issue.
Created attachment 363288 [details] Poppler upstram patch This patch was proposed by poppler upstream to address this flaw. It builds on top of the previously mentioned git commits c36d8afc and f41fa9ee.
Xpdf upstream's proposed fix is to use hard-coded upper limit for nObjects: if (nObjects > 1000000) { error(errSyntaxError, -1, "Too many objects in an object stream"); goto err1; } According to Derek, it's unlikely to have more than couple of hundreds of objects in one object stream in non-malicious PDFs, as lot more objects would be bad from the performance point of view.
Created attachment 363744 [details] upstream xpdf patch This is the upstream patch that should address both the ImageStream::ImageStream issue and ObjectStream::ObjectStream limit.
Created attachment 364871 [details] Final xpdf 3.02pl4 patch Fixes following issues: CVE-2009-1188/CVE-2009-3603, CVE-2009-3604, CVE-2009-3606, CVE-2009-3608, CVE-2009-3609
Fixed now in xpdf 3.02pl4: ftp://ftp.foolabs.com/pub/xpdf/xpdf-3.02pl4.patch poppler patches should be committed soon.
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 4 Via RHSA-2009:1503 https://rhn.redhat.com/errata/RHSA-2009-1503.html
This issue has been addressed in following products: Red Hat Enterprise Linux 5 Via RHSA-2009:1504 https://rhn.redhat.com/errata/RHSA-2009-1504.html
This issue has been addressed in following products: Red Hat Enterprise Linux 5 Via RHSA-2009:1513 https://rhn.redhat.com/errata/RHSA-2009-1513.html
This issue has been addressed in following products: Red Hat Enterprise Linux 4 Via RHSA-2009:1512 https://rhn.redhat.com/errata/RHSA-2009-1512.html
> In Red Hat Enterprise Linux, that means: - xpdf - el4 ( ... and so on) There is currently xpdf-3.02-13.el5 in epel so RHEL5 is affected here, if indirectly, too. Also there are corresponding Fedora packages and so far fixed xpdf did not show up even in koji.
(In reply to comment #15) > Fixed now in xpdf 3.02pl4: > ftp://ftp.foolabs.com/pub/xpdf/xpdf-3.02pl4.patch > > poppler patches should be committed soon. Equivalent poppler git commit: http://cgit.freedesktop.org/poppler/poppler/commit/?id=1082e1671a
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.
oCERT advisory: http://www.ocert.org/advisories/ocert-2009-016.html poppler fixed now in version 0.12.1: http://poppler.freedesktop.org/releases.html
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.
This should still affect koffice 1.x (2.x uses poppler) and pdfedit shipped in Fedora, as they embed xpdf code copy too. I've not got to having a closer look at those.
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-3908 has been also (by mistake) assigned for this: Name: CVE-2009-3908 Status: Candidate URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-3908 Final-Decision: Interim-Decision: Modified: Proposed: Assigned: 20091109 Category: ** REJECT ** DO NOT USE THIS CANDIDATE NUMBER. ConsultIDs: CVE-2009-3608. Reason: This candidate is a duplicate of CVE-2009-3608. A typo caused the wrong ID to be used. Notes: All CVE users should reference CVE-2009-3608 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.
This issue has been addressed in following products: Red Hat Enterprise Linux 5 Via RHSA-2010:0400 https://rhn.redhat.com/errata/RHSA-2010-0400.html