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. ----------------------- Planned announce day is 21. Oct. 1400 UTC
Created attachment 42122 [details, diff] xpdf-CESA-2004-007-xpdf2.diff xpdf2
Created attachment 42123 [details, diff] xpdf-CESA-2004-007-xpdf3.diff2 xpdf3
From: Sebastian Krahmer <krahmer@suse.de> To: chris@scary.beasts.org Cc: vendor-sec@lst.de Subject: [vendor-sec] Xpdf patches, combined Date: Mon, 11 Oct 2004 16:05:27 +0200 (CEST) Hi, here we are. The xpdf2 patch is the same as in the last mail but included for the sake of completeness. The xpdf3 patch now contains Chris' patches for XRef.cc (xref.patch) and my xpdf3 patch for XRef.cc and Catalog.cc which have been up-ported from xpdf2. Sebastian
This is a confidential pre-notification of a security alert for xpdf Please *do not forward* any part of this to anyone or discuss these problems in a public setting. The public announcement is not until Oct 21 2004 14:00 UTC, and we'd like to keep this information embargoed until then. -------------------------------------------------------------------------------- effected packages may include. * app-text/xpdf (2 && 3) * app-text/xpdf-chinese-simplified * app-text/xpdf-chinese-traditional * app-text/xpdf-cyrillic * app-text/xpdf-greek * app-text/xpdf-japanese * app-text/xpdf-korean * app-text/xpdf-latin2 * app-text/xpdf-thai * app-text/xpdf-turkish ------------------------------------------------------------------------------- lanius can you please review this and test out the patches.
Created attachment 42169 [details, diff] xpdf-CESA-2004-007-xpdf2-newer.diff Updated version that catches another area in which xpdf can go out of bounds
Created attachment 42170 [details, diff] xpdf-CESA-2004-002-xpdf3-newer.diff and updated xpdf3 patch
The update comes From: Marcus Meissner <meissner@suse.de>
Please note that ebuilds should *not* be put in the tree until the release date. You can attach them to the bug.
Lanius, any success in your patching/testing ?
i applied the latest patch for xpdf3 and it works fine for x86. i have an updated ebuild for xpdf3 in my portoverlay to commit, xpdf2 will be removed from portage.
Created attachment 42242 [details] xpdf-3.00-r3
Guy, Tom, Gustavo, Dylan, Lars, Bryan, Aron : You recently tested and marked stable an xpdf3 version. Could you test the provided ebuild overlay (last bug attachment, is a .tbz2) and check that it works on your arch ? The goal is to commit it directly stable tomorrow by 1400 UTC and issue the corresponding GLSA. This is a confidential bug, so do not open or disclose it.
Builds and functions correctly on amd64. Cheers
Looks good for sparc, feel free to stable when it's out.
Works on hppa.
No problem on ppc. You can make it stable.
Thanks everyone. Draft submitted... waiting on kloeri to confirm it's stable on alpha. Note that according to the advisory, CUPS looks affected too by CAN-2004-0888... and we don't have an ebuild ready.
cups includes xpdf, the patch applies fine there. i assume that i can mark it stable on the same arches that tested xpdf
Works on alpha.
commited xpdf-3.00-r3 and cups-1.1.20-r4
Thanks everyone, GLSA 200410-20 is out.