Opening bug to keep track of the issue. Vendor-sec says: I have identified 2 problems: - We are using "if (size * sizeof(Foo)/sizeof(Foo) != size)" checks, which operate on "size_t" which is 64bit unsigned long on 64bit systems. However Xpdf then goes and calls "g*alloc" its own funny gmalloc/grealloc routines. Which have size passed into as "int" a 32bit quantity. This is happily truncated by the compiler leading again to the mentioned overflow. I have attached a patch against libgoo to change its arguments from int to size_t. Applies to xpdf2 and xpdf3. - Several negative integer conditions went unchecked. I am not sure why this did not show up on 32bit systems, but it does on 64bit systems. Additionaly, at one place the parser could be made to enter an endless loop. I have fixed the most obvious places of those problems, more might be in there. Patch attached. Applies to xpdf2 only, xpdf3 already has checks in place. The goo patch can be considered final I think. The underflow patch is yet another layer of checks and patchwork. I would call this issue public, since it can be reproduced using Chris Evans bad4.pdf and bad5.pdf.
Created attachment 43033 [details, diff] xpdf-goo-sizet.patch
Created attachment 43034 [details, diff] xpdf2-underflow.patch
Heinrich please provide an updated ebuild or CC relevant dev.
Can this issue be considered public now? at least gnustep-libs/pdfkit (bug 69008) app-text/gpdf (bug 68571) kde-base/kdegraphics ->kpdf (bug 68558) app-text/pdftohtml (bug 69019) would probably need these patches too, since they are including xpdf (most of them with patches from bug 68058)
added the patch to xpdf-3.00-r5, currently testing net-print/cups with this patch
added net-print/cups-1.1.20-r5 with this patch
Armando, please apply these xpdf patches to gnustep-libs/pdfkit if possible foser, please apply the patches to app-text/gpdf if possible
motaboy, pls apply the patches to kdegraphics (kpdf) if possible
http://lists.netsys.com/pipermail/full-disclosure/2004-November/028264.html This announcement by Ubuntu Linux seems to address these issues and the patches to xpdf kinda looked familiar too ;-) I would guess this is really public now...
I think that also koffice is affected from this problem as it includes a copy of xpdf2 in a kword's import filter.
Caleb is the maintainer for the kde-base/* ebuilds (kde-core herd). Carlo keeps the koffice ebuilds and already updated them to the xpdf issues of the lasts days So please CC them. Thanks!
caleb, carlo : unfortunately the koffice/kdegraphics xpdf patches were not sufficient. Please see above comments and repatch :/ Note: we cannot open this bug until vendor-sec liaisons agree it's a public issue.
gpdf-0.132-r2 (gnome 2.6) & gpdf-2.8.0-r2 (gnome 2.8) added, marked x86 stable
Could someone please give me a heads up on procedure here, as these xpdf issues are the first bona fide security issues I've had to take care of. - gnustep-libs/pdfkit uses xpdf-3.00 code, so I'm only applying the xpdf-goo-sizet.patch, correct? (patches for the slightly older xpdf issue already applied). - as per "publicizing" this issue, do I wait until it's public to fix it? (that doesn't seem right..) or fix now, update the tree, and just "don't talk about it" until it's publicized? Thanks.
Fixes for xpdf-3.00 issues for gnustep-libs/pdfkit are in.
OK, so now we still need to finally fix that xpdf annoying thing: carlo : koffice caleb : kpdf (kdegraphics) robbat2 : pdftohtml then we'll call arch testing. Kurt, since Ubuntu published it, I think we should consider this is public. Please open it if you agree.
opening since this is a public bug now.
Separating bugs for clarity. This one is for xpdf,cups,gpdf and pdfkit which already have fixed ebuilds in the tree. Arches, please mark stable : app-text/xpdf-3.00-r5 : ppc sparc alpha hppa amd64 ia64 ppc64 net-print/cups-1.1.20-r5 : ppc sparc mips alpha arm hppa amd64 ia64 s390 ppc64 app-text/gpdf-0.132-r2 : alpha amd64 hppa ia64 mips ppc sparc app-text/gpdf-2.8.0-r2 : alpha amd64 ia64 ppc
sparc done.
stable on ppc
app-text/xpdf-3.00-r5 : cannot mark stable on ppc64. look bug #68661 Comment #6 net-print/cups-1.1.20-r5 : stable on ppc64 Markus
Stable on alpha.
arm/hppa/ia64/s390 *should* be all set ... please correct me if i'm wrong :)
amd64 should also be good to go
Blocked by xpdf stable on ppc64, bug 68661
Will be released as a 200410-20 update when bug 68661 is done
xpdf stable on ppc64 by corsair
GLSA 200410-20:02 update out
Stable on mips.
