Bugzilla Bug 69662

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 an attachment (id=43033) [details]
xpdf-goo-sizet.patch

Created an attachment (id=43034) [details]
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.