Bug 58082 (CVE-2005-0206)

Summary: VUL-0: CVE-2005-0206: xpdf: multiple integer overflows
Product: [Novell Products] SUSE Security Incidents Reporter: Marcus Meissner <meissner>
Component: IncidentsAssignee: Thomas Biege <thomas>
Status: RESOLVED FIXED QA Contact: Security Team bot <security-team>
Severity: Normal    
Priority: P3 - Medium CC: coolo, dmueller, gnome-bugs, kde-maintainers, ke, patch-request, security-team, thomas, werner
Version: unspecified   
Target Milestone: ---   
Hardware: All   
OS: Linux   
Whiteboard: CVE-2005-0206: CVSS v2 Base Score: 7.5 (AV:N/AC:L/Au:N/C:P/I:P/A:P) CVSSv2:NVD:CVE-2004-0888:10.0:(AV:N/AC:L/Au:N/C:C/I:C/A:C) CVSSv2:RedHat:CVE-2004-0888:5.8:(AV:A/AC:L/Au:N/C:P/I:P/A:P)
Found By: --- Services Priority:
Business Priority: Blocker: ---
Marketing QA Status: --- IT Deployment: ---
Bug Depends on:    
Bug Blocks: 58084, 59963    
Attachments: patchinfo-box.xpdf
patchinfo.xpdf
xref.patch
additional patch for xpdf2 issues moved to xpdf3
The new ultimate patch. Combines xref.patch and my patch.
xpdf-CESA-2004-007-xpdf2-newer.diff
xpdf-CESA-2004-002-xpdf3-newer.diff
libgoo-sizet.patch
xpdf2-underflow.patch

Description Thomas Biege 2004-07-16 19:32:57 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
Comment 1 Thomas Biege 2004-07-16 19:32:57 UTC
<!-- SBZ_reproduce  -->
-
Comment 2 Karl Eichwalder 2004-07-16 20:08:13 UTC
pdftohtml 0.36 comes with xpdf 2.02:

-updated Xpdf to 2.02 (security fix)

maybe, it is also affected.
Comment 3 Thomas Biege 2004-07-16 20:30:23 UTC
Created attachment 22235 [details]
patchinfo-box.xpdf
Comment 4 Thomas Biege 2004-07-16 20:31:04 UTC
Created attachment 22236 [details]
patchinfo.xpdf
Comment 5 Thomas Biege 2004-07-28 15:43:59 UTC
Karl, 
can you have a look at your package please. 
Comment 6 Thomas Biege 2004-07-28 15:45:03 UTC
Vladimir, 
do you have seen some patches somewhere? 
Comment 7 Karl Eichwalder 2004-07-28 16:23:13 UTC
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.
Comment 8 Thomas Biege 2004-07-28 22:47:33 UTC
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. 
Comment 9 Thomas Biege 2004-09-08 17:55:05 UTC
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" ]
Comment 10 Thomas Biege 2004-09-08 18:08:35 UTC
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 
 
Comment 11 Thomas Biege 2004-09-10 21:06:57 UTC
I think bug 59963 is a duplicate of this one. please check... 
Comment 12 Karl Eichwalder 2004-09-13 13:19:29 UTC
This bug here deal with 3.x, but bug 59963's focus is 2.x.
Comment 13 Thomas Biege 2004-09-13 20:13:28 UTC
Vladimir, 
does the attached patch work? 
Comment 14 Vladimir Nadvornik 2004-09-13 20:37:43 UTC
Yes, it prevents crashes on the bad pdf files above. 
 
Comment 15 Thomas Biege 2004-09-14 18:55:20 UTC
Can you submit the new packages please? Patchinfo files are attached to this 
bugreport. 
 
Thank you! 
Comment 16 Vladimir Nadvornik 2004-09-14 19:06:12 UTC
OK, but I still don't have a patch for xpdf 2.0 in 9.0 and older. 
Comment 17 Vladimir Nadvornik 2004-09-14 21:13:03 UTC
Packages and patchinfos for 9.1 and stable submitted. 
Comment 18 Stephan Kulow 2004-10-04 16:39:51 UTC
Is this published meanwhile? KDE 3.3.1 uses xpdf 3 and I'm unsure if I can 
release it patched or not ;( 
Comment 19 Thomas Biege 2004-10-05 06:01:07 UTC
coordinated release date is 12th Oct. 1400 UTC 
Comment 20 Sebastian Krahmer 2004-10-11 21:03:04 UTC
Created attachment 24853 [details]
additional patch for xpdf2 issues moved to xpdf3

...
Comment 21 Thomas Biege 2004-10-11 21:29:39 UTC
Thank you Sebastian! 
 
Vladimir, we have to do it again. The old patchinfo files (+ a space or such) 
can be used. 
Comment 22 Sebastian Krahmer 2004-10-11 22:01:44 UTC
Created attachment 24858 [details]
The new ultimate patch. Combines xref.patch and my patch.

...
Comment 23 Vladimir Nadvornik 2004-10-12 19:03:14 UTC
Packages and patchinfos are submitted. 
Comment 24 Stephan Kulow 2004-10-12 21:01:13 UTC
That means the kdegraphics 3.3.1 packages (in stable) aren't any good either ;( 
Comment 25 Thomas Biege 2004-10-12 21:29:23 UTC
jupp. 
Comment 26 Thomas Biege 2004-10-12 22:08:38 UTC
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. 
Comment 27 Stephan Kulow 2004-10-13 03:33:55 UTC
adding Dirk to the CC list - he handles the kpdf issue for KDE 
Comment 28 Thomas Biege 2004-10-13 14:53:24 UTC
CRD: 20. oct., 1400 UTC 
 
Comment 29 Thomas Biege 2004-10-15 15:43:17 UTC
new CRD: 21. oct. 1400 UTC 
Comment 30 Marcus Meissner 2004-10-18 22:46:39 UTC
Created attachment 25136 [details]
xpdf-CESA-2004-007-xpdf2-newer.diff

added missing check for sizeof(Ref)
Comment 31 Marcus Meissner 2004-10-18 23:19:35 UTC
Created attachment 25139 [details]
xpdf-CESA-2004-002-xpdf3-newer.diff
Comment 32 Marcus Meissner 2004-10-18 23:20:51 UTC
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) 
 
 
 
 
Comment 33 Thomas Biege 2004-10-26 18:52:48 UTC
adv released. cupy only missing package 
Comment 34 Dr. Werner Fink 2004-10-26 20:08:45 UTC
Which patch does what? In short please.
Comment 35 Marcus Meissner 2004-10-29 21:21:07 UTC
<!-- SBZ_reopen -->Reopened by meissner@suse.de at Fri Oct 29 15:21:07 2004, took initial reporter thomas@suse.de to cc
Comment 36 Marcus Meissner 2004-10-29 21:21:07 UTC
not fixed for 64bit 
Comment 37 Marcus Meissner 2004-10-29 21:21:46 UTC
Created attachment 25625 [details]
libgoo-sizet.patch

make sure we pass size_t to goo helper functions, instead of int.
Comment 38 Marcus Meissner 2004-10-29 21:23:13 UTC
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. 
Comment 39 Marcus Meissner 2004-10-29 21:51:53 UTC
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
Comment 40 Dirk Mueller 2004-11-02 01:08:27 UTC
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)) 
 
 
Comment 41 Karl Eichwalder 2004-11-03 23:14:14 UTC
Done with:
8.1/pdf2html
8.2/pdf2html
9.0/pdftohtml
9.1/pdftohtml
9.2/pdftohtml

Comment 42 Klaus Singvogel 2004-11-04 01:34:04 UTC
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. 
Comment 43 Thomas Biege 2004-11-05 03:21:16 UTC
cups patchinfos done 
Comment 44 Michael Schröder 2004-11-06 01:32:29 UTC
Where is gpdf?
Comment 45 Dirk Mueller 2004-11-07 22:18:04 UTC
ok, so whom do I have my firstborn child to get an answer? 
 
 
Comment 46 Marcus Meissner 2004-11-08 21:11:04 UTC
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. 
Comment 47 Michael Schröder 2004-11-09 04:03:03 UTC
gpdf: I need the NLD version, too.
Comment 48 Adrian Schröter 2004-11-09 20:44:37 UTC
kdegraphics3 packages have been submitted for 9.1 and 9.2. They are not 
tested ... 
Comment 49 Dr. Werner Fink 2004-11-12 22:23:48 UTC
Which patch I need for xpdf2 and xpdf1 based libpdf of teTeX?
Comment 50 Marcus Meissner 2004-11-12 22:27:03 UTC
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. 
Comment 51 Dirk Mueller 2004-11-20 22:10:47 UTC
there's a patch available from 
 
http://www.foolabs.com/xpdf/download.html 
Comment 52 Thomas Biege 2004-11-23 19:47:26 UTC
cups packages approved 
Comment 53 Marcus Meissner 2005-02-14 22:46:19 UTC
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) 
Comment 54 Thomas Biege 2009-10-13 20:53:57 UTC
CVE-2005-0206: CVSS v2 Base Score: 7.5 (AV:N/AC:L/Au:N/C:P/I:P/A:P)