|Summary:||xpdf,cups,gpdf,pdfkit 64bit security issues|
|Product:||Gentoo Security||Reporter:||Sune Kloppenborg Jeppesen <jaervosz>|
|Component:||Vulnerabilities||Assignee:||Gentoo Security <security>|
|Severity:||major||CC:||fafhrd, foser, lanius|
|Whiteboard:||A2 [glsa] koon|
|Package list:||Runtime testing required:||---|
|Bug Depends on:||68661|
Description Sune Kloppenborg Jeppesen 2004-10-31 13:01:36 UTC
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.
Comment 1 Sune Kloppenborg Jeppesen 2004-10-31 13:02:57 UTC
Created attachment 43033 [details, diff] xpdf-goo-sizet.patch
Comment 2 Sune Kloppenborg Jeppesen 2004-10-31 13:03:35 UTC
Created attachment 43034 [details, diff] xpdf2-underflow.patch
Comment 3 Sune Kloppenborg Jeppesen 2004-10-31 13:09:30 UTC
Heinrich please provide an updated ebuild or CC relevant dev.
Comment 4 Matthias Geerdsen (RETIRED) 2004-11-01 01:13:05 UTC
Comment 5 Heinrich Wendel (RETIRED) 2004-11-01 05:59:49 UTC
added the patch to xpdf-3.00-r5, currently testing net-print/cups with this patch
Comment 6 Heinrich Wendel (RETIRED) 2004-11-01 06:37:32 UTC
added net-print/cups-1.1.20-r5 with this patch
Comment 7 Matthias Geerdsen (RETIRED) 2004-11-01 12:52:11 UTC
Armando, please apply these xpdf patches to gnustep-libs/pdfkit if possible foser, please apply the patches to app-text/gpdf if possible
Comment 8 Matthias Geerdsen (RETIRED) 2004-11-01 13:39:44 UTC
motaboy, pls apply the patches to kdegraphics (kpdf) if possible
Comment 9 Matthias Geerdsen (RETIRED) 2004-11-01 13:48:56 UTC
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...
Comment 10 Simone Gotti (RETIRED) 2004-11-01 13:59:31 UTC
I think that also koffice is affected from this problem as it includes a copy of xpdf2 in a kword's import filter.
Comment 11 Simone Gotti (RETIRED) 2004-11-01 14:12:17 UTC
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!
Comment 12 Thierry Carrez (RETIRED) 2004-11-01 14:16:57 UTC
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.
Comment 13 foser (RETIRED) 2004-11-01 15:29:26 UTC
gpdf-0.132-r2 (gnome 2.6) & gpdf-2.8.0-r2 (gnome 2.8) added, marked x86 stable
Comment 14 Armando Di Cianno (RETIRED) 2004-11-01 18:14:51 UTC
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.
Comment 15 Armando Di Cianno (RETIRED) 2004-11-01 19:43:16 UTC
Fixes for xpdf-3.00 issues for gnustep-libs/pdfkit are in.
Comment 16 Thierry Carrez (RETIRED) 2004-11-03 03:01:37 UTC
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.
Comment 17 Kurt Lieber (RETIRED) 2004-11-03 04:41:40 UTC
opening since this is a public bug now.
Comment 18 Thierry Carrez (RETIRED) 2004-11-03 04:54:34 UTC
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
Comment 19 Gustavo Zacarias (RETIRED) 2004-11-03 05:10:12 UTC
Comment 20 Jochen Maes (RETIRED) 2004-11-03 06:00:42 UTC
stable on ppc
Comment 21 Markus Rothe (RETIRED) 2004-11-03 07:07:54 UTC
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
Comment 22 Bryan Østergaard (RETIRED) 2004-11-03 10:34:43 UTC
Stable on alpha.
Comment 23 SpanKY 2004-11-03 21:34:07 UTC
arm/hppa/ia64/s390 *should* be all set ... please correct me if i'm wrong :)
Comment 24 Travis Tilley (RETIRED) 2004-11-04 09:28:54 UTC
amd64 should also be good to go
Comment 25 Thierry Carrez (RETIRED) 2004-11-04 11:42:07 UTC
Blocked by xpdf stable on ppc64, bug 68661
Comment 26 Thierry Carrez (RETIRED) 2004-11-05 04:55:52 UTC
Will be released as a 200410-20 update when bug 68661 is done
Comment 27 Thierry Carrez (RETIRED) 2004-11-06 05:09:37 UTC
xpdf stable on ppc64 by corsair
Comment 28 Thierry Carrez (RETIRED) 2004-11-06 05:33:10 UTC
GLSA 200410-20:02 update out
Comment 29 Hardave Riar (RETIRED) 2004-11-08 02:10:51 UTC
Stable on mips.