Bug 59963 (CVE-2004-0888)

Summary: VUL-0: CVE-2004-0888: xpdf and code based on it
Product: [Novell Products] SUSE Security Incidents Reporter: Sebastian Krahmer <krahmer>
Component: IncidentsAssignee: Security Team bot <security-team>
Status: RESOLVED FIXED QA Contact: Security Team bot <security-team>
Severity: Normal    
Priority: P3 - Medium CC: adrian.schroeter, dmueller, gnome-bugs, ke, nadvornik, qa-bugs, security-team
Version: unspecified   
Target Milestone: ---   
Hardware: All   
OS: Linux   
Whiteboard: 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: 58082    
Bug Blocks:    
Attachments: The patch for the issues in the advisory
kpdf-CESA-2004-007.diff
patchinfo file for box
New patch for the issues described in advisory plus a few more I found.

Description Sebastian Krahmer 2004-09-10 17:20:03 UTC 
ate: Wed, 8 Sep 2004 23:13:00 +0100 (BST)
From: chris@scary.beasts.org
To: vendor-sec@lst.de
Subject: [vendor-sec] xpdf-2.03 issues

Hi,

Upon suggestion from Dirk Muller of KDE, I located some specific problems
with the xpdf-2.03 codebase (which is much more commonly deployed than
v3.00). xpdf-3.00 may share these issues.
I'll forward this to the xpdf people to get patches.

The sheer size of xpdf is only just becoming apparent to me. It has
massive numbers of home-brew decoders as far as I can tell - e.g.
JPEG, LZW, PNG, RLE, etc.

Cheers
Chris
CESA-2004-007 - rev 1

xpdf-2.03 example integer overflow and integer arithmetic flaws
===============================================================

Programs affected: xpdf, gpdf and kpdf.
Severity: Unassessed.

This advisory lists code flaws discovered by inspection of the xpdf-2.03
code. Note that the GNOME and KDE PDF browsers seem to be based on xpdf.
This advisory follows on from CESA-2004-002, which looked at xpdf-3.0. In
response to feedback, xpdf-2.03 was briefly examined. The reason for this is
that xpdf-2.03 and derivatives are currently very common. For example, kpdf
in all released versions is based on xpdf-2 (this may change with KDE 3.3.1).

Flaw 1. Multiple integer overflows possible when allocating memory.

For example, XRef.cc: 79
    entries = (XRefEntry *)gmalloc(size * sizeof(XRefEntry));
"size" is an arbitrary signed int and comes from the PDF.
XRef.cc: 286
    if (first + n > size) {
      newSize = first + n;
      entries = (XRefEntry *)grealloc(entries, newSize * sizeof(XRefEntry));
"first" and "n" are arbitrary signed ints and come from the PDF. Not only
might the addition overflow, but also games can be played by makking one or
both negative. After the addition, the multiplication for thr grealloc() might
overflow.
Catalog.cc:68
  pages = (Page **)gmalloc(pagesSize * sizeof(Page *));
  pageRefs = (Ref *)gmalloc(pagesSize * sizeof(Ref));
"pageSize" is an arbitrary signed int from the PDF.

Demo PDF: http://scary.beasts.org/misc/bad5.pdf

Flaw 2. Integer overflows leading to out of bounds write.

XRef.cc:436
        if (num >= size) {
    newSize = (num + 1 + 255) & ~255;
    entries = (XRefEntry *)
                grealloc(entries, newSize * sizeof(XRefEntry));
    for (i = size; i < newSize; ++i) {
      entries[i].offset = 0xffffffff;
      entries[i].used = gFalse;
    }
    size = newSize;
        }
        if (!entries[num].used || gen >= entries[num].gen) {
    entries[num].offset = pos - start;
    entries[num].gen = gen;
    entries[num].used = gTrue;
        }

"num" and "gen" are arbitrary signed ints from the PDF file. This causes a
problem with integer overflow on the memory allocation. But more seriously,
a negative value of "num" leads (with minor restrictions) to an out of bounds
write to the heap[*]. One of the values written is "gen" - an arbitrary int
from the PDF file.
[*] - with a sufficiently negative value of "num", I don't see why the write
access couldn't be so out of bounds that it in fact writes into the stack.

Demo PDF: http://scary.beasts.org/misc/bad4.pdf


CESA-2004-007 - rev 1
Chris Evans
chris@scary.beasts.org
Comment 1 Sebastian Krahmer 2004-09-10 17:20:03 UTC 
<!-- SBZ_reproduce  -->
...
Comment 2 Karl Eichwalder 2004-09-13 13:20:51 UTC 
In addition to xpdf, gpdf and kpdf "pdftohtml" is affected, too.
Comment 3 Sebastian Krahmer 2004-09-24 17:15:53 UTC 
Created attachment 23923 [details]
The patch for the issues in the advisory

I created this fix, sent it to vendor-sec and nobody complained yet,
so i assume its correct :-)
Comment 4 Sebastian Krahmer 2004-09-27 21:25:52 UTC 
Ok, can you please go ahead with the patch? The fix should
also be suitable for the kpdf and other derived pdf
viewers.
Comment 5 Adrian Schröter 2004-09-27 21:48:46 UTC 
the patch got partly applied for 9.2. kpdf has some rewritten code it seems, 
at least it uses C++ classes, xpdf doesn't seem to have some.
Comment 6 Sebastian Krahmer 2004-09-27 21:54:58 UTC 
xpdf 2 is the finest C++ code (with classes) ever :-)
Comment 7 Karl Eichwalder 2004-09-27 21:56:27 UTC 
It would be great, if a C++/security guru would fix pdftohtml.  The next 2 or 3
days, I'm mostly busy with SL 9.2 (translations, release-notes, testing, other
packages).
Comment 8 Adrian Schröter 2004-09-27 22:01:13 UTC 
oh.. 
 
anyway, one hunk seems not to be needed anymore, since there is a new parser 
class. /work/users/adrian/kde33/kdegraphics3/ , if you want to have a look.
Comment 9 Thomas Biege 2004-09-29 16:49:29 UTC 
I'll have a look...
Comment 10 Thomas Biege 2004-09-29 18:12:07 UTC 
Created attachment 24191 [details]
kpdf-CESA-2004-007.diff

Adrian,
this is the kpdf patch.
Comment 11 Thomas Biege 2004-09-29 19:25:21 UTC 
Karl, 
I submitted packages for 9.0, 9.1, and STABLE
Comment 12 Thomas Biege 2004-09-29 19:28:40 UTC 
patchinfo file for box: 
/work/src/done/PATCHINFO/pdftohtml.patch.box
Comment 13 Sebastian Krahmer 2004-09-29 22:13:43 UTC 
Vladimir, could you submit new packages? The fix for xpdf is attached.
We can create patchinfos then.
Comment 14 Vladimir Nadvornik 2004-09-29 23:06:36 UTC 
Packages for 8.1, 8.2 and 9.0 are submitted.
Comment 15 Sebastian Krahmer 2004-10-01 18:31:38 UTC 
So I guess maintained is noit affected and so is SL 9.1.
I will submit patchinfos.
Comment 16 Sebastian Krahmer 2004-10-01 18:38:35 UTC 
Created attachment 24366 [details]
patchinfo file for box

...
Comment 17 Sebastian Krahmer 2004-10-01 18:39:57 UTC 
Please tell suse-dist to build packages now.
Comment 18 Marcus Meissner 2004-10-04 16:43:53 UTC 
dirk, there is no public disclosure date yet for it, but I am trying to get 
one. coolo said to cc me for the KDE side of the problem.
Comment 19 Thomas Biege 2004-10-04 22:16:18 UTC 
patchinfo files submitted.
Comment 20 Thomas Biege 2004-10-04 22:16:47 UTC 
The only one missing is kpdf AFAIK.
Comment 21 Thomas Biege 2004-10-05 06:02:29 UTC 
coordinated release date is 12th Oct. 1400 UTC
Comment 22 Dirk Mueller 2004-10-10 22:59:41 UTC 
CVE id ?
Comment 23 Thomas Biege 2004-10-11 15:26:24 UTC 
none so far...
Comment 24 Klaus Singvogel 2004-10-11 19:44:27 UTC 
Cups is affected either. 
The internal and default filter "pdftops" is a stripped xpdf version and the 
patch is working in latest version. 
Sorry for the late response.
Comment 25 Marcus Meissner 2004-10-11 20:04:01 UTC 
pdftops in cups needs: 
/work/SRC/old-versions/8.1/UL/all/xpdf/xpdf-overflow.patch 
/work/SRC/old-versions/8.1/UL/all/xpdf/xpdf-CESA-2004-007.diff 
 
replace filename ending .cc by .cxx
Comment 26 Sebastian Krahmer 2004-10-11 21:27:36 UTC 
Created attachment 24854 [details]
New patch for the issues described in advisory plus a few more I found.

...
Comment 27 Thomas Biege 2004-10-11 21:30:04 UTC 
Thx!
Comment 28 Vladimir Nadvornik 2004-10-11 23:22:58 UTC 
xpdf packages and patchinfo are submited.
Comment 29 Thomas Biege 2004-10-12 15:35:06 UTC 
Thank you!
Comment 30 Thomas Biege 2004-10-12 17:49:13 UTC 
Karl, 
new pdftohtml package submitted
Comment 31 Thomas Biege 2004-10-12 22:07:51 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 32 Dirk Mueller 2004-10-12 22:24:49 UTC 
when is the public disclosure date&time now? I've heard it was slipped
Comment 33 Dirk Mueller 2004-10-13 00:18:10 UTC 
what is the latest patch?
Comment 34 Thomas Biege 2004-10-13 14:52:45 UTC 
CRD: 20. oct, 1400UTC 
 
ptach, as attached AFAIK
Comment 35 Thomas Biege 2004-10-15 17:17:03 UTC 
new CRD will be 21. oct. 1400 UTC
Comment 36 Thomas Biege 2004-10-26 18:52:14 UTC 
advisory released. only missing package is cups.
Comment 37 Michael Schröder 2004-10-26 21:25:13 UTC 
Patchinfo for cups?
Comment 38 Thomas Biege 2004-10-26 21:45:48 UTC 
/work/src/done/PATCHINFO/cups.patch.box 
/mounts/work/src/done/PATCHINFO/cups.patch.maintained
Comment 39 Klaus Singvogel 2004-10-26 21:47:46 UTC 
Made cups patches (packages) for: UL1/SLES8/8.1, 8.2, 9.0, 9.1/SLES9/SLD, 9.2  
  
Couldn't test older versions, as my test machine is currently broken (cpu fan  
broken). 9.2 patches seem to work. :-)
Comment 40 Thomas Biege 2004-10-26 21:49:19 UTC 
Thx Klaus.
Comment 41 Thomas Biege 2004-11-23 19:47:05 UTC 
cups packages approved