----- Forwarded message from "Derek B. Noonburg" -----

From: "Derek B. Noonburg" Date: Fri, 13 Jul 2007 11:29:59 -0700 (PDT) To: Ludwig Nussel cc: than@redhat.com, mike@easysw.com, secalert@redhat.com, security@gentoo.org, security@kde.org, hanthethanh@gmail.com, Fabrice.Popineau@supelec.fr, security@suse.de, z33d@isec.pl, "Derek B. Noonburg" Subject: Re: Xpdf 3.02 security hole

On 13 Jul, Ludwig Nussel wrote:

...

Josh Bressers wrote:

...

...

A security hole in Xpdf 3.02 has been reported. I'm attaching the patch file. I'm currently expecting this to be disclosed early next week.

Hi Derek,

Please use CVE-2007-3387 for this flaw. Am I right in assuming that the flaw here is an integer overflow?

Please note that this bug was originally reported by Maurycy Prodeus , whom I have added to the cc list. I believe he is coordinating a release date with google (since Xpdf's pdftotext is used by Google Desktop).

...

IMO the crucial part is the changed check for nComps > gfxColorMaxComps as nComps is used later as upper bound for an offset into Guchar upLeftBuf[gfxColorMaxComps * 2 + 1];

The reported vulnerability was in the call to memset -- pixBytes was not checked for overflow. (With the patch it is limited to gfxColorMaxComps * 16.)

...

The patch removes the check width >= INT_MAX / nComps / nBits though which should be kept nevertheless IMO:

I don't think that check is actually useful anymore. The only place where width is used is in one loop in StreamPredictor::getNextLine(). The issue to worry about would be an overflow on predLine[] in that loop, which I believe is prevented by the nVals<=0 and rowBytes<=0 tests.

But let me know if you see a combination of values that might cause problems there.

- Derek

----- End forwarded message -----