Bugzilla – Bug 59963
VUL-0: CVE-2004-0888: xpdf and code based on it
Last modified: 2021-09-27 14:41:49 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
<!-- SBZ_reproduce --> ...
In addition to xpdf, gpdf and kpdf "pdftohtml" is affected, too.
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 :-)
Ok, can you please go ahead with the patch? The fix should also be suitable for the kpdf and other derived pdf viewers.
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.
xpdf 2 is the finest C++ code (with classes) ever :-)
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).
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.
I'll have a look...
Created attachment 24191 [details] kpdf-CESA-2004-007.diff Adrian, this is the kpdf patch.
Karl, I submitted packages for 9.0, 9.1, and STABLE
patchinfo file for box: /work/src/done/PATCHINFO/pdftohtml.patch.box
Vladimir, could you submit new packages? The fix for xpdf is attached. We can create patchinfos then.
Packages for 8.1, 8.2 and 9.0 are submitted.
So I guess maintained is noit affected and so is SL 9.1. I will submit patchinfos.
Created attachment 24366 [details] patchinfo file for box ...
Please tell suse-dist to build packages now.
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.
patchinfo files submitted.
The only one missing is kpdf AFAIK.
coordinated release date is 12th Oct. 1400 UTC
CVE id ?
none so far...
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.
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
Created attachment 24854 [details] New patch for the issues described in advisory plus a few more I found. ...
Thx!
xpdf packages and patchinfo are submited.
Thank you!
Karl, new pdftohtml package submitted
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.
when is the public disclosure date&time now? I've heard it was slipped
what is the latest patch?
CRD: 20. oct, 1400UTC ptach, as attached AFAIK
new CRD will be 21. oct. 1400 UTC
advisory released. only missing package is cups.
Patchinfo for cups?
/work/src/done/PATCHINFO/cups.patch.box /mounts/work/src/done/PATCHINFO/cups.patch.maintained
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. :-)
Thx Klaus.
cups packages approved