Created attachment 59932 [details]
xpdf-3.01pl1.patch from xpdf home page

Lars, will you please work on pdf2html/pdftohtml fixes, if required?

Created attachment 59935 [details]
patch for 2.02 from redhat

this is the patch they applied to the xpdf 2.0x tree. it seems broken though.

Jip. I will crosscheck with pdf2html...

Seems only patch for 2.02 is needed for pdftohtml. => checked in to stable, but 9.0, 9.1, 9.2, 9.3, 10.0, SLES9 are affected.

By chance I noticed that there is a if-clause double in the xpdf-2.0x:
+  if (numComps <= 0 || numComps > 4) {
+    error(getPos(), "Bad number of components in DCT stream", prec);
+    return gFalse;
+  }
This part can be deleted. :-)

submitted fixed cups packages for: SLES8, SLES9, 9.0, 9.1, 9.2, 9.3, 10.0
==> CUPS is done.

the error message is broken: 

error(getPos(), "Bad number of components in DCT stream", prec);

ok, thats not a big issue :)

submitted pdftohtml to: SLES8, SLES9, 9.0, 9.1, 9.2, 9.3, 10.0
==> pdftohtml is done

ok, the redhat patches are incomplete. the posted patch is against xpdf 3.01, which is a regression introduced by 3.0.1. they didn't notice and backported the patch brute force against 3.0. 

xpdf 3.0.1 however itself fixes about 100 integer overflow bugs. 

xpdf 2.0 and friends has those very same bugs: 

$ grep malloc * | grep '*' | grep sizeof | wc -l
108

while 3.0.1+CVE patch has almost fixed those issues: 
$ grep gmalloc * | grep '*' | grep sizeof  | grep -v gmallocn
GfxFont.cc:  map = (Gushort *)gmalloc(mapsize * sizeof(Gushort));
PSOutputDev.cc: codeToGID = (Gushort *)gmalloc(n * sizeof(Gushort));

so there are still two integer overflows left in 3.0.1 + patch. 

if we don't care about those 108 integer overflows in xpdf 2.x then we don't need to care about those 2 integer overflows that were fixed in 3.0.1 either. 

CAN-2005-3191 - DCTStream Progressive/Baseline Heap Overflow
CAN-2005-3192 - StreamPredictor Heap Overflow Vulnerability
CAN-2005-3193 - JPX Stream Reader Heap Overflow Vulnerability

... potential overflows. It still depends on where the data comes from.

Submitted:
xpdf: stable 10.0 9.3 9.2 9.1 9.0 ul1
gpdf: stable plus 10.0 9.3 9.2 9.1
poppler: stable plus 10.0

For xpdf 3.0 I'd move the sizeof(JPXTile) into the calculation:

nTiles = img.nXTiles * img.nYTiles * sizeof(JPXTile);
if (nTiles == 0 || nTiles / img.nXTiles / sizeof(JPXTile)  != img.nYTiles) {
  error(getPos(), "Bad tile count in JPX SIZ marker segment");
  return gFalse;
}
img.tiles = (JPXTile *)gmalloc(nTiles);

Maintenance-Tracker-3136

Resubmitted:
xpdf: 10.0 9.3 9.2 9.1
poppler: stable plus 10.0

Submitted: 

kdegraphics3-pdf: stable plus 10.0 9.3 9.2 9.1
koffice-wordprocessing: 10.0 9.3 9.2 9.1 9.0

wrt koffice, what about 8.1 (slec)?

Ludwig: koffice 1.2.x is not affected. 

the patches the KDE team released were incorrect. I received this mail this morning: 

From: 
Martin Pitt <martin.pitt@canonical.com>
Hi Derek, hi Dirk, hi Vendor-Sec!

Josh Bressers [2005-12-06 13:50 -0500]:
> In the event any of you missed this:
> 
> http://www.idefense.com/application/poi/display?id=342&type=vulnerabilities
> http://www.idefense.com/application/poi/display?id=343&type=vulnerabilities

It seems that the patch linked from these advisories [1] is a little
bit flawed: it checks numComps twice in DCTStream::readBaselineSOF(),
but does not check it in DCTStream::readProgressiveSOF().


I'll have to resubmit most of the kpdf/koffice updates now, will do so ASAP. most likely others need to update their patches as well, please have a look. 

Created attachment 60106 [details]
updated patch for CAN-2005-3193

this is the updated patch addressing the bugs Ludwig and Martin Pitt found.

Do last two comments affect already submitted xpdf, gpdf and evince?

yes, the chances are very high that your submissions are also incorrect. kpdf uses a close to unmodified xpdf fork (luckily we replaced that with poppler now).  

dpo we need libextractor updates for old distros, Karl? You submitted a fixed on to STABLE at least.

Yes, libextractor-0.5.2 comes with 10.0.  I'll check whether I can apply the posted patch or backport the xpdf fixes from version 0.5.8.

I applied CAN-2005-3193-updated.patch without the JPXStream.cc hunk; JPXStream.cc does not exist in the libextractor archive.  Submitted to /work.

So the current state of knowledge is that all packages need to be resubmitted to include the additional numComps check. numComps needs to be checked in

readBaselineSOF()
readProgressiveSOF()
readScanInfo()

Previously it was only in readBaselineSOF(). Creating diffs with the -p parameter helps verifying this.

Created attachment 60190 [details]
goo's gmallocn integer overflow fix

this patch fixes the integer overflow check in gmallocn and friends.

Created attachment 60194 [details]
combined patch by Martin Pitt aginst 3.00 that also fixes potentially undefined behavior with signed integer multiplications

Resubmitted with attachment 60194 [details]: 

kdegraphics3-pdf: stable plus 10.0 9.3 9.2 9.1
koffice-wordprocessing: 10.0 9.3 9.2 9.1 9.0

I've been informed and can confirm that there is another integer overflow, found by Chris Evans apparently a few weeks ago. 

Created attachment 60264 [details]
updated patch from Martin Pitt

the new version from Martin Pitt obsoleting the old one

Created attachment 60265 [details]
Overflows found by Chris Evans

Overflows pointed out in the advisory by Chris Evans - patch is pending review.

Sorry for asking...
But I'm currently joining a training course, and I'm only for a short time back in the office rooms. As these discussion grows now very quick and gets very long:
- are there final patches to apply or should I wait?
- which are xpdf-2.x relevant and which xpdf-3.x?
Thanks in advance.

I hope we get some ack/nack about Dirk's patch from vendor-sec tonight. I'll post a summary and final patches tomorrow then.

Created attachment 60405 [details]
new patch for overflows found by Chris evans and similiar ones

this one contains protections for the new overflows of the day.

Backported the patches to xpdf 2.02 and 3.00. On the way I made it more robust, it doesn't loop nor segfault with any of Chris Evans' bad pdf files anymore, worst thing is exit(1):
~lnussel/Export/xpdf

Resubmitted with attachment 60405 [details] and attachment 60264 [details]: 

kdegraphics3-pdf: stable plus 10.0 9.3 9.2 9.1
koffice-wordprocessing: 10.0 9.3 9.2 9.1 9.0

Created attachment 60994 [details]
xpdf 2.02 combined patch fixes all currently knows problems

Created attachment 60995 [details]
xpdf 3.00 combined patch fixes all currently known problems

Resubmitted with attachment 60994 [details]:

kdegraphics3-pdf: stable plus 10.0 9.3 9.2 9.1
koffice-wordprocessing: 10.0 9.3 9.2 9.1 9.0

To all: Does anyone have a copy of xpdf version 1 in a package we have to maintain? Right now I'm only aware of xpdf itself on sles8.

Created attachment 60998 [details]
xpdf 3.01pl1 combined patch

Submitted:
xpdf: stable 10.0 9.3 9.2 9.1 9.0
gpdf: stable plus 10.0 9.3 9.2 9.1
poppler: stable plus 10.0

Skipping: xpdf: ul1

Old patch replaced, old changelog entry kept.

Resubmitted pdftohtml to: STABLE, SLES8, SLES9, 9.0, 9.1, 9.2, 9.3, 10.0

libextractor resubmitted (10.0 only).

From: "Derek B. Noonburg" <derekn@foolabs.com>
Reply-To: "Derek B. Noonburg" <derekn@foolabs.com>
Subject: Re: [vendor-sec] Re: xpdf update - gmallocn() flaw
To: bressers@redhat.com
Cc: joey@infodrom.org, mueller@kde.org, koon@gentoo.org,
        scarybeasts@gmail.com, martin.pitt@canonical.com, vendor-sec@lst.de,
        "Derek B. Noonburg" <derekn@foolabs.com>
Errors-To: vendor-sec-admin@lst.de
Date: Mon, 19 Dec 2005 21:04:24 -0800 (PST)

On 16 Dec, Josh Bressers wrote:
>>
>> True.  However, December 21st is just next week and we all have to prepare   
>> updates for xpdf, gpdf, kpdf, cups, koffice, tetex - and maybe more.  That  
>> alone take a while already.  I can only speak of Debian, but I'm not even
>> sure I'm *able* to release updates before the 21st, given there are no more  
>> corrections.  So, I'm fine with any disclosure date before Christmas.
>
> I don't think this is wise.  I'm sure there are other issues that will be
> found during patch creation, and this is a bad time for most of us given
> the pending holidays.  Putting this off until after the holidays would work
> best as none of us would be pressed to do a quick and incomplete job.  The
> decision is obviously up to Chris as he's the discoverer.

I apologize for not chiming in earlier -- I've been travelling (and will
be travelling again this week), and I still haven't had time to look at
these patches.  I'd strongly prefer postponing any announcement/release
until after I've looked things over, which is going to be early January
at this point.

- Derek

Date: Tue, 20 Dec 2005 20:01:43 +0100
From: Sune Kloppenborg Jeppesen <jaervosz@gentoo.org>
To: vendor-sec@lst.de
Cc: Martin Schulze <joey@infodrom.org>, Josh Bressers <bressers@redhat.com>,
    Dirk Mueller <mueller@kde.org>, Chris Evans <scarybeasts@gmail.com>,
    Martin Pitt <martin.pitt@canonical.com>, derekn@foolabs.com
Subject: Re: [vendor-sec] Re: xpdf update - gmallocn() flaw
Parts/Attachments:
   1 Shown    ~13 lines  Text
   2          196 bytes  Application
----------------------------------------

On Friday 16 December 2005 15:51, Martin Schulze wrote:
> Please don't postpone it after Christmas.  Then rather release the
> current fixes now and add another set of updates after Christmas.

What embargo date has been decided on this issue? 

Gentoo would prefer a release soon as patches are apparently available in at 
least one upstream public svn repository. 

-- 
Sune Kloppenborg Jeppesen
Gentoo Linux Security Team

From: Josh Bressers <bressers@redhat.com>
To: Dirk Mueller <mueller@kde.org>

> On Monday 02 January 2006 22:02, Sune Kloppenborg Jeppesen wrote:
> 
> > > I'd also prefer to release soon, preferably on 21st like I suggested last
> > > week.
> > New Year and Christmas are behind us now, any news on an embargo date?
> 
> The latest patch I mailed around, which has been created by Ludwig Nussel and 
> myself, which also contains fixes for vulnerabilities found by Chris Evans, 
> has already been published by Red Hat on 2005-12-20. 
> 
> https://rhn.redhat.com/errata/RHSA-2005-868.html
> 
> Therefore I consider the patch to be leaked and the embargo to be broken.

This does appear this is true.  The complete patch is also in our xpdf
update as well.  Both xpdf and kpdf are maintained by the same person, who
I have never sent the full patch to.  Sadly he's out today so the whole
story will have to wait.

As for the CVE ids, here they are:

1) Out-of-bounds heap accesses with large or negative parameters to
   "FlateDecode" stream.
2) Out-of-bounds heap accesses with large or negative parameters to
   "CCITTFaxDecode" stream.
* CVE-2005-3624

3) Infinite CPU spins in various places when stream ends unexpectedly.
   Probably repeated at various locations in the code.
* CVE-2005-3625

4) NULL pointer crash in the "FlateDecode" stream.
* CVE-2005-3626

5) Overflows of compInfo array in "DCTDecode" stream.
6) Possible to use index past end of array in "DCTDecode" stream.
7) More possible out-of-bounds indexing trouble in "DCTDecode" stream.
* CVE-2005-3627

These are for the CESA-2005-003 advisory from Chris.

-- 
    JB

CVE-2005-3628 for the JBIG2Bitmap fixes. It's all public in the meantime so if anyone did not submit to STABLE yet you may do so now.

There is another xpdf issue pending (#141242), no patch yet.

updated koffice for sles8-slec, which contained a backported xpdf from KOffice 1.3.x (sigh!)

*** Bug 142106 has been marked as a duplicate of this bug. ***

pdftohtml needs corrected packages.

cups needs updated patches.

tetex needs updated patches.

Does this mean we've stable patches for both xpdf 3+ and xpdf 2 which do not
change every day?

yes, besides that we have another xpdf issue already in the making this particular one is done. 

OK, which attachments are required for xpdf 3 and which attachments for xpdf 2?

read the list of attachments, please. there is one combined patch for 2.00, 3.00 and 3.01 attached (and not marked as obsoleted). The goo fix is necessary if you use 3.01pl1

cups is finished: SLES8, SLES9, 9.0, 9.1, 9.2, 9.3, 10.0, STABLE

pdftohtml: correct packages for SLES9, 9.0, 9.1, 9.2, 9.3 (STABLE and 10.0) checked in 

For tetex on SLES8 a xpdf-1 version is needed.

tetex: SLES9, 9.0, 9.1, 9.2, 9.3, 10.0, STABLE

Missed SLES8 due missed patch:

  Patch #15 (xpdf-CAN-2005-3191,3192,3193-xpdf202.dif):
  + patch -p0 -b --suffix .xpdfsec4 -s
  7 out of 10 hunks FAILED -- saving rejects to file libs/xpdf/xpdf/Stream.cc.rej
  The text leading up to this was:
  --------------------------
  |--- libs/xpdf/xpdf/JBIG2Stream.cc
  |+++ libs/xpdf/xpdf/JBIG2Stream.cc
  --------------------------
  File to patch:
  Skip this patch? [y]
  6 out of 6 hunks ignored
  Bad exit status from /var/tmp/rpm-tmp.10321 (%prep)

Created attachment 62964 [details]
untested backport to xpdf1

OK, now we're done with tetex, just submitted to SLES8.

we rejected tetex, since it only renders into pdfs but does not read out 
of them.

we will not fix tetex for pdf rendering issues again.

I released libextractor, the last package with xpdf code left in the queue.

Thanks everybody!

CVE-2005-3628: CVSS v2 Base Score: 7.5 (AV:N/AC:L/Au:N/C:P/I:P/A:P)