Bugzilla – Bug 58082
VUL-0: CVE-2005-0206: xpdf: multiple integer overflows
Last modified: 2021-09-28 07:53:21 UTC
Hi, this report from Chris Evan reached us through vendor-sec. (private) Date: Fri, 16 Jul 2004 01:11:53 +0100 (BST) From: chris@scary.beasts.org To: vendor-sec@lst.de Subject: [vendor-sec] xpdf nasty issues (and gpdf, kpdf) Hi, Below is appended an advisory I just put together for xpdf. It's a bit of a can of worms, unfortunately. I'll try and enumerate why: - gpdf and, as far as I'm aware, kpdf, re-use the xpdf code. - However, I don't think the re-use is via a library (shared or otherwise). gpdf, at least, seems to have a copy (possibly even a fork) of an older xpdf in it. - The xpdf code varies a moderate amount between v3.0 and previous versions. gpdf seems to be based off a previous version. - The sorts of issues I highlight in my advisory are scattered fairly far and wide throughout the xpdf code. There's a fair bit of work going to be needed in order to patch them all. - I haven't yet proved anything other than xpdf-3.0 is fully exploitable. All versions are easily crashable, though, so it doesn't bode well. Does anyone want to take this on? It's a bit too much for me to co-ordinate in the limited time I get to spend on security:( The release date for the advisory is, of course, "when it's all fixed and ready". Cheers Chris CESA-2004-002 - rev 1 xpdf-3.0 multiple integer overflow and integer arithmetic flaws =============================================================== Programs affected: xpdf, gpdf and kpdf. Severity: Compromise of account used to browse malicious PDF file. This advisory lists code flaws discovered by inspection of the xpdf-3.0 code. Note that the GNOME and KDE PDF browsers seem to be based on xpdf. The specific flaws exposed below are apply to xpdf-3.0; earlier versions do not neccessarily suffer from them. However, it is very important to note that earlier versions (and programs such as gpdf based off earlier versions) do have serious instances of integer overflow / signedness / arithmetic problems. It just happens that the demo PDF files were developed against xpdf-3.0. Flaw 1. Impact: xpdf-3.0 hangs whilst consuming 100% CPU Demo PDF: http://scary.beasts.org/misc/bad1.pdf The code flaw is a logic error in a loop that never terminates if a large enough integer value is present in the PDF file, at XRef.cc, line 373. Flaw 2. Impact: xpdf-3.0 crashes due to an out-of-bounds read Demo PDF: http://scary.beasts.org/misc/bad2.pdf The code flaw is failure to prevent negative (or large) values in the PDF file indexing before the start of an array, at XRef.cc, line 403. Flaw 3. Impact: xpdf-3.0 crashes due to heap corruption caused and controlled by a malicious PDF file (i.e. exploitable to gain control over xpdf) Demo PDF: http://scary.beasts.org/misc/bad3.pdf The code flaw is failure to prevent negative (or large) values in the PDF file indexing and writing before that start and after the end of an array, at XRef.cc, line 595 and around. It is almost certainly exploitable to take control of xpdf. Flaw n. There are multiple additional instances of integer signedness, overflow and arithmetic problems scattered throughout the xpdf code. CESA-2004-002 - rev 1 Chris Evans chris@scary.beasts.org _______________________________________________ Vendor Security mailing list Vendor Security@lst.de https://www.lst.de/cgi-bin/mailman/listinfo/vendor-sec
<!-- SBZ_reproduce --> -
pdftohtml 0.36 comes with xpdf 2.02: -updated Xpdf to 2.02 (security fix) maybe, it is also affected.
Created attachment 22235 [details] patchinfo-box.xpdf
Created attachment 22236 [details] patchinfo.xpdf
Karl, can you have a look at your package please.
Vladimir, do you have seen some patches somewhere?
Chris Evan (#1) says: The specific flaws exposed below are apply to xpdf-3.0; earlier versions do not neccessarily suffer from them. However, it is very important to note that earlier versions (and programs such as gpdf based off earlier versions) do have serious instances of integer overflow / signedness / arithmetic problems. and incidentally the provided PDF files (bad1,pdf, bd2.pdf) make pdftohtml on 9.1 crash. To fix pdftohtml replacing the old included xpdf version with the fixed 3.x version is the way to go. Unfortunately, upstream maintainers of pdftohtml do not seem to have the time to work on this issue. And my knowledge in C++ equals to zero. I can only offer to write a wrapper script that explains the security issues to the user and asks him whether he wants to run pdftohtml nevertheless... Recommendation by my side: users must not process foreign PDF files with pdftohtml resp. ought to deinstall the package.
Karl, ok let's wait till the mainstream autor fixed it or we got an easy solution. I'll write an statement about it in the advisory.
Created attachment 23223 [details] xref.patch Date: Tue, 07 Sep 2004 16:18:45 -0400 From: Josh Bressers <bressers@redhat.com> To: chris@scary.beasts.org Cc: Thomas Biege <thomas@suse.de>, vendor-sec@lst.de Subject: Re: [vendor-sec] xpdf nasty issues (and gpdf, kpdf) Parts/Attachments: 1 Shown 23 lines Text 2 Shown 314 lines Text, "xref.patch" ---------------------------------------- > My aim here is to get the xpdf / gpdf / kpdf etc. people to collaborate to > understand and then fix the problems. > I think this approach is preferable because my quick scan of the code > located a large number of probable issues. It was not an exhaustive scan, > although one does need doing. I think this is best done by the software > authors. I've received this patch from Derek Nooburg (derekn@foolabs.com). I looked it over, it seems OK, I've not had a good look through the rest of xpdf 3.0 yet. I figured it's probably best to get this out in the open before someone else duplicates the work. At the very least this should fix the problems Chris' demo pdf files trigger. As for a disclosure date, if nothing else big is found, it has been made known to me that the KDE group would like this fix in xpdf so they can have this fixed in the next version of KDE which has a current target date of early October. -- JB [ Part 2: "xref.patch" ]
Date: Tue, 7 Sep 2004 23:27:33 +0100 (BST) From: chris@scary.beasts.org To: Josh Bressers <bressers@redhat.com> Cc: Thomas Biege <thomas@suse.de>, vendor-sec@lst.de Subject: Re: [vendor-sec] xpdf nasty issues (and gpdf, kpdf) Hi- On Tue, 7 Sep 2004, Josh Bressers wrote: > I've received this patch from Derek Nooburg (derekn@foolabs.com). I looked > it over, it seems OK, I've not had a good look through the rest of xpdf 3.0 > yet. I figured it's probably best to get this out in the open before > someone else duplicates the work. Are you sure? I'm unsure which is riskier: - Delaying and risking a leak or parallel discovery. - Releasing, and directing black hats towards an area which likely has more issues awaiting discovery. I've asked the xpdf maintainers if they think there might be more issues beyond the ones I pointed out. Will forward any response. > As for a disclosure date, if nothing else big is found, it has been made > known to me that the KDE group would like this fix in xpdf so they can have > this fixed in the next version of KDE which has a current target date of > early October. Yeah, I've just been talking to the KDE folks. There are complications here: KDE 3.3 will be based on the xpdf v3.0 code, which suffers from the holes I pointed out. All released versions of kpdf and possibly gpdf are based on v2 of the xpdf code, which is quite different. My advisory only has v3.0 flaws, but notes that v2 appears to suffer the same sort of issues. I've taken an action to try and find some specific problems with v2. Cheers Chris
I think bug 59963 is a duplicate of this one. please check...
This bug here deal with 3.x, but bug 59963's focus is 2.x.
Vladimir, does the attached patch work?
Yes, it prevents crashes on the bad pdf files above.
Can you submit the new packages please? Patchinfo files are attached to this bugreport. Thank you!
OK, but I still don't have a patch for xpdf 2.0 in 9.0 and older.
Packages and patchinfos for 9.1 and stable submitted.
Is this published meanwhile? KDE 3.3.1 uses xpdf 3 and I'm unsure if I can release it patched or not ;(
coordinated release date is 12th Oct. 1400 UTC
Created attachment 24853 [details] additional patch for xpdf2 issues moved to xpdf3 ...
Thank you Sebastian! Vladimir, we have to do it again. The old patchinfo files (+ a space or such) can be used.
Created attachment 24858 [details] The new ultimate patch. Combines xref.patch and my patch. ...
Packages and patchinfos are submitted.
That means the kdegraphics 3.3.1 packages (in stable) aren't any good either ;(
jupp.
CAN-2004-0888: Multiple integer overflow issues affecting xpdf-2.0 and xpdf-3.0 and things like cups which have embedded versions of xpdf-0*. These can result in writing an arbitrary byte to an attacker controlled location which probably could lead to arbitrary code execution. CAN-2004:0889: Multiple integer overflow issues affecting xpdf-3.0 only. These can result in DoS or possibly arbitrary code execution. Infinite loop logic error affecting xpdf-3.0 only. I don't think this is a security vulnerability for xpdf - now perhaps if this version of xpdf is embedded into something that parses pdf's automatically like CUPS (but CUPS embedds a version without this flaw). So I don't think this deserves a CVE name. I'm willing to be convinced otherwise though.
adding Dirk to the CC list - he handles the kpdf issue for KDE
CRD: 20. oct., 1400 UTC
new CRD: 21. oct. 1400 UTC
Created attachment 25136 [details] xpdf-CESA-2004-007-xpdf2-newer.diff added missing check for sizeof(Ref)
Created attachment 25139 [details] xpdf-CESA-2004-002-xpdf3-newer.diff
there was 1 missing sizeof() check in Catalog.cc, spotted by mls. redid xpdf3 and xpdf2 patch. resubmitted xpdf, gpdf, pdftohtml for all distros. (i think)
adv released. cupy only missing package
Which patch does what? In short please.
<!-- SBZ_reopen -->Reopened by meissner@suse.de at Fri Oct 29 15:21:07 2004, took initial reporter thomas@suse.de to cc
not fixed for 64bit
Created attachment 25625 [details] libgoo-sizet.patch make sure we pass size_t to goo helper functions, instead of int.
explanation: the problem we have is that our sizeof() checks operate on "size_t" which is 64bit on 64bit systems. However, gmalloc/grealloc were only passed "int" aka 32bit entities, which resulted in truncation anyway -> integer overflow in a ... different way yet again.
Created attachment 25633 [details] xpdf2-underflow.patch xpdf2 only patch to check for more < 0 conditions which lead to crashes on bad5.pdf and bad4.pdf
how about choosing the approach suggested by the debian people which works on both 32 bit and 64bit and is very safe against future compiler optimisation: if ( (unsigned int) foo >= INT_MAX / sizeof(int))
Done with: 8.1/pdf2html 8.2/pdf2html 9.0/pdftohtml 9.1/pdftohtml 9.2/pdftohtml
Made patches for cups: 8.1/SLES8/UL, 8.2, 9.0, 9.1/SLES9, 9.2 testing-team: Tested only 9.2-i386 as my testmachine is still in repair. security-team please handle putonftp, etc.
cups patchinfos done
Where is gpdf?
ok, so whom do I have my firstborn child to get an answer?
dirk: No one. the approach we use now works as is. later we will take whatever upstream sends us. And I really hope the xpdf guys get their act together and merge some of those fixes. mls: i will do gpdf.
gpdf: I need the NLD version, too.
kdegraphics3 packages have been submitted for 9.1 and 9.2. They are not tested ...
Which patch I need for xpdf2 and xpdf1 based libpdf of teTeX?
werner, you need: xpdf-CESA-2004-007-xpdf2-newer.diff (should already be applied in tetex) and: libgoo-sizet.patch xpdf2-underflow.patch I think.
there's a patch available from http://www.foolabs.com/xpdf/download.html
cups packages approved
64bit bug is tracked as - If folks here used an incorrect patch then if you do updates you need to use CAN-2005-0206 to refer to the "missing protection for 64-bit architectures". (just for completeness)
CVE-2005-0206: CVSS v2 Base Score: 7.5 (AV:N/AC:L/Au:N/C:P/I:P/A:P)