tetex-bin: Multiple exploitable heap overflows in embedded xpdf copy

[Debian Bug Importer]

Automatically imported from Debian bug report #342292 http://bugs.debian.org/342292

[Debian Bug Importer (debzilla)]

Automatically imported from Debian bug report #342292 http://bugs.debian.org/342292

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Tue, 06 Dec 2005 23:15:18 +0100
From: Moritz Muehlenhoff <email address hidden>
To: Debian Bug Tracking System <email address hidden>
Subject: tetex-bin: Multiple exploitable heap overflows in embedded xpdf copy

Package: tetex-bin
Version: 3.0-10.1
Severity: grave
Tags: security
Justification: user security hole

Multiple exploitable security problems have been found in xpdf, which are
all present in tetex-bin's embedded xpdf copy as well:

Multiple Vendor xpdf DCTStream Baseline Heap Overflow Vulnerability
 http://www.idefense.com/application/poi/display?id=342

Multiple Vendor xpdf DCTStream Progressive Heap Overflow
 http://www.idefense.com/application/poi/display?id=343

Multiple Vendor xpdf StreamPredictor Heap Overflow Vulnerability
 http://www.idefense.com/application/poi/display?id=344

Multiple Vendor xpdf JPX Stream Reader Heap Overflow Vulnerability
 http://www.idefense.com/application/poi/display?id=345

Please reference CVE-2005-3191, CVE-2005-3192 and CVE-2005-3193 when fixing
this.

Cheers,
        Moritz

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.14-2-686
Locale: LANG=C, LC_CTYPE=de_DE.ISO-8859-15@euro (charmap=ISO-8859-15)

Versions of packages tetex-bin depends on:
ii debconf [debconf-2.0] 1.4.62 Debian configuration management sy
ii debianutils 2.15.1 Miscellaneous utilities specific t
ii dpkg 1.13.11.0.1 package maintenance system for Deb
ii ed 0.2-20 The classic unix line editor
ii libc6 2.3.5-8.1 GNU C Library: Shared libraries an
ii libgcc1 1:4.0.2-5 GCC support library
ii libice6 6.8.2.dfsg.1-11 Inter-Client Exchange library
ii libkpathsea4 3.0-10.1 path search library for teTeX (run
ii libpaper1 1.1.14-3 Library for handling paper charact
ii libpng12-0 1.2.8rel-5 PNG library - runtime
ii libsm6 6.8.2.dfsg.1-11 X Window System Session Management
ii libstdc++6 4.0.2-5 The GNU Standard C++ Library v3
ii libt1-5 5.1.0-2 Type 1 font rasterizer library - r
ii libx11-6 6.8.2.dfsg.1-11 X Window System protocol client li
ii libxaw8 6.8.2.dfsg.1-11 X Athena widget set library
ii libxext6 6.8.2.dfsg.1-11 X Window System miscellaneous exte
ii libxmu6 6.8.2.dfsg.1-11 X Window System miscellaneous util
ii libxp6 6.8.2.dfsg.1-11 X Window System printing extension
ii libxpm4 6.8.2.dfsg.1-11 X pixmap library
ii libxt6 6.8.2.dfsg.1-11 X Toolkit Intrinsics
ii mime-support 3.35-1 MIME files 'mime.types' & 'mailcap
ii perl 5.8.7-8 Larry Wall's Practical Extraction
ii sed 4.1.4-4 The GNU sed stream editor
ii tetex-base ...

[Frank Küster (frank-debian)]

Dear security team,

Moritz Muehlenhoff <email address hidden> wrote:

> Package: tetex-bin
> Version: 3.0-10.1
> Severity: grave
> Tags: security
> Justification: user security hole
>
> Multiple exploitable security problems have been found in xpdf, which are
> all present in tetex-bin's embedded xpdf copy as well

A patch is provided by upstream, and I'll be able to upload a fixed
version to sid in the next 2 or three days.

However, since I'm currently busy with real-life issues, I will *NOT* be
able to backport the patch to the stable version of tetex-bin, nor work
on the numerous other packages that contain xpdf code and that I have
prepared patches for or NMU'ed previously in similar cases.

Note also that testing still has the same upstream version as stable,
and other issues prevent the new version to migrate from sid to testing
soon.

Regards, Frank

P.S. Is anybody in contact with the xpdf upstream about providing a
dynamically shared library, or at least get clarification whether they
think distributions should try libpoppler instead? If not, would the
security team allow me to quote them as "We would very much appreciate
if such a library existed, and would urge maintainers and upstream
developers to switch to using it"?
--
Frank Küster
Inst. f. Biochemie der Univ. Zürich
Debian Developer

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Wed, 07 Dec 2005 09:36:24 +0100
From: =?iso-8859-1?q?Frank_K=FCster?= <email address hidden>
To: <email address hidden>
Cc: <email address hidden>, Moritz Muehlenhoff <email address hidden>
Subject: Re: Bug#342292: tetex-bin: Multiple exploitable heap overflows in
 embedded xpdf copy

Dear security team,

Moritz Muehlenhoff <email address hidden> wrote:

> Package: tetex-bin
> Version: 3.0-10.1
> Severity: grave
> Tags: security
> Justification: user security hole
>
> Multiple exploitable security problems have been found in xpdf, which are
> all present in tetex-bin's embedded xpdf copy as well

A patch is provided by upstream, and I'll be able to upload a fixed
version to sid in the next 2 or three days.

However, since I'm currently busy with real-life issues, I will *NOT* be
able to backport the patch to the stable version of tetex-bin, nor work
on the numerous other packages that contain xpdf code and that I have
prepared patches for or NMU'ed previously in similar cases.

Note also that testing still has the same upstream version as stable,
and other issues prevent the new version to migrate from sid to testing
soon.=20

Regards, Frank

P.S. Is anybody in contact with the xpdf upstream about providing a
dynamically shared library, or at least get clarification whether they
think distributions should try libpoppler instead? If not, would the
security team allow me to quote them as "We would very much appreciate
if such a library existed, and would urge maintainers and upstream
developers to switch to using it"?
--=20
Frank K=FCster
Inst. f. Biochemie der Univ. Z=FCrich
Debian Developer

[Frank Küster (frank-debian)]

found 342292 2.0.2-30
found 342292 2.0.2-31
found 342292 1.0.7+20011202-7.3
thanks

The upstream patch applies cleanly to xpdf/Stream.{cc,h} in sarge, but
JPXStream.cc does not exist. But the functions might still be defined
elsewhere.

The patch does not apply cleanly, except for Stream.h, in woody, but at
least one affected line in Stream.cc *does* exist.

As I said previously, I will not be able to work on this.

Regards, Frank
--
Frank Küster
Inst. f. Biochemie der Univ. Zürich
Debian Developer

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Wed, 07 Dec 2005 14:54:40 +0100
From: =?iso-8859-1?q?Frank_K=FCster?= <email address hidden>
To: Debian Bug Control Server <email address hidden>
Cc: <email address hidden>, Debian Security Team <email address hidden>
Subject: Re: Bug#342292: tetex-bin: Multiple exploitable heap overflows in
 embedded xpdf copy

found 342292 2.0.2-30
found 342292 2.0.2-31
found 342292 1.0.7+20011202-7.3
thanks

The upstream patch applies cleanly to xpdf/Stream.{cc,h} in sarge, but
JPXStream.cc does not exist. But the functions might still be defined
elsewhere.

The patch does not apply cleanly, except for Stream.h, in woody, but at
least one affected line in Stream.cc *does* exist.

As I said previously, I will not be able to work on this.

Regards, Frank
--=20
Frank K=FCster
Inst. f. Biochemie der Univ. Z=FCrich
Debian Developer

[Frank Küster (frank-debian)]

Source: tetex-bin
Source-Version: 3.0-11

We believe that the bug you reported is fixed in the latest version of
tetex-bin, which is due to be installed in the Debian FTP archive:

libkpathsea4-dev_3.0-11_i386.deb
  to pool/main/t/tetex-bin/libkpathsea4-dev_3.0-11_i386.deb
libkpathsea4_3.0-11_i386.deb
  to pool/main/t/tetex-bin/libkpathsea4_3.0-11_i386.deb
tetex-bin_3.0-11.diff.gz
  to pool/main/t/tetex-bin/tetex-bin_3.0-11.diff.gz
tetex-bin_3.0-11.dsc
  to pool/main/t/tetex-bin/tetex-bin_3.0-11.dsc
tetex-bin_3.0-11_i386.deb
  to pool/main/t/tetex-bin/tetex-bin_3.0-11_i386.deb

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed. If you
have further comments please address them to <email address hidden>,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Frank Küster <email address hidden> (supplier of updated tetex-bin package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing <email address hidden>)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Format: 1.7
Date: Wed, 7 Dec 2005 14:34:12 +0100
Source: tetex-bin
Binary: tetex-bin libkpathsea4-dev libkpathsea4
Architecture: source i386
Version: 3.0-11
Distribution: unstable
Urgency: high
Maintainer: teTeX maintainers <email address hidden>
Changed-By: Frank Küster <email address hidden>
Description:
 libkpathsea4 - path search library for teTeX (runtime part)
 libkpathsea4-dev - path search library for teTeX (devel part)
 tetex-bin - The teTeX binary files
Closes: 207874 335055 335477 336092 337308 338986 339388 341940 342292
Changes:
 tetex-bin (3.0-11) unstable; urgency=high
 .
   * Apply xpdf patch 3.01pl1 to fix vulnerabilities in the included xpdf
     code. The patch has been modified slightly, because our code is based
     on xpdf 3.00 which uses gmalloc() instead of gmallocn() (closes:
     #342292) [frank]
   * Remove old alternatives for oxdvi, which is now integrated in xdvi
     (closes: #335477) [frank]
   * Add Florent to the list of uploaders to prevent future technical NMUs,
     and acknowledge the last one with thanks (closes: #335055)
     [frank]
   * Fix up our backwards compatibility code in fmtutil(-sys), so that root
     can now also use it as mktexfmt (closes: #338986) [frank]
   * Remove ancient code from libkpathsea's postinst script; it is now
     fully created by debhelper. The same is true for libkpathsea4-dev.
     Many thanks to Hilmar (closes: #207874) [frank]
   * Unset variables that might override texmf.cnf settings in postinst
     [frank]
   * Translations:
     - Update Italian debconf translation, thanks to Luca Monducci
       <email address hidden> (closes: #336092) [frank]
     - Update French debconf translation, thanks to Clement Stenac
       <email address hidden> (closes: #337308) [frank]
     - Update Danish debconf translation, thanks to Claus Hindsgaul
       <email address hidden> (closes: #339388) [frank]
     - Update Czech debconf translation, thanks to Miroslav Kure
       <...

[Debian Bug Importer (debzilla)]

Message-Id: <email address hidden>
Date: Wed, 07 Dec 2005 06:32:11 -0800
From: =?utf-8?q?Frank_K=C3=BCster?= <email address hidden>
To: <email address hidden>
Subject: Bug#342292: fixed in tetex-bin 3.0-11

Source: tetex-bin
Source-Version: 3.0-11

We believe that the bug you reported is fixed in the latest version of
tetex-bin, which is due to be installed in the Debian FTP archive:

libkpathsea4-dev_3.0-11_i386.deb
  to pool/main/t/tetex-bin/libkpathsea4-dev_3.0-11_i386.deb
libkpathsea4_3.0-11_i386.deb
  to pool/main/t/tetex-bin/libkpathsea4_3.0-11_i386.deb
tetex-bin_3.0-11.diff.gz
  to pool/main/t/tetex-bin/tetex-bin_3.0-11.diff.gz
tetex-bin_3.0-11.dsc
  to pool/main/t/tetex-bin/tetex-bin_3.0-11.dsc
tetex-bin_3.0-11_i386.deb
  to pool/main/t/tetex-bin/tetex-bin_3.0-11_i386.deb

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed. If you
have further comments please address them to <email address hidden>,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Frank Küster <email address hidden> (supplier of updated tetex-bin package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing <email address hidden>)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Format: 1.7
Date: Wed, 7 Dec 2005 14:34:12 +0100
Source: tetex-bin
Binary: tetex-bin libkpathsea4-dev libkpathsea4
Architecture: source i386
Version: 3.0-11
Distribution: unstable
Urgency: high
Maintainer: teTeX maintainers <email address hidden>
Changed-By: Frank Küster <email address hidden>
Description:
 libkpathsea4 - path search library for teTeX (runtime part)
 libkpathsea4-dev - path search library for teTeX (devel part)
 tetex-bin - The teTeX binary files
Closes: 207874 335055 335477 336092 337308 338986 339388 341940 342292
Changes:
 tetex-bin (3.0-11) unstable; urgency=high
 .
   * Apply xpdf patch 3.01pl1 to fix vulnerabilities in the included xpdf
     code. The patch has been modified slightly, because our code is based
     on xpdf 3.00 which uses gmalloc() instead of gmallocn() (closes:
     #342292) [frank]
   * Remove old alternatives for oxdvi, which is now integrated in xdvi
     (closes: #335477) [frank]
   * Add Florent to the list of uploaders to prevent future technical NMUs,
     and acknowledge the last one with thanks (closes: #335055)
     [frank]
   * Fix up our backwards compatibility code in fmtutil(-sys), so that root
     can now also use it as mktexfmt (closes: #338986) [frank]
   * Remove ancient code from libkpathsea's postinst script; it is now
     fully created by debhelper. The same is true for libkpathsea4-dev.
     Many thanks to Hilmar (closes: #207874) [frank]
   * Unset variables that might override texmf.cnf settings in postinst
     [frank]
   * Translations:
     - Update Italian debconf translation, thanks to Luca Monducci
       <email address hidden> (closes: #336092) [frank]
     - Update French debconf translation, thanks to Clement Stenac
       <<email address hidden>...

[Martin Pitt (pitti)]

Hi!

I'm currently preparing Ubuntu security updates for these issues, and
I noticed that the upstream provided patch is wrong. I sent the mail
below to upstream (and some others).

Can you please check that you indeed fixed (tetex-bin)/will fix
(poppler) DCTStream::readProgressiveSOF(), too?

Thanks,

Martin

----- Forwarded message from Martin Pitt <email address hidden> -----

From: Martin Pitt <email address hidden>
To: <email address hidden>, <email address hidden>, Dirk Mueller <email address hidden>
Subject: Re: [vendor-sec] xpdf update - patch wrong?
Mail-Followup-To: <email address hidden>, <email address hidden>,
 Dirk Mueller <email address hidden>
Date: Thu, 8 Dec 2005 11:20:37 +0100
X-Spam-Status: No, score=1.0 required=4.0 tests=AWL,BAYES_50,
 RCVD_IN_BL_SPAMCOP_NET,RCVD_IN_SORBS_WEB autolearn=no version=3.0.3

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().

It *seems* that KDE spotted and removed the double check in their
kdegraphics patch [2], but unless they removed
DCTStream::readProgressiveSOF() (which could very well be, I didn't
check yet), these patches now have the same flaw.

Thanks,

Martin

[1] ftp://ftp.foolabs.com/pub/xpdf/xpdf-3.01pl1.patch
[2] ftp://ftp.kde.org/pub/kde/security_patches/post-3.4.3-kdegraphics-CAN-2005-3193.diff

--
Martin Pitt http://www.piware.de
Ubuntu Developer http://www.ubuntu.com
Debian Developer http://www.debian.org

In a world without walls and fences, who needs Windows and Gates?

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

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Thu, 8 Dec 2005 12:21:57 +0100
From: Martin Pitt <email address hidden>
To: <email address hidden>, <email address hidden>
Subject: Fwd: Re: [vendor-sec] xpdf update - patch wrong?

--Dzs2zDY0zgkG72+7
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hi!

I'm currently preparing Ubuntu security updates for these issues, and
I noticed that the upstream provided patch is wrong. I sent the mail
below to upstream (and some others).

Can you please check that you indeed fixed (tetex-bin)/will fix
(poppler) DCTStream::readProgressiveSOF(), too?

Thanks,

Martin

----- Forwarded message from Martin Pitt <email address hidden> -----

=46rom: Martin Pitt <email address hidden>
To: <email address hidden>, <email address hidden>, Dirk Mueller <email address hidden>
Subject: Re: [vendor-sec] xpdf update - patch wrong?
Mail-Followup-To: <email address hidden>, <email address hidden>,
 Dirk Mueller <email address hidden>
Date: Thu, 8 Dec 2005 11:20:37 +0100
X-Spam-Status: No, score=3D1.0 required=3D4.0 tests=3DAWL,BAYES_50,
 RCVD_IN_BL_SPAMCOP_NET,RCVD_IN_SORBS_WEB autolearn=3Dno version=3D3.0.3

Hi Derek, hi Dirk, hi Vendor-Sec!

Josh Bressers [2005-12-06 13:50 -0500]:
> In the event any of you missed this:
>=20
> http://www.idefense.com/application/poi/display?id=3D342&type=3Dvulnerabi=
lities
> http://www.idefense.com/application/poi/display?id=3D343&type=3Dvulnerabi=
lities

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().

It *seems* that KDE spotted and removed the double check in their
kdegraphics patch [2], but unless they removed
DCTStream::readProgressiveSOF() (which could very well be, I didn't
check yet), these patches now have the same flaw.

Thanks,

Martin

[1] ftp://ftp.foolabs.com/pub/xpdf/xpdf-3.01pl1.patch
[2] ftp://ftp.kde.org/pub/kde/security_patches/post-3.4.3-kdegraphics-CAN-2=
005-3193.diff

--=20
Martin Pitt http://www.piware.de
Ubuntu Developer http://www.ubuntu.com
Debian Developer http://www.debian.org

In a world without walls and fences, who needs Windows and Gates?

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

--Dzs2zDY0zgkG72+7
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFDmBdVDecnbV4Fd/IRArJnAJ9lVGh7ZCQ3loxC7+uKfzBnMfuqVQCgt5KY
PNLCquUaYwRRfhC9QWYKbg4=
=JqTt
-----END PGP SIGNATURE-----

--Dzs2zDY0zgkG72+7--

[Frank Küster (frank-debian)]

Martin Pitt <email address hidden> wrote:

> Hi!
>
> I'm currently preparing Ubuntu security updates for these issues, and
> I noticed that the upstream provided patch is wrong. I sent the mail
> below to upstream (and some others).
>
> Can you please check that you indeed fixed (tetex-bin)/will fix
> (poppler) DCTStream::readProgressiveSOF(), too?
[...]
> 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().

We have the same flaw in our upload. Would you be so kind and check the
updated patch at

http://svn.debian.org/wsvn/pkg-tetex/tetex-bin/trunk/debian/patches/patch-CVE-2005-3191+2+3?op=file&rev=0&sc=0

I'm completely illerate in C++, and would like to make sure this is
correct.

Regards, Frank
--
Frank Küster
Inst. f. Biochemie der Univ. Zürich
Debian Developer

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Thu, 08 Dec 2005 13:17:50 +0100
From: =?iso-8859-1?q?Frank_K=FCster?= <email address hidden>
To: Martin Pitt <email address hidden>
Cc: <email address hidden>
Subject: Re: Bug#342292: Fwd: Re: [vendor-sec] xpdf update - patch wrong?

Martin Pitt <email address hidden> wrote:

> Hi!
>
> I'm currently preparing Ubuntu security updates for these issues, and
> I noticed that the upstream provided patch is wrong. I sent the mail
> below to upstream (and some others).
>
> Can you please check that you indeed fixed (tetex-bin)/will fix
> (poppler) DCTStream::readProgressiveSOF(), too?
[...]
> 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().

We have the same flaw in our upload. Would you be so kind and check the
updated patch at=20

http://svn.debian.org/wsvn/pkg-tetex/tetex-bin/trunk/debian/patches/patch-C=
VE-2005-3191+2+3?op=3Dfile&rev=3D0&sc=3D0

I'm completely illerate in C++, and would like to make sure this is
correct.=20=20

Regards, Frank
--=20
Frank K=FCster
Inst. f. Biochemie der Univ. Z=FCrich
Debian Developer

[Martin Pitt (pitti)]

Hi Frank!

Frank Küster [2005-12-08 13:17 +0100]:
> Martin Pitt <email address hidden> wrote:
>
> > Hi!
> >
> > I'm currently preparing Ubuntu security updates for these issues, and
> > I noticed that the upstream provided patch is wrong. I sent the mail
> > below to upstream (and some others).
> >
> > Can you please check that you indeed fixed (tetex-bin)/will fix
> > (poppler) DCTStream::readProgressiveSOF(), too?
> [...]
> > 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().
>
> We have the same flaw in our upload. Would you be so kind and check the
> updated patch at
>
> http://svn.debian.org/wsvn/pkg-tetex/tetex-bin/trunk/debian/patches/patch-CVE-2005-3191+2+3?op=file&rev=0&sc=0

The DCTStream::readProgressiveSOF() seems to be correct now, however,
there is still a flaw in

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

gmalloc does a multiplication which is not checked for integer
overflows. xpdf uses gmallocn() which does that check.

I'll send you an updated patch very soon, I just finished patching
tetex-bin 2.0.2, cupsys, xpdf, poppler, etc.

Martin

--
Martin Pitt http://www.piware.de
Ubuntu Developer http://www.ubuntu.com
Debian Developer http://www.debian.org

In a world without walls and fences, who needs Windows and Gates?

[Martin Pitt (pitti)]

Hi Frank!

Frank Küster [2005-12-08 13:17 +0100]:
> We have the same flaw in our upload. Would you be so kind and check the
> updated patch at
>
> http://svn.debian.org/wsvn/pkg-tetex/tetex-bin/trunk/debian/patches/patch-CVE-2005-3191+2+3?op=file&rev=0&sc=0
>
> I'm completely illerate in C++, and would like to make sure this is
> correct.

OK, you can now find the 3.0 debdiff at

  http://patches.ubuntu.com/patches/tetex-bin.CVE-2005-3191_2_3.diff

it might be interesting for you to get the CVE numbers in the
changelog right. (Please do mention the CVE numbers to ease tracking.)

The essential difference is the JPXStream.cc diff, which now looks
like:

--- tetex-bin-3.0/libs/xpdf/xpdf/JPXStream.cc 2004-01-22 02:26:45.000000000 +0100
+++ tetex-bin-3.0.new/libs/xpdf/xpdf/JPXStream.cc 2005-12-08 14:40:19.000000000 +0100
@@ -666,7 +666,8 @@
   int segType;
   GBool haveSIZ, haveCOD, haveQCD, haveSOT;
   Guint precinctSize, style;
- Guint segLen, capabilities, comp, i, j, r;
+ Guint segLen, capabilities, nTiles, comp, i, j, r;
+ Guint allocSize;

   //----- main header
   haveSIZ = haveCOD = haveQCD = haveSOT = gFalse;
@@ -701,8 +702,15 @@
                    / img.xTileSize;
       img.nYTiles = (img.ySize - img.yTileOffset + img.yTileSize - 1)
                    / img.yTileSize;
- img.tiles = (JPXTile *)gmalloc(img.nXTiles * img.nYTiles *
- sizeof(JPXTile));
+ nTiles = img.nXTiles * img.nYTiles;
+ allocSize = nTiles * sizeof(JPXTile);
+ // check for overflow before allocating memory
+ if (nTiles == 0 || nTiles / img.nXTiles != img.nYTiles ||
+ allocSize / sizeof(JPXTile) != nTiles) {
+ error(getPos(), "Bad tile count in JPX SIZ marker segment");
+ return gFalse;
+ }
+ img.tiles = (JPXTile *)gmalloc(allocSize);
       for (i = 0; i < img.nXTiles * img.nYTiles; ++i) {
        img.tiles[i].tileComps = (JPXTileComp *)gmalloc(img.nComps *
                                                        sizeof(JPXTileComp));

I added an additional allocSize variable and check it for int
overflow, to get the same effect as gmallocn() in the original xpdf
source.

HTH,

Martin
(who really wishes upstreams would switch to poppler after uploading
22 security update packgages)

--
Martin Pitt http://www.piware.de
Ubuntu Developer http://www.ubuntu.com
Debian Developer http://www.debian.org

In a world without walls and fences, who needs Windows and Gates?

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Thu, 8 Dec 2005 14:33:50 +0100
From: Martin Pitt <email address hidden>
To: Frank =?iso-8859-1?Q?K=FCster?= <email address hidden>
Cc: Martin Pitt <email address hidden>, <email address hidden>
Subject: Re: Bug#342292: Fwd: Re: [vendor-sec] xpdf update - patch wrong?

--XsQoSWH+UP9D9v3l
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hi Frank!

Frank K=FCster [2005-12-08 13:17 +0100]:
> Martin Pitt <email address hidden> wrote:
>=20
> > Hi!
> >
> > I'm currently preparing Ubuntu security updates for these issues, and
> > I noticed that the upstream provided patch is wrong. I sent the mail
> > below to upstream (and some others).
> >
> > Can you please check that you indeed fixed (tetex-bin)/will fix
> > (poppler) DCTStream::readProgressiveSOF(), too?
> [...]
> > 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().
>=20
> We have the same flaw in our upload. Would you be so kind and check the
> updated patch at=20
>=20
> http://svn.debian.org/wsvn/pkg-tetex/tetex-bin/trunk/debian/patches/patch=
-CVE-2005-3191+2+3?op=3Dfile&rev=3D0&sc=3D0

The DCTStream::readProgressiveSOF() seems to be correct now, however,
there is still a flaw in=20

- img.tiles =3D (JPXTile *)gmalloc(img.nXTiles * img.nYTiles *
- sizeof(JPXTile));
+ nTiles =3D img.nXTiles * img.nYTiles;
+ // check for overflow before allocating memory
+ if (nTiles =3D=3D 0 || nTiles / img.nXTiles !=3D img.nYTiles) {
+ error(getPos(), "Bad tile count in JPX SIZ marker segment");
+ return gFalse;
+ }
+ img.tiles =3D (JPXTile *)gmalloc(nTiles * sizeof(JPXTile));

gmalloc does a multiplication which is not checked for integer
overflows. xpdf uses gmallocn() which does that check.

I'll send you an updated patch very soon, I just finished patching
tetex-bin 2.0.2, cupsys, xpdf, poppler, etc.

Martin

--=20
Martin Pitt http://www.piware.de
Ubuntu Developer http://www.ubuntu.com
Debian Developer http://www.debian.org

In a world without walls and fences, who needs Windows and Gates?

--XsQoSWH+UP9D9v3l
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFDmDY+DecnbV4Fd/IRAtNaAJ9Z3WuPxQvhHVgDw6Kt1+WHROSDxACg6v1w
/HHv+Ap9V1siAkOVt3mZ+ZY=
=ktd+
-----END PGP SIGNATURE-----

--XsQoSWH+UP9D9v3l--

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Thu, 8 Dec 2005 14:55:55 +0100
From: Martin Pitt <email address hidden>
To: Frank =?iso-8859-1?Q?K=FCster?= <email address hidden>
Cc: <email address hidden>
Subject: Re: Bug#342292: Fwd: Re: [vendor-sec] xpdf update - patch wrong?

--NMuMz9nt05w80d4+
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hi Frank!

Frank K=FCster [2005-12-08 13:17 +0100]:
> We have the same flaw in our upload. Would you be so kind and check the
> updated patch at=20
>=20
> http://svn.debian.org/wsvn/pkg-tetex/tetex-bin/trunk/debian/patches/patch=
-CVE-2005-3191+2+3?op=3Dfile&rev=3D0&sc=3D0
>=20
> I'm completely illerate in C++, and would like to make sure this is
> correct. =20

OK, you can now find the 3.0 debdiff at=20

  http://patches.ubuntu.com/patches/tetex-bin.CVE-2005-3191_2_3.diff

it might be interesting for you to get the CVE numbers in the
changelog right. (Please do mention the CVE numbers to ease tracking.)

The essential difference is the JPXStream.cc diff, which now looks
like:

--- tetex-bin-3.0/libs/xpdf/xpdf/JPXStream.cc 2004-01-22 02:26:45.0000000=
00 +0100
+++ tetex-bin-3.0.new/libs/xpdf/xpdf/JPXStream.cc 2005-12-08 14:40:19=
=2E000000000 +0100
@@ -666,7 +666,8 @@
   int segType;
   GBool haveSIZ, haveCOD, haveQCD, haveSOT;
   Guint precinctSize, style;
- Guint segLen, capabilities, comp, i, j, r;
+ Guint segLen, capabilities, nTiles, comp, i, j, r;
+ Guint allocSize;

   //----- main header
   haveSIZ =3D haveCOD =3D haveQCD =3D haveSOT =3D gFalse;
@@ -701,8 +702,15 @@
                    / img.xTileSize;
       img.nYTiles =3D (img.ySize - img.yTileOffset + img.yTileSize - 1)
                    / img.yTileSize;
- img.tiles =3D (JPXTile *)gmalloc(img.nXTiles * img.nYTiles *
- sizeof(JPXTile));
+ nTiles =3D img.nXTiles * img.nYTiles;
+ allocSize =3D nTiles * sizeof(JPXTile);
+ // check for overflow before allocating memory
+ if (nTiles =3D=3D 0 || nTiles / img.nXTiles !=3D img.nYTiles ||
+ allocSize / sizeof(JPXTile) !=3D nTiles) {
+ error(getPos(), "Bad tile count in JPX SIZ marker segment");
+ return gFalse;
+ }
+ img.tiles =3D (JPXTile *)gmalloc(allocSize);
       for (i =3D 0; i < img.nXTiles * img.nYTiles; ++i) {
        img.tiles[i].tileComps =3D (JPXTileComp *)gmalloc(img.nComps *
                                                        sizeof(JPXTileComp)=
);

I added an additional allocSize variable and check it for int
overflow, to get the same effect as gmallocn() in the original xpdf
source.

HTH,

Martin
(who really wishes upstreams would switch to poppler after uploading
22 security update packgages)

--=20
Martin Pitt http://www.piware.de
Ubuntu Developer http://www.ubuntu.com
Debian Developer http://www.debian.org

In a world without walls and fences, who needs Windows and Gates?

--NMuMz9nt05w80d4+
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFDmDtrD...

[Rogério Theodoro de Brito (rbrito)]

On Dec 08 2005, Martin Pitt wrote:
> (who really wishes upstreams would switch to poppler after uploading
> 22 security update packgages)

Yes, but poppler is still not exactly a complete replacement for
xpdf---at least, that is what I understand from this bug of mine:
http://bugs.debian.org/340379

Cheers, Rogério Brito.
--
Rogério Brito : <email address hidden> : http://www.ime.usp.br/~rbrito
Homepage of the algorithms package : http://algorithms.berlios.de
Homepage on freshmeat: http://freshmeat.net/projects/algorithms/

[Frank Küster (frank-kuesterei)]

Martin Pitt <email address hidden> wrote:

> - img.tiles = (JPXTile *)gmalloc(img.nXTiles * img.nYTiles *
> - sizeof(JPXTile));
> + nTiles = img.nXTiles * img.nYTiles;
> + // check for overflow before allocating memory
> + if (nTiles == 0 || nTiles / img.nXTiles != img.nYTiles) {
> + error(getPos(), "Bad tile count in JPX SIZ marker segment");
> + return gFalse;
> + }
> + img.tiles = (JPXTile *)gmalloc(nTiles * sizeof(JPXTile));
>
> gmalloc does a multiplication which is not checked for integer
> overflows. xpdf uses gmallocn() which does that check.

xpdf has gmallocn only since 3.01, but tetex-bin uses 3.00. I wouldn't
want to update parts of the code, or all of it to 3.01, without
understanding the differences. On the other hand, maybe the xpdf code
in tetex-bin has *more* unchecked buffer overflows exactly because it
does not yet use gmallocn...

Would

      if (nTiles >= INT_MAX / sizeof(JPXTile) {
 error(getPos(), "Bad tile count in JPX SIZ marker segment");
 return gFalse;

be okay?

Regards, Frank

--
Frank Küster
Inst. f. Biochemie der Univ. Zürich
Debian Developer

[Frank Küster (frank-debian)]

Rogério Brito <email address hidden> wrote:

> On Dec 08 2005, Martin Pitt wrote:
>> (who really wishes upstreams would switch to poppler after uploading
>> 22 security update packgages)
>
> Yes, but poppler is still not exactly a complete replacement for
> xpdf---at least, that is what I understand from this bug of mine:
> http://bugs.debian.org/340379

One single bug need not mean that the library is not generally usable;
especially if it's "only" about viewing.

But the real concern that I have is whether the poppler people do
actually intend to become a "libxpdf". My impression from looking at
their homepage (a while ago, though) was that they wanted to create
something new on top of xpdf - a unified viewing and printing tool for
the desktop, based on pdf. But many projects that use xpdf code have a
different interest in xpdf: They use it for parsing, analysing and
manipulating PDF files, which is different from a user's point of view,
and I don't know whether it's also different from a developer's.

My concern is that if pdftex, pdftk, pdftohtml et al. start using
libpoppler now they might find in the future that libpoppler does not
all they need, or does not give proper support for them, because of its
different goal. I'd be very glad to hear that this not realistic, and
if I am such advised, I would be happy to create a patch for pdftex to
use poppler and submit it upstream.

Regards, Frank
--
Frank Küster
Inst. f. Biochemie der Univ. Zürich
Debian Developer

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Thu, 08 Dec 2005 15:54:49 +0100
From: =?iso-8859-1?q?Frank_K=FCster?= <email address hidden>
To: Martin Pitt <email address hidden>
Cc: Martin Pitt <email address hidden>, <email address hidden>
Subject: Re: Bug#342292: Fwd: Re: [vendor-sec] xpdf update - patch wrong?

Martin Pitt <email address hidden> wrote:

> - img.tiles =3D (JPXTile *)gmalloc(img.nXTiles * img.nYTiles *
> - sizeof(JPXTile));
> + nTiles =3D img.nXTiles * img.nYTiles;
> + // check for overflow before allocating memory
> + if (nTiles =3D=3D 0 || nTiles / img.nXTiles !=3D img.nYTiles) {
> + error(getPos(), "Bad tile count in JPX SIZ marker segment");
> + return gFalse;
> + }
> + img.tiles =3D (JPXTile *)gmalloc(nTiles * sizeof(JPXTile));
>
> gmalloc does a multiplication which is not checked for integer
> overflows. xpdf uses gmallocn() which does that check.

xpdf has gmallocn only since 3.01, but tetex-bin uses 3.00. I wouldn't
want to update parts of the code, or all of it to 3.01, without
understanding the differences. On the other hand, maybe the xpdf code
in tetex-bin has *more* unchecked buffer overflows exactly because it
does not yet use gmallocn...

Would=20

      if (nTiles >=3D INT_MAX / sizeof(JPXTile) {
 error(getPos(), "Bad tile count in JPX SIZ marker segment");
 return gFalse;

be okay?

Regards, Frank

--=20
Frank K=FCster
Inst. f. Biochemie der Univ. Z=FCrich
Debian Developer

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Thu, 8 Dec 2005 12:54:43 -0200
From: =?iso-8859-1?Q?Rog=E9rio?= Brito <email address hidden>
To: Martin Pitt <email address hidden>, <email address hidden>
Cc: Frank =?iso-8859-1?Q?K=FCster?= <email address hidden>
Subject: Re: Bug#342292: Fwd: Re: [vendor-sec] xpdf update - patch wrong?

On Dec 08 2005, Martin Pitt wrote:
> (who really wishes upstreams would switch to poppler after uploading
> 22 security update packgages)

Yes, but poppler is still not exactly a complete replacement for
xpdf---at least, that is what I understand from this bug of mine:
http://bugs.debian.org/340379

Cheers, Rog=E9rio Brito.
--=20
Rog=E9rio Brito : <email address hidden> : http://www.ime.usp.br/~rbrito
Homepage of the algorithms package : http://algorithms.berlios.de
Homepage on freshmeat: http://freshmeat.net/projects/algorithms/

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Thu, 08 Dec 2005 16:20:34 +0100
From: =?iso-8859-1?q?Frank_K=FCster?= <email address hidden>
To: =?iso-8859-1?q?Rog=E9rio_Brito?= <email address hidden>
Cc: <email address hidden>, Martin Pitt <email address hidden>,
        <email address hidden>
Subject: poppler as a replacement for xpdf code (was: Bug#342292: Fwd: Re:
 [vendor-sec] xpdf update - patch wrong?)

Rog=E9rio Brito <email address hidden> wrote:

> On Dec 08 2005, Martin Pitt wrote:
>> (who really wishes upstreams would switch to poppler after uploading
>> 22 security update packgages)
>
> Yes, but poppler is still not exactly a complete replacement for
> xpdf---at least, that is what I understand from this bug of mine:
> http://bugs.debian.org/340379

One single bug need not mean that the library is not generally usable;
especially if it's "only" about viewing.

But the real concern that I have is whether the poppler people do
actually intend to become a "libxpdf". My impression from looking at
their homepage (a while ago, though) was that they wanted to create
something new on top of xpdf - a unified viewing and printing tool for
the desktop, based on pdf. But many projects that use xpdf code have a
different interest in xpdf: They use it for parsing, analysing and
manipulating PDF files, which is different from a user's point of view,
and I don't know whether it's also different from a developer's.

My concern is that if pdftex, pdftk, pdftohtml et al. start using
libpoppler now they might find in the future that libpoppler does not
all they need, or does not give proper support for them, because of its
different goal. I'd be very glad to hear that this not realistic, and
if I am such advised, I would be happy to create a patch for pdftex to
use poppler and submit it upstream.

Regards, Frank
--=20
Frank K=FCster
Inst. f. Biochemie der Univ. Z=FCrich
Debian Developer

[Frank Küster (frank-debian)]

Martin Pitt <email address hidden> wrote:

> OK, you can now find the 3.0 debdiff at
>
> http://patches.ubuntu.com/patches/tetex-bin.CVE-2005-3191_2_3.diff

Thank you, I've added this.

> it might be interesting for you to get the CVE numbers in the
> changelog right. (Please do mention the CVE numbers to ease tracking.)

Thanks, sorry that I forgot it in the upload.

But I have more bad news. While looking at the patches, I noticed that
the patch for CAN-2004-0888 in tetex 3.0 still has the flaws in the
upstream/KDE/whoever patch. It does buffer overflow checks that some
compilers will simply optimize away ( if (size * sizeof(int)/sizeof(int)
!= size) and the like). In the upload to unstable back then, which was
2.0.2, we changed this to size >=MAX_INT / sizeof(int), but I obviously
did not do this in our copy.

I have started to fix this, see

http://svn.debian.org/wsvn/pkg-tetex/tetex-bin/trunk/debian/patches/patch-CAN-2004-0888?op=diff&rev=0&sc=0

however since the codebase differs I cannot simply use the patch from
tetex 2.0.2. Unfortunately, I don't have the original patch against 3.00
left, and I also cannot find it on the net.

It also seems that there are some buffer overflows in 3.00 that do not
have any tests, e.g. in XRef.cc, line 391 after patch-CAN-2004-0888 has
been applied. Or is such a check

      if (newSize < 0) {
 goto err1;
      }

enough to detect an integer overflow, because newSize is signed? 3.01
uses greallocn there.

Regards, Frank

--
Frank Küster
Inst. f. Biochemie der Univ. Zürich
Debian Developer

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Thu, 08 Dec 2005 17:28:15 +0100
From: =?iso-8859-1?q?Frank_K=FCster?= <email address hidden>
To: Martin Pitt <email address hidden>
Cc: <email address hidden>
Subject: Re: Bug#342292: Fwd: Re: [vendor-sec] xpdf update - patch wrong?

Martin Pitt <email address hidden> wrote:

> OK, you can now find the 3.0 debdiff at=20
>
> http://patches.ubuntu.com/patches/tetex-bin.CVE-2005-3191_2_3.diff

Thank you, I've added this.

> it might be interesting for you to get the CVE numbers in the
> changelog right. (Please do mention the CVE numbers to ease tracking.)

Thanks, sorry that I forgot it in the upload.

But I have more bad news. While looking at the patches, I noticed that
the patch for CAN-2004-0888 in tetex 3.0 still has the flaws in the
upstream/KDE/whoever patch. It does buffer overflow checks that some
compilers will simply optimize away ( if (size * sizeof(int)/sizeof(int)
!=3D size) and the like). In the upload to unstable back then, which was
2.0.2, we changed this to size >=3DMAX_INT / sizeof(int), but I obviously
did not do this in our copy.

I have started to fix this, see

http://svn.debian.org/wsvn/pkg-tetex/tetex-bin/trunk/debian/patches/patch-C=
AN-2004-0888?op=3Ddiff&rev=3D0&sc=3D0

however since the codebase differs I cannot simply use the patch from
tetex 2.0.2. Unfortunately, I don't have the original patch against 3.00
left, and I also cannot find it on the net.

It also seems that there are some buffer overflows in 3.00 that do not
have any tests, e.g. in XRef.cc, line 391 after patch-CAN-2004-0888 has
been applied. Or is such a check

      if (newSize < 0) {
 goto err1;
      }

enough to detect an integer overflow, because newSize is signed? 3.01
uses greallocn there.

Regards, Frank

--=20
Frank K=FCster
Inst. f. Biochemie der Univ. Z=FCrich
Debian Developer

[Florian Weimer (fw)]

* Frank Küster:

> It also seems that there are some buffer overflows in 3.00 that do not
> have any tests, e.g. in XRef.cc, line 391 after patch-CAN-2004-0888 has
> been applied. Or is such a check
>
> if (newSize < 0) {
> goto err1;
> }
>
> enough to detect an integer overflow, because newSize is signed?

No, it's not, see:

  <http://cert.uni-stuttgart.de/advisories/c-integer-overflow.php>

I should retry with GCC 4.1; it might actually perform the
optimization.

[Florian Weimer (fw)]

* Frank Küster:

> Would
>
> if (nTiles >= INT_MAX / sizeof(JPXTile) {
> error(getPos(), "Bad tile count in JPX SIZ marker segment");
> return gFalse;
>
> be okay?

It might still be a DoS issue, I think. Allocating arbitrary amounts
of memory upon user request is usually a bad idea. But gmallocn does
not touch the memory it allocates, so even very large allocations are
very cheap initially. As long as you initialize the allocated data
structure as you read more input, it should be a minor issue (because
you need an enormous file size to cause problems on even slightly
dated machines).

By the way, the gmallocn function suffers from undefined integer
overflow, too:

void *gmallocn(int nObjs, int objSize) {
  int n;

  n = nObjs * objSize;
  if (objSize == 0 || n / objSize != nObjs) {
    fprintf(stderr, "Bogus memory allocation size\n");
    exit(1);
  }
  return gmalloc(n);
}

The error handling is not suitable for library use, either. I don't
know if this is a problem.

PS: I haven't checked if the comparison "nTiles >= INT_MAX /
sizeof(JPXTile" is indeed correct and checks the right bound.

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Thu, 08 Dec 2005 22:03:19 +0100
From: Florian Weimer <email address hidden>
To: Frank =?iso-8859-1?Q?K=FCster?= <email address hidden>
Cc: <email address hidden>, Martin Pitt <email address hidden>
Subject: Re: Bug#342292: Fwd: Re: [vendor-sec] xpdf update - patch wrong?

* Frank K=FCster:

> It also seems that there are some buffer overflows in 3.00 that do not
> have any tests, e.g. in XRef.cc, line 391 after patch-CAN-2004-0888 has
> been applied. Or is such a check
>
> if (newSize < 0) {
> goto err1;
> }
>
> enough to detect an integer overflow, because newSize is signed?

No, it's not, see:

  <http://cert.uni-stuttgart.de/advisories/c-integer-overflow.php>

I should retry with GCC 4.1; it might actually perform the
optimization.

[Frank Küster (frank-kuesterei)]

Florian Weimer <email address hidden> wrote:

> * Frank Küster:
>
>> Would
>>
>> if (nTiles >= INT_MAX / sizeof(JPXTile) {
>> error(getPos(), "Bad tile count in JPX SIZ marker segment");
>> return gFalse;
>>
>> be okay?
>
> It might still be a DoS issue, I think. Allocating arbitrary amounts
> of memory upon user request is usually a bad idea. But gmallocn does
> not touch the memory it allocates, so even very large allocations are
> very cheap initially.

The function that is called in *tetex-bin* is not gmallocn, but gmalloc
- it's based on xpdf 3.00, not 3.01, and this is the very reason why I
need to check for an overflow in nTiles * sizeof(JPXTile).

> As long as you initialize the allocated data
> structure as you read more input, it should be a minor issue (because
> you need an enormous file size to cause problems on even slightly
> dated machines).

I have no idea what the code does, and I'm only starting to learn C and
know next to nothing about C++. Somebody else should check.

> By the way, the gmallocn function suffers from undefined integer
> overflow, too:
>
> void *gmallocn(int nObjs, int objSize) {
> int n;
>
> n = nObjs * objSize;
> if (objSize == 0 || n / objSize != nObjs) {
> fprintf(stderr, "Bogus memory allocation size\n");
> exit(1);
> }
> return gmalloc(n);
> }

What's the problem here? That the value in "n" is undefined, and
therefore the comparison n / objSize != nObjs is undefined, too?

This xpdf stuff seems to be a security nightmare by itself, even if not
copied to everybodies orig.tar.gz.

> The error handling is not suitable for library use, either. I don't
> know if this is a problem.

Only if the poppler people didn't notice...

Regards, Frank
--
Frank Küster
Inst. f. Biochemie der Univ. Zürich
Debian Developer

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Thu, 08 Dec 2005 22:21:53 +0100
From: Florian Weimer <email address hidden>
To: Frank =?iso-8859-1?Q?K=FCster?= <email address hidden>
Cc: <email address hidden>, Martin Pitt <email address hidden>, Martin Pitt <email address hidden>
Subject: Re: Bug#342292: Fwd: Re: [vendor-sec] xpdf update - patch wrong?

* Frank K=FCster:

> Would=20
>
> if (nTiles >=3D INT_MAX / sizeof(JPXTile) {
> error(getPos(), "Bad tile count in JPX SIZ marker segment");
> return gFalse;
>
> be okay?

It might still be a DoS issue, I think. Allocating arbitrary amounts
of memory upon user request is usually a bad idea. But gmallocn does
not touch the memory it allocates, so even very large allocations are
very cheap initially. As long as you initialize the allocated data
structure as you read more input, it should be a minor issue (because
you need an enormous file size to cause problems on even slightly
dated machines).

By the way, the gmallocn function suffers from undefined integer
overflow, too:

void *gmallocn(int nObjs, int objSize) {
  int n;

  n =3D nObjs * objSize;
  if (objSize =3D=3D 0 || n / objSize !=3D nObjs) {
    fprintf(stderr, "Bogus memory allocation size\n");
    exit(1);
  }
  return gmalloc(n);
}

The error handling is not suitable for library use, either. I don't
know if this is a problem.

PS: I haven't checked if the comparison "nTiles >=3D INT_MAX /
sizeof(JPXTile" is indeed correct and checks the right bound.

[Florian Weimer (fw)]

* Frank Küster:

> The function that is called in *tetex-bin* is not gmallocn, but gmalloc
> - it's based on xpdf 3.00, not 3.01, and this is the very reason why I
> need to check for an overflow in nTiles * sizeof(JPXTile).

Sure, I wanted to explain why this is not sufficient. It should be
equivalent to the gmallocn check (once that is fixed, as discussed).

>> By the way, the gmallocn function suffers from undefined integer
>> overflow, too:
>>
>> void *gmallocn(int nObjs, int objSize) {
>> int n;
>>
>> n = nObjs * objSize;
>> if (objSize == 0 || n / objSize != nObjs) {
>> fprintf(stderr, "Bogus memory allocation size\n");
>> exit(1);
>> }
>> return gmalloc(n);
>> }
>
> What's the problem here? That the value in "n" is undefined, and
> therefore the comparison n / objSize != nObjs is undefined, too?

Exactly. You have a strange way of learning C, most programmers learn
that signed integer overflow is undefined only after they've written
tens of thousands of lines of code. 8-)

> This xpdf stuff seems to be a security nightmare by itself, even if not
> copied to everybodies orig.tar.gz.

The xpdf code which we are discussing is pretty much industry
standard, I fear.
>
>> The error handling is not suitable for library use, either. I don't
>> know if this is a problem.
>
> Only if the poppler people didn't notice...

According to their CVS repository, they didn't. 8-(

I'm going to notify them. I'm also going to report the undefined
behavior problem to the xpdf folks.

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Thu, 08 Dec 2005 22:55:39 +0100
From: =?iso-8859-1?q?Frank_K=FCster?= <email address hidden>
To: Florian Weimer <email address hidden>
Cc: <email address hidden>, Martin Pitt <email address hidden>, Martin Pitt <email address hidden>
Subject: Re: Bug#342292: Fwd: Re: [vendor-sec] xpdf update - patch wrong?

Florian Weimer <email address hidden> wrote:

> * Frank K=FCster:
>
>> Would=20
>>
>> if (nTiles >=3D INT_MAX / sizeof(JPXTile) {
>> error(getPos(), "Bad tile count in JPX SIZ marker segment");
>> return gFalse;
>>
>> be okay?
>
> It might still be a DoS issue, I think. Allocating arbitrary amounts
> of memory upon user request is usually a bad idea. But gmallocn does
> not touch the memory it allocates, so even very large allocations are
> very cheap initially.

The function that is called in *tetex-bin* is not gmallocn, but gmalloc
- it's based on xpdf 3.00, not 3.01, and this is the very reason why I
need to check for an overflow in nTiles * sizeof(JPXTile).

> As long as you initialize the allocated data
> structure as you read more input, it should be a minor issue (because
> you need an enormous file size to cause problems on even slightly
> dated machines).

I have no idea what the code does, and I'm only starting to learn C and
know next to nothing about C++. Somebody else should check.

> By the way, the gmallocn function suffers from undefined integer
> overflow, too:
>
> void *gmallocn(int nObjs, int objSize) {
> int n;
>
> n =3D nObjs * objSize;
> if (objSize =3D=3D 0 || n / objSize !=3D nObjs) {
> fprintf(stderr, "Bogus memory allocation size\n");
> exit(1);
> }
> return gmalloc(n);
> }

What's the problem here? That the value in "n" is undefined, and
therefore the comparison n / objSize !=3D nObjs is undefined, too?

This xpdf stuff seems to be a security nightmare by itself, even if not
copied to everybodies orig.tar.gz.

> The error handling is not suitable for library use, either. I don't
> know if this is a problem.

Only if the poppler people didn't notice...

Regards, Frank
--=20
Frank K=FCster
Inst. f. Biochemie der Univ. Z=FCrich
Debian Developer

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Thu, 08 Dec 2005 23:19:53 +0100
From: Florian Weimer <email address hidden>
To: Frank =?iso-8859-1?Q?K=FCster?= <email address hidden>
Cc: <email address hidden>, Martin Pitt <email address hidden>, Martin Pitt <email address hidden>
Subject: Re: Bug#342292: Fwd: Re: [vendor-sec] xpdf update - patch wrong?

* Frank K=FCster:

> The function that is called in *tetex-bin* is not gmallocn, but gmalloc
> - it's based on xpdf 3.00, not 3.01, and this is the very reason why I
> need to check for an overflow in nTiles * sizeof(JPXTile).

Sure, I wanted to explain why this is not sufficient. It should be
equivalent to the gmallocn check (once that is fixed, as discussed).

>> By the way, the gmallocn function suffers from undefined integer
>> overflow, too:
>>
>> void *gmallocn(int nObjs, int objSize) {
>> int n;
>>
>> n =3D nObjs * objSize;
>> if (objSize =3D=3D 0 || n / objSize !=3D nObjs) {
>> fprintf(stderr, "Bogus memory allocation size\n");
>> exit(1);
>> }
>> return gmalloc(n);
>> }
>
> What's the problem here? That the value in "n" is undefined, and
> therefore the comparison n / objSize !=3D nObjs is undefined, too?

Exactly. You have a strange way of learning C, most programmers learn
that signed integer overflow is undefined only after they've written
tens of thousands of lines of code. 8-)

> This xpdf stuff seems to be a security nightmare by itself, even if not
> copied to everybodies orig.tar.gz.

The xpdf code which we are discussing is pretty much industry
standard, I fear.
>
>> The error handling is not suitable for library use, either. I don't
>> know if this is a problem.
>
> Only if the poppler people didn't notice...

According to their CVS repository, they didn't. 8-(

I'm going to notify them. I'm also going to report the undefined
behavior problem to the xpdf folks.

[Martin Pitt (pitti)]

Hi!

Frank Küster [2005-12-08 15:54 +0100]:
> Martin Pitt <email address hidden> wrote:
>
> > - img.tiles = (JPXTile *)gmalloc(img.nXTiles * img.nYTiles *
> > - sizeof(JPXTile));
> > + nTiles = img.nXTiles * img.nYTiles;
> > + // check for overflow before allocating memory
> > + if (nTiles == 0 || nTiles / img.nXTiles != img.nYTiles) {
> > + error(getPos(), "Bad tile count in JPX SIZ marker segment");
> > + return gFalse;
> > + }
> > + img.tiles = (JPXTile *)gmalloc(nTiles * sizeof(JPXTile));
> >
> > gmalloc does a multiplication which is not checked for integer
> > overflows. xpdf uses gmallocn() which does that check.
>
> xpdf has gmallocn only since 3.01, but tetex-bin uses 3.00. I wouldn't
> want to update parts of the code, or all of it to 3.01, without
> understanding the differences. On the other hand, maybe the xpdf code
> in tetex-bin has *more* unchecked buffer overflows exactly because it
> does not yet use gmallocn...

Possibly. gmallocn() is just a shallow wrapper around gmalloc() with
integer overflow checking, so it's not a big deal.

> Would
>
> if (nTiles >= INT_MAX / sizeof(JPXTile) {
> error(getPos(), "Bad tile count in JPX SIZ marker segment");
> return gFalse;
>
> be okay?

This is the standard way of checking for multiplicative overflows,
that looks fine.

Martin

--
Martin Pitt http://www.piware.de
Ubuntu Developer http://www.ubuntu.com
Debian Developer http://www.debian.org

In a world without walls and fences, who needs Windows and Gates?

[Martin Pitt (pitti)]

Hi Frank!

Frank Küster [2005-12-08 13:17 +0100]:
> Martin Pitt <email address hidden> wrote:
>
> > Hi!
> >
> > I'm currently preparing Ubuntu security updates for these issues, and
> > I noticed that the upstream provided patch is wrong. I sent the mail
> > below to upstream (and some others).
> >
> > Can you please check that you indeed fixed (tetex-bin)/will fix
> > (poppler) DCTStream::readProgressiveSOF(), too?
> [...]
> > 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().
>
> We have the same flaw in our upload. Would you be so kind and check the
> updated patch at
>
> http://svn.debian.org/wsvn/pkg-tetex/tetex-bin/trunk/debian/patches/patch-CVE-2005-3191+2+3?op=file&rev=0&sc=0
>
> I'm completely illerate in C++, and would like to make sure this is
> correct.

Bad news. A further review of Streams.cc revealed a third place where
numComps goes unchecked (I checked the whole file now, it's really the
last one). So you additionally need this hunk:

@@ -2947,6 +2974,10 @@ GBool DCTStream::readScanInfo() {

   length = read16() - 2;
   scanInfo.numComps = str->getChar();
+ if (scanInfo.numComps <= 0 || scanInfo.numComps > 4) {
+ error(getPos(), "Bad number of components in DCT stream");
+ return gFalse;
+ }
   --length;
   if (length != 2 * scanInfo.numComps + 3) {
     error(getPos(), "Bad DCT scan info block");

Martin
--
Martin Pitt http://www.piware.de
Ubuntu Developer http://www.ubuntu.com
Debian Developer http://www.debian.org

In a world without walls and fences, who needs Windows and Gates?

[Martin Pitt (pitti)]

Hi Florian, hi Frank!

Frank Küster [2005-12-08 22:55 +0100]:
> Florian Weimer <email address hidden> wrote:
> > By the way, the gmallocn function suffers from undefined integer
> > overflow, too:
> >
> > void *gmallocn(int nObjs, int objSize) {
> > int n;
> >
> > n = nObjs * objSize;
> > if (objSize == 0 || n / objSize != nObjs) {
> > fprintf(stderr, "Bogus memory allocation size\n");
> > exit(1);
> > }
> > return gmalloc(n);
> > }
>
> What's the problem here? That the value in "n" is undefined, and
> therefore the comparison n / objSize != nObjs is undefined, too?

n is not 'undefined' here. For every given nObjs and objSize input, it
always gets the same well-defined value.

We can assume that objSize is a small positive number, since it is not
user defined (just a sizeof value). The function works correctly for
positive number of nObjs (both valid and invalid), but there is a
corner case for negative nOjbs. Since gmalloc() takes a size_t
(unsigned), in most cases gmalloc() will allocate more memory than
required for a negative argument. However, when n is exactly -2^31 you
could see an off-by-one memory allocation error.

Indeed the function should completely be written using unsigned
arithmetics, otherwise your head will just explode.

Florian, is that what you meant?

Thanks,

Martin
--
Martin Pitt http://www.piware.de
Ubuntu Developer http://www.ubuntu.com
Debian Developer http://www.debian.org

In a world without walls and fences, who needs Windows and Gates?

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Fri, 9 Dec 2005 10:17:51 +0100
From: Martin Pitt <email address hidden>
To: Frank =?iso-8859-1?Q?K=FCster?= <email address hidden>
Cc: Martin Pitt <email address hidden>, Martin Pitt <email address hidden>, <email address hidden>
Subject: Re: Bug#342292: Fwd: Re: [vendor-sec] xpdf update - patch wrong?

--7LkOrbQMr4cezO2T
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hi!

Frank K=FCster [2005-12-08 15:54 +0100]:
> Martin Pitt <email address hidden> wrote:
>=20
> > - img.tiles =3D (JPXTile *)gmalloc(img.nXTiles * img.nYTiles *
> > - sizeof(JPXTile));
> > + nTiles =3D img.nXTiles * img.nYTiles;
> > + // check for overflow before allocating memory
> > + if (nTiles =3D=3D 0 || nTiles / img.nXTiles !=3D img.nYTiles) {
> > + error(getPos(), "Bad tile count in JPX SIZ marker segment");
> > + return gFalse;
> > + }
> > + img.tiles =3D (JPXTile *)gmalloc(nTiles * sizeof(JPXTile));
> >
> > gmalloc does a multiplication which is not checked for integer
> > overflows. xpdf uses gmallocn() which does that check.
>=20
> xpdf has gmallocn only since 3.01, but tetex-bin uses 3.00. I wouldn't
> want to update parts of the code, or all of it to 3.01, without
> understanding the differences. On the other hand, maybe the xpdf code
> in tetex-bin has *more* unchecked buffer overflows exactly because it
> does not yet use gmallocn...

Possibly. gmallocn() is just a shallow wrapper around gmalloc() with
integer overflow checking, so it's not a big deal.

> Would=20
>=20
> if (nTiles >=3D INT_MAX / sizeof(JPXTile) {
> error(getPos(), "Bad tile count in JPX SIZ marker segment");
> return gFalse;
>=20
> be okay?

This is the standard way of checking for multiplicative overflows,
that looks fine.

Martin

--=20
Martin Pitt http://www.piware.de
Ubuntu Developer http://www.ubuntu.com
Debian Developer http://www.debian.org

In a world without walls and fences, who needs Windows and Gates?

--7LkOrbQMr4cezO2T
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFDmUu/DecnbV4Fd/IRAlO5AKCNMZgei17LJra3eFPATfqWOWv8SwCggVxa
c3P8msl8pXRk7p4AajZOgDQ=
=fSFz
-----END PGP SIGNATURE-----

--7LkOrbQMr4cezO2T--

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Fri, 9 Dec 2005 10:19:51 +0100
From: Martin Pitt <email address hidden>
To: Frank =?iso-8859-1?Q?K=FCster?= <email address hidden>
Cc: <email address hidden>
Subject: Re: Bug#342292: Fwd: Re: [vendor-sec] xpdf update - patch wrong?

--+jhVVhN62yS6hEJ8
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hi Frank!

Frank K=FCster [2005-12-08 13:17 +0100]:
> Martin Pitt <email address hidden> wrote:
>=20
> > Hi!
> >
> > I'm currently preparing Ubuntu security updates for these issues, and
> > I noticed that the upstream provided patch is wrong. I sent the mail
> > below to upstream (and some others).
> >
> > Can you please check that you indeed fixed (tetex-bin)/will fix
> > (poppler) DCTStream::readProgressiveSOF(), too?
> [...]
> > 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().
>=20
> We have the same flaw in our upload. Would you be so kind and check the
> updated patch at=20
>=20
> http://svn.debian.org/wsvn/pkg-tetex/tetex-bin/trunk/debian/patches/patch=
-CVE-2005-3191+2+3?op=3Dfile&rev=3D0&sc=3D0
>=20
> I'm completely illerate in C++, and would like to make sure this is
> correct. =20

Bad news. A further review of Streams.cc revealed a third place where
numComps goes unchecked (I checked the whole file now, it's really the
last one). So you additionally need this hunk:

@@ -2947,6 +2974,10 @@ GBool DCTStream::readScanInfo() {

   length =3D read16() - 2;
   scanInfo.numComps =3D str->getChar();
+ if (scanInfo.numComps <=3D 0 || scanInfo.numComps > 4) {
+ error(getPos(), "Bad number of components in DCT stream");
+ return gFalse;
+ }
   --length;
   if (length !=3D 2 * scanInfo.numComps + 3) {
     error(getPos(), "Bad DCT scan info block");

Martin
--=20
Martin Pitt http://www.piware.de
Ubuntu Developer http://www.ubuntu.com
Debian Developer http://www.debian.org

In a world without walls and fences, who needs Windows and Gates?

--+jhVVhN62yS6hEJ8
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFDmUw3DecnbV4Fd/IRAt7+AJ9pMDVGX9iAVYm32Kth2vIaF1RLQgCdG7Fs
DWxut0KwwqiiFdtA2Ye430U=
=PtJ0
-----END PGP SIGNATURE-----

--+jhVVhN62yS6hEJ8--

[Frank Küster (frank-kuesterei)]

Martin Pitt <email address hidden> wrote:

> Hi Florian, hi Frank!
>
> Frank Küster [2005-12-08 22:55 +0100]:
>> Florian Weimer <email address hidden> wrote:
>> > By the way, the gmallocn function suffers from undefined integer
>> > overflow, too:
>> >
>> > void *gmallocn(int nObjs, int objSize) {
>> > int n;
>> >
>> > n = nObjs * objSize;
>> > if (objSize == 0 || n / objSize != nObjs) {
>> > fprintf(stderr, "Bogus memory allocation size\n");
>> > exit(1);
>> > }
>> > return gmalloc(n);
>> > }
>>
>> What's the problem here? That the value in "n" is undefined, and
>> therefore the comparison n / objSize != nObjs is undefined, too?
>
> n is not 'undefined' here. For every given nObjs and objSize input, it
> always gets the same well-defined value.
>
> We can assume that objSize is a small positive number, since it is not
> user defined (just a sizeof value). The function works correctly for
> positive number of nObjs (both valid and invalid),

But what if nObjs * objSize is larger than fits into an int?

Regards, Frank
--
Frank Küster
Inst. f. Biochemie der Univ. Zürich
Debian Developer

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Fri, 9 Dec 2005 10:40:39 +0100
From: Martin Pitt <email address hidden>
To: Frank =?iso-8859-1?Q?K=FCster?= <email address hidden>,
 Florian Weimer <email address hidden>
Cc: <email address hidden>
Subject: Re: Bug#342292: Fwd: Re: [vendor-sec] xpdf update - patch wrong?

--+sHJum3is6Tsg7/J
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hi Florian, hi Frank!

Frank K=FCster [2005-12-08 22:55 +0100]:
> Florian Weimer <email address hidden> wrote:
> > By the way, the gmallocn function suffers from undefined integer
> > overflow, too:
> >
> > void *gmallocn(int nObjs, int objSize) {
> > int n;
> >
> > n =3D nObjs * objSize;
> > if (objSize =3D=3D 0 || n / objSize !=3D nObjs) {
> > fprintf(stderr, "Bogus memory allocation size\n");
> > exit(1);
> > }
> > return gmalloc(n);
> > }
>=20
> What's the problem here? That the value in "n" is undefined, and
> therefore the comparison n / objSize !=3D nObjs is undefined, too?

n is not 'undefined' here. For every given nObjs and objSize input, it
always gets the same well-defined value.

We can assume that objSize is a small positive number, since it is not
user defined (just a sizeof value). The function works correctly for
positive number of nObjs (both valid and invalid), but there is a
corner case for negative nOjbs. Since gmalloc() takes a size_t
(unsigned), in most cases gmalloc() will allocate more memory than
required for a negative argument. However, when n is exactly -2^31 you
could see an off-by-one memory allocation error.

Indeed the function should completely be written using unsigned
arithmetics, otherwise your head will just explode.

Florian, is that what you meant?

Thanks,

Martin
--=20
Martin Pitt http://www.piware.de
Ubuntu Developer http://www.ubuntu.com
Debian Developer http://www.debian.org

In a world without walls and fences, who needs Windows and Gates?

--+sHJum3is6Tsg7/J
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFDmVEXDecnbV4Fd/IRAszsAKDLSb1yiFXd8tN7vuSDWheEj29JrQCgrmNY
fW6rC4vrRfj4o5hr9fL/tiU=
=lnnp
-----END PGP SIGNATURE-----

--+sHJum3is6Tsg7/J--

[Martin Pitt (pitti)]

Hi!

Frank Küster [2005-12-09 11:09 +0100]:
> Martin Pitt <email address hidden> wrote:
>
> > Hi Florian, hi Frank!
> >
> > Frank Küster [2005-12-08 22:55 +0100]:
> >> Florian Weimer <email address hidden> wrote:
> >> > By the way, the gmallocn function suffers from undefined integer
> >> > overflow, too:
> >> >
> >> > void *gmallocn(int nObjs, int objSize) {
> >> > int n;
> >> >
> >> > n = nObjs * objSize;
> >> > if (objSize == 0 || n / objSize != nObjs) {
> >> > fprintf(stderr, "Bogus memory allocation size\n");
> >> > exit(1);
> >> > }
> >> > return gmalloc(n);
> >> > }
> >>
> >> What's the problem here? That the value in "n" is undefined, and
> >> therefore the comparison n / objSize != nObjs is undefined, too?
> >
> > n is not 'undefined' here. For every given nObjs and objSize input, it
> > always gets the same well-defined value.
> >
> > We can assume that objSize is a small positive number, since it is not
> > user defined (just a sizeof value). The function works correctly for
> > positive number of nObjs (both valid and invalid),
>
> But what if nObjs * objSize is larger than fits into an int?

Handling this case is the sole purpose of this gmallocn() wrapper.

Let N be the product of nObjs * objSize in the naturals.

- For valid (small) positive values of nObjs, n == N and the division is ok.

- For invalid (big) positive values of nObjs which, when multiplied with nObjs
  overflow an int, we have two cases:

  * n == N mod 2^31 (i. e. product overflows into the positive half of int space)
    => n < N
    => n/objSize < N/objSize
    => n/objSize < nObjs
    => n/objSize != nObjs
    => check fails.

  * n < 0
    => n/objSize < 0
    => since by assumption nObjs > 0: n/objSize != nObjs
    => check fails.

As I already said, the function will cause trouble (allocating
insanely amounts of memory, but probably not an overflow) for negative
nObjs. Thus, the function should either use unsigneds, or at least
check that nObjs and objSize > 0.

Martin

--
Martin Pitt http://www.piware.de
Ubuntu Developer http://www.ubuntu.com
Debian Developer http://www.debian.org

In a world without walls and fences, who needs Windows and Gates?

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Fri, 09 Dec 2005 11:09:26 +0100
From: =?iso-8859-1?q?Frank_K=FCster?= <email address hidden>
To: Martin Pitt <email address hidden>
Cc: Florian Weimer <email address hidden>, <email address hidden>
Subject: Re: Bug#342292: Fwd: Re: [vendor-sec] xpdf update - patch wrong?

Martin Pitt <email address hidden> wrote:

> Hi Florian, hi Frank!
>
> Frank K=FCster [2005-12-08 22:55 +0100]:
>> Florian Weimer <email address hidden> wrote:
>> > By the way, the gmallocn function suffers from undefined integer
>> > overflow, too:
>> >
>> > void *gmallocn(int nObjs, int objSize) {
>> > int n;
>> >
>> > n =3D nObjs * objSize;
>> > if (objSize =3D=3D 0 || n / objSize !=3D nObjs) {
>> > fprintf(stderr, "Bogus memory allocation size\n");
>> > exit(1);
>> > }
>> > return gmalloc(n);
>> > }
>>=20
>> What's the problem here? That the value in "n" is undefined, and
>> therefore the comparison n / objSize !=3D nObjs is undefined, too?
>
> n is not 'undefined' here. For every given nObjs and objSize input, it
> always gets the same well-defined value.
>
> We can assume that objSize is a small positive number, since it is not
> user defined (just a sizeof value). The function works correctly for
> positive number of nObjs (both valid and invalid),=20

But what if nObjs * objSize is larger than fits into an int?

Regards, Frank
--=20
Frank K=FCster
Inst. f. Biochemie der Univ. Z=FCrich
Debian Developer

[Florian Weimer (fw)]

* Martin Pitt:

> - For invalid (big) positive values of nObjs which, when multiplied with nObjs
> overflow an int, we have two cases:

But neither ISO C nor GNU C make any promises regarding this case.
Overflow is undefined, period.

You can pass -fwrapv to gcc if you want modulo arithmetic for ints.
In general, this decreases code quality, that's why it's not the
default.

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Fri, 9 Dec 2005 11:20:29 +0100
From: Martin Pitt <email address hidden>
To: Frank =?iso-8859-1?Q?K=FCster?= <email address hidden>
Cc: Martin Pitt <email address hidden>,
 Florian Weimer <email address hidden>, <email address hidden>
Subject: Re: Bug#342292: Fwd: Re: [vendor-sec] xpdf update - patch wrong?

--rCb8EA+9TsBVtA92
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hi!

Frank K=FCster [2005-12-09 11:09 +0100]:
> Martin Pitt <email address hidden> wrote:
>=20
> > Hi Florian, hi Frank!
> >
> > Frank K=FCster [2005-12-08 22:55 +0100]:
> >> Florian Weimer <email address hidden> wrote:
> >> > By the way, the gmallocn function suffers from undefined integer
> >> > overflow, too:
> >> >
> >> > void *gmallocn(int nObjs, int objSize) {
> >> > int n;
> >> >
> >> > n =3D nObjs * objSize;
> >> > if (objSize =3D=3D 0 || n / objSize !=3D nObjs) {
> >> > fprintf(stderr, "Bogus memory allocation size\n");
> >> > exit(1);
> >> > }
> >> > return gmalloc(n);
> >> > }
> >>=20
> >> What's the problem here? That the value in "n" is undefined, and
> >> therefore the comparison n / objSize !=3D nObjs is undefined, too?
> >
> > n is not 'undefined' here. For every given nObjs and objSize input, it
> > always gets the same well-defined value.
> >
> > We can assume that objSize is a small positive number, since it is not
> > user defined (just a sizeof value). The function works correctly for
> > positive number of nObjs (both valid and invalid),=20
>=20
> But what if nObjs * objSize is larger than fits into an int?

Handling this case is the sole purpose of this gmallocn() wrapper.

Let N be the product of nObjs * objSize in the naturals.

- For valid (small) positive values of nObjs, n =3D=3D N and the division i=
s ok.

- For invalid (big) positive values of nObjs which, when multiplied with nO=
bjs
  overflow an int, we have two cases:

  * n =3D=3D N mod 2^31 (i. e. product overflows into the positive half of =
int space)=20
    =3D> n < N=20
    =3D> n/objSize < N/objSize
    =3D> n/objSize < nObjs=20
    =3D> n/objSize !=3D nObjs=20
    =3D> check fails.

  * n < 0=20
    =3D> n/objSize < 0=20
    =3D> since by assumption nObjs > 0: n/objSize !=3D nObjs
    =3D> check fails.

As I already said, the function will cause trouble (allocating
insanely amounts of memory, but probably not an overflow) for negative
nObjs. Thus, the function should either use unsigneds, or at least
check that nObjs and objSize > 0.

Martin

--=20
Martin Pitt http://www.piware.de
Ubuntu Developer http://www.ubuntu.com
Debian Developer http://www.debian.org

In a world without walls and fences, who needs Windows and Gates?

--rCb8EA+9TsBVtA92
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFDmVptDecnbV4Fd/IRAmtvAKCkECmWdeZdDA9fBKY5RPW2C4UhAACg18/0
2lsXexzwnUlA8gICcbb7DJc=
=ZeJj
-----END PGP SIGNATURE-----

--rCb8EA+9TsBVtA92--

[Martin Pitt (pitti)]

Hi Florian!

Florian Weimer [2005-12-09 11:53 +0100]:
> * Martin Pitt:
>
> > - For invalid (big) positive values of nObjs which, when multiplied with nObjs
> > overflow an int, we have two cases:
>
> But neither ISO C nor GNU C make any promises regarding this case.
> Overflow is undefined, period.

Ah, right, I mixed that up with additive overflow (which is defined).
Thanks for the cluebat.

Well, in terms of the current security update this is irrelevant
anyway since gmalloc() is not yet used.

Martin

--
Martin Pitt http://www.piware.de
Ubuntu Developer http://www.ubuntu.com
Debian Developer http://www.debian.org

In a world without walls and fences, who needs Windows and Gates?

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Fri, 09 Dec 2005 11:53:58 +0100
From: Florian Weimer <email address hidden>
To: Martin Pitt <email address hidden>
Cc: Frank =?iso-8859-1?Q?K=FCster?= <email address hidden>,
  <email address hidden>
Subject: Re: Bug#342292: Fwd: Re: [vendor-sec] xpdf update - patch wrong?

* Martin Pitt:

> - For invalid (big) positive values of nObjs which, when multiplied with nObjs
> overflow an int, we have two cases:

But neither ISO C nor GNU C make any promises regarding this case.
Overflow is undefined, period.

You can pass -fwrapv to gcc if you want modulo arithmetic for ints.
In general, this decreases code quality, that's why it's not the
default.

[Florian Weimer (fw)]

* Martin Pitt:

> Hi Florian!
>
> Florian Weimer [2005-12-09 11:53 +0100]:
>> * Martin Pitt:
>>
>> > - For invalid (big) positive values of nObjs which, when multiplied with nObjs
>> > overflow an int, we have two cases:
>>
>> But neither ISO C nor GNU C make any promises regarding this case.
>> Overflow is undefined, period.
>
> Ah, right, I mixed that up with additive overflow (which is defined).

I think you mean unsigned arithmetic, which is performed module 2^k
for some k.

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Fri, 9 Dec 2005 12:05:56 +0100
From: Martin Pitt <email address hidden>
To: Florian Weimer <email address hidden>
Cc: Martin Pitt <email address hidden>, Frank =?iso-8859-1?Q?K=FCster?= <email address hidden>,
 <email address hidden>
Subject: Re: Bug#342292: Fwd: Re: [vendor-sec] xpdf update - patch wrong?

--F4+N/OgRSdC8YnqX
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hi Florian!

Florian Weimer [2005-12-09 11:53 +0100]:
> * Martin Pitt:
>=20
> > - For invalid (big) positive values of nObjs which, when multiplied wit=
h nObjs
> > overflow an int, we have two cases:
>=20
> But neither ISO C nor GNU C make any promises regarding this case.
> Overflow is undefined, period.

Ah, right, I mixed that up with additive overflow (which is defined).
Thanks for the cluebat.

Well, in terms of the current security update this is irrelevant
anyway since gmalloc() is not yet used.

Martin

--=20
Martin Pitt http://www.piware.de
Ubuntu Developer http://www.ubuntu.com
Debian Developer http://www.debian.org

In a world without walls and fences, who needs Windows and Gates?

--F4+N/OgRSdC8YnqX
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFDmWUUDecnbV4Fd/IRAolAAJ9l3dDFzrUj9qsSbHvBIMhmrdWZXgCfaQQe
oO5X9KIIZ+zx5AfSZfuM4sQ=
=hMDr
-----END PGP SIGNATURE-----

--F4+N/OgRSdC8YnqX--

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Fri, 09 Dec 2005 12:42:45 +0100
From: Florian Weimer <email address hidden>
To: Martin Pitt <email address hidden>
Cc: Frank =?iso-8859-1?Q?K=FCster?= <email address hidden>,
  <email address hidden>
Subject: Re: Bug#342292: Fwd: Re: [vendor-sec] xpdf update - patch wrong?

* Martin Pitt:

> Hi Florian!
>
> Florian Weimer [2005-12-09 11:53 +0100]:
>> * Martin Pitt:
>>
>> > - For invalid (big) positive values of nObjs which, when multiplied with nObjs
>> > overflow an int, we have two cases:
>>
>> But neither ISO C nor GNU C make any promises regarding this case.
>> Overflow is undefined, period.
>
> Ah, right, I mixed that up with additive overflow (which is defined).

I think you mean unsigned arithmetic, which is performed module 2^k
for some k.

[Martin Schulze (joey-infodrom)]

Frank Küster wrote:
> The upstream patch applies cleanly to xpdf/Stream.{cc,h} in sarge, but
> JPXStream.cc does not exist. But the functions might still be defined
> elsewhere.
>
> The patch does not apply cleanly, except for Stream.h, in woody, but at
> least one affected line in Stream.cc *does* exist.
>
> As I said previously, I will not be able to work on this.

The original patch was not sufficient. I'm attaching the entire and the
incremental patch. Please apply the incremental patch to the version in
sid as well.

Regards,

 Joey

--
Have you ever noticed that "General Public Licence" contains the word "Pub"?

Please always Cc to me when replying to me on the lists.

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Fri, 9 Dec 2005 15:47:03 +0100
From: Martin Schulze <email address hidden>
To: Frank =?iso-8859-1?Q?K=FCster?= <email address hidden>
Cc: <email address hidden>,
 Debian Security Team <email address hidden>
Subject: Re: Bug#342292: tetex-bin: Multiple exploitable heap overflows in embedded xpdf copy

--vGgW1X5XWziG23Ko
Content-Type: multipart/mixed; boundary="5mCyUwZo2JvN/JJP"
Content-Disposition: inline

--5mCyUwZo2JvN/JJP
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Frank K=FCster wrote:
> The upstream patch applies cleanly to xpdf/Stream.{cc,h} in sarge, but
> JPXStream.cc does not exist. But the functions might still be defined
> elsewhere.
>=20
> The patch does not apply cleanly, except for Stream.h, in woody, but at
> least one affected line in Stream.cc *does* exist.
>=20
> As I said previously, I will not be able to work on this.

The original patch was not sufficient. I'm attaching the entire and the
incremental patch. Please apply the incremental patch to the version in
sid as well.

Regards,

 Joey

--=20
Have you ever noticed that "General Public Licence" contains the word "Pub"?

Please always Cc to me when replying to me on the lists.

--5mCyUwZo2JvN/JJP
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: attachment; filename="patch.sarge"
Content-Transfer-Encoding: quoted-printable

diff -u tetex-bin-2.0.2/debian/changelog tetex-bin-2.0.2/debian/changelog
--- tetex-bin-2.0.2/debian/changelog
+++ tetex-bin-2.0.2/debian/changelog
@@ -1,3 +1,20 @@
+tetex-bin (2.0.2-30sarge2) stable-security; urgency=3Dhigh
+
+ * Non-maintainer upload by the Security Team
+ * Adjusted the former patch
+ * Applied missing bits found by Ludwig Nussel
+
+ -- Martin Schulze <email address hidden> Fri, 9 Dec 2005 11:25:16 +0100
+
+tetex-bin (2.0.2-30sarge1) stable-security; urgency=3Dhigh
+
+ * Non-maintainer upload by the Security Team
+ * Partially applied patch from xpdf upstream to fix buffer overflows
+ [libs/xpdf/xpdf/Stream.cc, libs/xpdf/xpdf/Stream.h, CAN-2005-3191,
+ debian/patches/patch-CVE-2005-3191]
+
+ -- Martin Schulze <email address hidden> Thu, 8 Dec 2005 10:19:45 +0100
+
 tetex-bin (2.0.2-30) unstable; urgency=3Dlow
=20
   * Restore debian/watch and don't keep the recovered control file in
diff -u tetex-bin-2.0.2/debian/rules tetex-bin-2.0.2/debian/rules
--- tetex-bin-2.0.2/debian/rules
+++ tetex-bin-2.0.2/debian/rules
@@ -57,6 +57,8 @@
  patch -p1 -Ni debian/patches/patch-CAN-2005-0064
  patch -p1 -NRi debian/patches/patch-mandash || true
  patch -p1 -Ni debian/patches/patch-mandash
+ patch -p1 -NRi debian/patches/patch-CVE-2005-3191 || true
+ patch -p1 -Ni debian/patches/patch-CVE-2005-3191
  cp -f /usr/share/misc/config.guess /usr/share/misc/config.sub ./texk/
  cp -f /usr/share/misc/config.guess /usr/share/misc/config.sub ./utils/tex=
info/
  cp -f /usr/share/misc/config.guess /usr/share/misc/config.sub ./config/
@@ -95,6 +97,7 @@
  # Add here commands to clean up after the build process.
  # Make sure all of our expected symlinks are in place
  sh debian/restore-syml...

[Martin Pitt (pitti)]

Hi Frank, hi Florian!

Frank Küster [2005-12-08 13:17 +0100]:
> Martin Pitt <email address hidden> wrote:
>
> > Hi!
> >
> > I'm currently preparing Ubuntu security updates for these issues, and
> > I noticed that the upstream provided patch is wrong. I sent the mail
> > below to upstream (and some others).
> >
> > Can you please check that you indeed fixed (tetex-bin)/will fix
> > (poppler) DCTStream::readProgressiveSOF(), too?
> [...]
> > 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().
>
> We have the same flaw in our upload. Would you be so kind and check the
> updated patch at
>
> http://svn.debian.org/wsvn/pkg-tetex/tetex-bin/trunk/debian/patches/patch-CVE-2005-3191+2+3?op=file&rev=0&sc=0

After discovering that the same flawed multiplication is also present
in upstream's other two patches, I decided to completely rework the
patch.

I attach the debdiff with separated out changelog. Florian, maybe you
can peer-review the patch?

Thanks!

Martin
--
Martin Pitt http://www.piware.de
Ubuntu Developer http://www.ubuntu.com
Debian Developer http://www.debian.org

In a world without walls and fences, who needs Windows and Gates?

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Fri, 9 Dec 2005 17:21:14 +0100
From: Martin Pitt <email address hidden>
To: Frank =?iso-8859-1?Q?K=FCster?= <email address hidden>
Cc: Martin Pitt <email address hidden>, <email address hidden>,
 Florian Weimer <email address hidden>
Subject: Re: Bug#342292: Fwd: Re: [vendor-sec] xpdf update - patch wrong?

--QHhm1I6mwQR20oIa
Content-Type: multipart/mixed; boundary="IUSVF+LtaR4kWxuH"
Content-Disposition: inline

--IUSVF+LtaR4kWxuH
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hi Frank, hi Florian!

Frank K=FCster [2005-12-08 13:17 +0100]:
> Martin Pitt <email address hidden> wrote:
>=20
> > Hi!
> >
> > I'm currently preparing Ubuntu security updates for these issues, and
> > I noticed that the upstream provided patch is wrong. I sent the mail
> > below to upstream (and some others).
> >
> > Can you please check that you indeed fixed (tetex-bin)/will fix
> > (poppler) DCTStream::readProgressiveSOF(), too?
> [...]
> > 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().
>=20
> We have the same flaw in our upload. Would you be so kind and check the
> updated patch at=20
>=20
> http://svn.debian.org/wsvn/pkg-tetex/tetex-bin/trunk/debian/patches/patch=
-CVE-2005-3191+2+3?op=3Dfile&rev=3D0&sc=3D0

After discovering that the same flawed multiplication is also present
in upstream's other two patches, I decided to completely rework the
patch.

I attach the debdiff with separated out changelog. Florian, maybe you
can peer-review the patch?

Thanks!

Martin
--=20
Martin Pitt http://www.piware.de
Ubuntu Developer http://www.ubuntu.com
Debian Developer http://www.debian.org

In a world without walls and fences, who needs Windows and Gates?

--IUSVF+LtaR4kWxuH
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="tetex-bin.CVE-2005-3191_2_3.diff"
Content-Transfer-Encoding: quoted-printable

 * SECURITY UPDATE: Multiple integer/buffer overflows in embedded xpdf code.
 * Add debian/patches/patch-CVE-2005-3191+2+3.patch:
 * xpdf/Stream.cc, DCTStream::readBaselineSOF(),
   DCTStream::readProgressiveSOF(), DCTStream::readScanInfo():
   - Check numComps for invalid values.
   - http://www.idefense.com/application/poi/display?id=3D342&type=3Dvulner=
abilities
   - CVE-2005-3191
 * xpdf/Stream.cc, StreamPredictor::StreamPredictor():
   - Check rowBytes for invalid values.
   - http://www.idefense.com/application/poi/display?id=3D344&type=3Dvulner=
abilities
   - CVE-2005-3192
  * xpdf/JPXStream.cc, JPXStream::readCodestream():
    - Check img.nXTiles * img.nYTiles * sizeof for integer overflow.
    - http://www.idefense.com/application/poi/display?id=3D345&type=3Dvulne=
rabilities
    - CVE-2005-3193

diff -u tetex-bin-3.0/debian/patches/series tetex-bin-3.0/debian/patches/se=
ries
--- tetex-bin-3.0/debian/patches/series
+++ tetex-bin-3.0/debian/patches/series
@@ -11,0 +12 @@
+patch-CVE-2005-3191+2+3
--- tetex-bin-3.0.orig/debian/patches/patch-CVE-200...

[Frank Küster (frank-debian)]

Hi Joey,

Martin Schulze <email address hidden> wrote:

> The original patch was not sufficient. I'm attaching the entire and the
> incremental patch. Please apply the incremental patch to the version in
> sid as well.

Did you see Martin Pitt's "enhanced" patch - do both address the same
problems?

TIA, Frank

P.S. Did you see my mail to -release regarding the tetex-base upload to
stable/proposed-updates?

--
Frank Küster
Inst. f. Biochemie der Univ. Zürich
Debian Developer

[Frank Küster (frank-debian)]

Martin Pitt <email address hidden> wrote:

> After discovering that the same flawed multiplication is also present
> in upstream's other two patches, I decided to completely rework the
> patch.
>
> I attach the debdiff with separated out changelog. Florian, maybe you
> can peer-review the patch?

Martin and Florian, Joey Schulze also sent a "fixed" patch to the bug,
see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=342292;msg=131

Would you be so kind and review it?

Regards, Frank
--
Frank Küster
Inst. f. Biochemie der Univ. Zürich
Debian Developer

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Fri, 09 Dec 2005 18:49:03 +0100
From: =?iso-8859-1?q?Frank_K=FCster?= <email address hidden>
To: Martin Schulze <email address hidden>
Cc: <email address hidden>, Debian Security Team <email address hidden>
Subject: Re: Bug#342292: tetex-bin: Multiple exploitable heap overflows in
 embedded xpdf copy

Hi Joey,

Martin Schulze <email address hidden> wrote:

> The original patch was not sufficient. I'm attaching the entire and the
> incremental patch. Please apply the incremental patch to the version in
> sid as well.

Did you see Martin Pitt's "enhanced" patch - do both address the same
problems?

TIA, Frank

P.S. Did you see my mail to -release regarding the tetex-base upload to
stable/proposed-updates?

--=20
Frank K=FCster
Inst. f. Biochemie der Univ. Z=FCrich
Debian Developer

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Fri, 09 Dec 2005 19:01:01 +0100
From: =?iso-8859-1?q?Frank_K=FCster?= <email address hidden>
To: Martin Pitt <email address hidden>
Cc: <email address hidden>, Martin Pitt <email address hidden>,
 Florian Weimer <email address hidden>
Subject: Re: Bug#342292: Fwd: Re: [vendor-sec] xpdf update - patch wrong?

Martin Pitt <email address hidden> wrote:

> After discovering that the same flawed multiplication is also present
> in upstream's other two patches, I decided to completely rework the
> patch.
>
> I attach the debdiff with separated out changelog. Florian, maybe you
> can peer-review the patch?

Martin and Florian, Joey Schulze also sent a "fixed" patch to the bug,
see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=3D342292;msg=3D131

Would you be so kind and review it?

Regards, Frank
--=20
Frank K=FCster
Inst. f. Biochemie der Univ. Z=FCrich
Debian Developer

[Martin Schulze (joey-infodrom)]

Frank Küster wrote:
> Hi Joey,
>
> Martin Schulze <email address hidden> wrote:
>
> > The original patch was not sufficient. I'm attaching the entire and the
> > incremental patch. Please apply the incremental patch to the version in
> > sid as well.
>
> Did you see Martin Pitt's "enhanced" patch - do both address the same
> problems?

The appendix removes the douplette Martin found, so yes.

> P.S. Did you see my mail to -release regarding the tetex-base upload to
> stable/proposed-updates?

No. Could you forward it?

Regards,

 Joey

--
Have you ever noticed that "General Public Licence" contains the word "Pub"?

Please always Cc to me when replying to me on the lists.

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Fri, 9 Dec 2005 21:45:08 +0100
From: Martin Schulze <email address hidden>
To: Frank =?iso-8859-1?Q?K=FCster?= <email address hidden>
Cc: <email address hidden>,
 Debian Security Team <email address hidden>
Subject: Re: Bug#342292: tetex-bin: Multiple exploitable heap overflows in embedded xpdf copy

Frank K=FCster wrote:
> Hi Joey,
>=20
> Martin Schulze <email address hidden> wrote:
>=20
> > The original patch was not sufficient. I'm attaching the entire and =
the
> > incremental patch. Please apply the incremental patch to the version=
 in
> > sid as well.
>=20
> Did you see Martin Pitt's "enhanced" patch - do both address the same
> problems?

The appendix removes the douplette Martin found, so yes.

> P.S. Did you see my mail to -release regarding the tetex-base upload to
> stable/proposed-updates?

No. Could you forward it?

Regards,

 Joey

--=20
Have you ever noticed that "General Public Licence" contains the word "Pu=
b"?

Please always Cc to me when replying to me on the lists.

[Frank Küster (frank-debian)]

Martin Schulze <email address hidden> wrote:

> Frank Küster wrote:
>> Hi Joey,
>>
>> Martin Schulze <email address hidden> wrote:
>>
>> > The original patch was not sufficient. I'm attaching the entire and the
>> > incremental patch. Please apply the incremental patch to the version in
>> > sid as well.
>>
>> Did you see Martin Pitt's "enhanced" patch - do both address the same
>> problems?
>
> The appendix removes the douplette Martin found, so yes.

I looked at both, and it seems that Martin's does more. I'm speaking of
the patch attached to http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=342292;msg=136

It introduces limits.h and does the same we did for the xpdf patches at
the beginning of the year, namely change code that can be optimized away
by compilers.

It seems to me that Martin Pitt's patch also has everything that yours
(Joey's) has, but I'm not completely sure; anyway it seems that also the
stable packages should use the code with limits.h.

Am I correct that the other issues that Florian found are not addressed
by any patch yet, and have not yet been widely published? Should I
delay an upload to sid until this can be fixed, too?

>> P.S. Did you see my mail to -release regarding the tetex-base upload to
>> stable/proposed-updates?
>
> No. Could you forward it?

Sent in a separate mail.

Regards, Frank
--
Frank Küster
Inst. f. Biochemie der Univ. Zürich
Debian Developer

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Sun, 11 Dec 2005 13:27:37 +0100
From: =?iso-8859-1?q?Frank_K=FCster?= <email address hidden>
To: Martin Schulze <email address hidden>
Cc: <email address hidden>, Debian Security Team <email address hidden>,
 Martin Pitt <email address hidden>, Florian Weimer <email address hidden>
Subject: Re: Bug#342292: tetex-bin: Multiple exploitable heap overflows in
 embedded xpdf copy

Martin Schulze <email address hidden> wrote:

> Frank K=FCster wrote:
>> Hi Joey,
>>=20
>> Martin Schulze <email address hidden> wrote:
>>=20
>> > The original patch was not sufficient. I'm attaching the entire and t=
he
>> > incremental patch. Please apply the incremental patch to the version =
in
>> > sid as well.
>>=20
>> Did you see Martin Pitt's "enhanced" patch - do both address the same
>> problems?
>
> The appendix removes the douplette Martin found, so yes.

I looked at both, and it seems that Martin's does more. I'm speaking of
the patch attached to http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=3D34=
2292;msg=3D136

It introduces limits.h and does the same we did for the xpdf patches at
the beginning of the year, namely change code that can be optimized away
by compilers.=20=20

It seems to me that Martin Pitt's patch also has everything that yours
(Joey's) has, but I'm not completely sure; anyway it seems that also the
stable packages should use the code with limits.h.

Am I correct that the other issues that Florian found are not addressed
by any patch yet, and have not yet been widely published? Should I
delay an upload to sid until this can be fixed, too?

>> P.S. Did you see my mail to -release regarding the tetex-base upload to
>> stable/proposed-updates?
>
> No. Could you forward it?

Sent in a separate mail.

Regards, Frank
--=20
Frank K=FCster
Inst. f. Biochemie der Univ. Z=FCrich
Debian Developer

[Martin Pitt (pitti)]

Hi Frank, hi Joey!

Frank Küster [2005-12-09 19:01 +0100]:
> Martin Pitt <email address hidden> wrote:
>
> > After discovering that the same flawed multiplication is also present
> > in upstream's other two patches, I decided to completely rework the
> > patch.
> >
> > I attach the debdiff with separated out changelog. Florian, maybe you
> > can peer-review the patch?
>
> Martin and Florian, Joey Schulze also sent a "fixed" patch to the bug,
> see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=342292;msg=131
>
> Would you be so kind and review it?

Sorry for the delay, lots of private stuff to do on the weekend.

+ nVals = width * nComps;
++ totalBits = nVals * nBits;
++ if (totalBits == 0 ||
++ (totalBits / nBits) / nComps != width ||
++ totalBits + 7 < 0) {
++ return;
++ }

Please do not use this part of Joey's patch. As already disdussed,
this way of checking a multiplication overflow is unreliable. Please
use the var1 >= INT_MAX/var2 approach, which is the 'standard way' and
avoids integer overflows.

Thanks,

Martin

P. S. Frank, I'm this ---><--- close to build tetex-bin against
poppler, I already have working debs. Just fighting with the build
system a bit. :)

--
Martin Pitt http://www.piware.de
Ubuntu Developer http://www.ubuntulinux.org
Debian Developer http://www.debian.org

[Martin Pitt (pitti)]

Hi!

Frank Küster [2005-12-11 13:27 +0100]:
> >> Did you see Martin Pitt's "enhanced" patch - do both address the same
> >> problems?
> >
> > The appendix removes the douplette Martin found, so yes.
>
> I looked at both, and it seems that Martin's does more. I'm speaking of
> the patch attached to http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=342292;msg=136
>
> It introduces limits.h and does the same we did for the xpdf patches at
> the beginning of the year, namely change code that can be optimized away
> by compilers.

... or cause an undefined integer overflow.

> It seems to me that Martin Pitt's patch also has everything that yours
> (Joey's) has

As far as I can see, yes.

> Am I correct that the other issues that Florian found are not addressed
> by any patch yet, and have not yet been widely published? Should I
> delay an upload to sid until this can be fixed, too?

Hm, I'm not aware of any additional issues. Florian raised and
explained why 'p = f1*f2; if (p/f1 != f2)' is flawed, so I updated the
patch to not use it any more. Are there any additional issues I
missed?

Thanks,

Martin

--
Martin Pitt http://www.piware.de
Ubuntu Developer http://www.ubuntulinux.org
Debian Developer http://www.debian.org

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Mon, 12 Dec 2005 07:35:08 +0100
From: Martin Pitt <email address hidden>
To: Frank =?iso-8859-1?Q?K=FCster?= <email address hidden>
Cc: <email address hidden>, Florian Weimer <email address hidden>,
 Martin Schulze <email address hidden>
Subject: Re: Bug#342292: Fwd: Re: [vendor-sec] xpdf update - patch wrong?

Hi Frank, hi Joey!

Frank K=FCster [2005-12-09 19:01 +0100]:
> Martin Pitt <email address hidden> wrote:
>=20
> > After discovering that the same flawed multiplication is also present
> > in upstream's other two patches, I decided to completely rework the
> > patch.
> >
> > I attach the debdiff with separated out changelog. Florian, maybe you
> > can peer-review the patch?
>=20
> Martin and Florian, Joey Schulze also sent a "fixed" patch to the bug,
> see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=3D342292;msg=3D131
>=20
> Would you be so kind and review it?

Sorry for the delay, lots of private stuff to do on the weekend.

+ nVals =3D width * nComps;
++ totalBits =3D nVals * nBits;
++ if (totalBits =3D=3D 0 ||
++ (totalBits / nBits) / nComps !=3D width ||
++ totalBits + 7 < 0) {
++ return;
++ }

Please do not use this part of Joey's patch. As already disdussed,
this way of checking a multiplication overflow is unreliable. Please
use the var1 >=3D INT_MAX/var2 approach, which is the 'standard way' and
avoids integer overflows.

Thanks,

Martin

P. S. Frank, I'm this ---><--- close to build tetex-bin against
poppler, I already have working debs. Just fighting with the build
system a bit. :)

--=20
Martin Pitt http://www.piware.de
Ubuntu Developer http://www.ubuntulinux.org
Debian Developer http://www.debian.org

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Mon, 12 Dec 2005 07:46:31 +0100
From: Martin Pitt <email address hidden>
To: Frank =?iso-8859-1?Q?K=FCster?= <email address hidden>
Cc: Martin Schulze <email address hidden>, <email address hidden>,
 Debian Security Team <email address hidden>, Florian Weimer <email address hidden>
Subject: Re: Bug#342292: tetex-bin: Multiple exploitable heap overflows in embedded xpdf copy

Hi!

Frank K=FCster [2005-12-11 13:27 +0100]:
> >> Did you see Martin Pitt's "enhanced" patch - do both address the sam=
e
> >> problems?
> >
> > The appendix removes the douplette Martin found, so yes.
>=20
> I looked at both, and it seems that Martin's does more. I'm speaking o=
f
> the patch attached to http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=3D=
342292;msg=3D136
>=20
> It introduces limits.h and does the same we did for the xpdf patches at
> the beginning of the year, namely change code that can be optimized awa=
y
> by compilers. =20

... or cause an undefined integer overflow.

> It seems to me that Martin Pitt's patch also has everything that yours
> (Joey's) has

As far as I can see, yes.

> Am I correct that the other issues that Florian found are not addressed
> by any patch yet, and have not yet been widely published? Should I
> delay an upload to sid until this can be fixed, too?

Hm, I'm not aware of any additional issues. Florian raised and
explained why 'p =3D f1*f2; if (p/f1 !=3D f2)' is flawed, so I updated th=
e
patch to not use it any more. Are there any additional issues I
missed?

Thanks,

Martin

--=20
Martin Pitt http://www.piware.de
Ubuntu Developer http://www.ubuntulinux.org
Debian Developer http://www.debian.org

[Martin Schulze (joey-infodrom)]

Hi Frank!

Frank Küster wrote:
> I looked at both, and it seems that Martin's does more. I'm speaking of
> the patch attached to http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=342292;msg=136
>
> It introduces limits.h and does the same we did for the xpdf patches at
> the beginning of the year, namely change code that can be optimized away
> by compilers.

*sigh* You are correct. I'll add the missing bits as well.

> It seems to me that Martin Pitt's patch also has everything that yours
> (Joey's) has, but I'm not completely sure; anyway it seems that also the
> stable packages should use the code with limits.h.

Aye.

> Am I correct that the other issues that Florian found are not addressed
> by any patch yet, and have not yet been widely published? Should I
> delay an upload to sid until this can be fixed, too?

Which issues? *phear*

Regards,

 Joey

--
If nothing changes, everything will remain the same. -- Barne's Law

Please always Cc to me when replying to me on the lists.

[Frank Küster (frank-kuesterei)]

Martin Pitt <email address hidden> wrote:

> Frank Küster [2005-12-11 13:27 +0100]:
>
>> Am I correct that the other issues that Florian found are not addressed
>> by any patch yet, and have not yet been widely published? Should I
>> delay an upload to sid until this can be fixed, too?
>
> Hm, I'm not aware of any additional issues. Florian raised and
> explained why 'p = f1*f2; if (p/f1 != f2)' is flawed, so I updated the
> patch to not use it any more. Are there any additional issues I
> missed?

He said that the function gmallocn is flawed; but you're right, this
does not affect tetex-bin (yet), only xpdf.

Regards, Frank
--
Frank Küster
Inst. f. Biochemie der Univ. Zürich
Debian Developer

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Mon, 12 Dec 2005 09:01:15 +0100
From: =?iso-8859-1?q?Frank_K=FCster?= <email address hidden>
To: Martin Pitt <email address hidden>
Cc: Martin Schulze <email address hidden>, <email address hidden>,
 Debian Security Team <email address hidden>, Florian Weimer <email address hidden>
Subject: Re: Bug#342292: tetex-bin: Multiple exploitable heap overflows in
 embedded xpdf copy

Martin Pitt <email address hidden> wrote:

> Frank K=FCster [2005-12-11 13:27 +0100]:
>
>> Am I correct that the other issues that Florian found are not addressed
>> by any patch yet, and have not yet been widely published? Should I
>> delay an upload to sid until this can be fixed, too?
>
> Hm, I'm not aware of any additional issues. Florian raised and
> explained why 'p =3D f1*f2; if (p/f1 !=3D f2)' is flawed, so I updated the
> patch to not use it any more. Are there any additional issues I
> missed?

He said that the function gmallocn is flawed; but you're right, this
does not affect tetex-bin (yet), only xpdf.

Regards, Frank
--=20
Frank K=FCster
Inst. f. Biochemie der Univ. Z=FCrich
Debian Developer

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Mon, 12 Dec 2005 08:52:39 +0100
From: Martin Schulze <email address hidden>
To: Frank =?iso-8859-1?Q?K=FCster?= <email address hidden>
Cc: <email address hidden>, Debian Security Team <email address hidden>,
 Martin Pitt <email address hidden>, Florian Weimer <email address hidden>
Subject: Re: Bug#342292: tetex-bin: Multiple exploitable heap overflows in embedded xpdf copy

Hi Frank!

Frank K=FCster wrote:
> I looked at both, and it seems that Martin's does more. I'm speaking o=
f
> the patch attached to http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=3D=
342292;msg=3D136
>=20
> It introduces limits.h and does the same we did for the xpdf patches at
> the beginning of the year, namely change code that can be optimized awa=
y
> by compilers. =20

*sigh* You are correct. I'll add the missing bits as well.

> It seems to me that Martin Pitt's patch also has everything that yours
> (Joey's) has, but I'm not completely sure; anyway it seems that also th=
e
> stable packages should use the code with limits.h.

Aye.

> Am I correct that the other issues that Florian found are not addressed
> by any patch yet, and have not yet been widely published? Should I
> delay an upload to sid until this can be fixed, too?

Which issues? *phear*

Regards,

 Joey

--=20
If nothing changes, everything will remain the same. -- Barne's Law

Please always Cc to me when replying to me on the lists.

[Martin Schulze (joey-infodrom)]

Martin Pitt wrote:
> > > After discovering that the same flawed multiplication is also present
> > > in upstream's other two patches, I decided to completely rework the
> > > patch.
> > >
> > > I attach the debdiff with separated out changelog. Florian, maybe you
> > > can peer-review the patch?
> >
> > Martin and Florian, Joey Schulze also sent a "fixed" patch to the bug,
> > see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=342292;msg=131
> >
> > Would you be so kind and review it?
>
> Sorry for the delay, lots of private stuff to do on the weekend.
>
> + nVals = width * nComps;
> ++ totalBits = nVals * nBits;
> ++ if (totalBits == 0 ||
> ++ (totalBits / nBits) / nComps != width ||
> ++ totalBits + 7 < 0) {
> ++ return;
> ++ }
>
> Please do not use this part of Joey's patch. As already disdussed,
> this way of checking a multiplication overflow is unreliable. Please
> use the var1 >= INT_MAX/var2 approach, which is the 'standard way' and
> avoids integer overflows.

Sorry, that slipped through from one of the load of different patches.

It's not that problematic, the line

> ++ (totalBits / nBits) / nComps != width ||

might be optimised by the compiler, but it's not a problem since the
proper check is above the code (at least in my local copy):

+ nComps >= INT_MAX/nBits ||
+ width >= INT_MAX/nComps/nBits) {

Regards,

 Joey

--
If nothing changes, everything will remain the same. -- Barne's Law

Please always Cc to me when replying to me on the lists.

[Martin Pitt (pitti)]

Fixed in USN-227-1, dapper uses poppler now.

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Mon, 12 Dec 2005 15:51:09 +0100
From: Martin Schulze <email address hidden>
To: Martin Pitt <email address hidden>
Cc: Frank =?iso-8859-1?Q?K=FCster?= <email address hidden>,
 <email address hidden>, Florian Weimer <email address hidden>
Subject: Re: Bug#342292: Fwd: Re: [vendor-sec] xpdf update - patch wrong?

Martin Pitt wrote:
> > > After discovering that the same flawed multiplication is also present
> > > in upstream's other two patches, I decided to completely rework the
> > > patch.
> > >
> > > I attach the debdiff with separated out changelog. Florian, maybe you
> > > can peer-review the patch?
> >
> > Martin and Florian, Joey Schulze also sent a "fixed" patch to the bug,
> > see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=342292;msg=131
> >
> > Would you be so kind and review it?
>
> Sorry for the delay, lots of private stuff to do on the weekend.
>
> + nVals = width * nComps;
> ++ totalBits = nVals * nBits;
> ++ if (totalBits == 0 ||
> ++ (totalBits / nBits) / nComps != width ||
> ++ totalBits + 7 < 0) {
> ++ return;
> ++ }
>
> Please do not use this part of Joey's patch. As already disdussed,
> this way of checking a multiplication overflow is unreliable. Please
> use the var1 >= INT_MAX/var2 approach, which is the 'standard way' and
> avoids integer overflows.

Sorry, that slipped through from one of the load of different patches.

It's not that problematic, the line

> ++ (totalBits / nBits) / nComps != width ||

might be optimised by the compiler, but it's not a problem since the
proper check is above the code (at least in my local copy):

+ nComps >= INT_MAX/nBits ||
+ width >= INT_MAX/nComps/nBits) {

Regards,

 Joey

--
If nothing changes, everything will remain the same. -- Barne's Law

Please always Cc to me when replying to me on the lists.

[Frank Küster (frank-debian)]

Martin Schulze <email address hidden> wrote:

>> Am I correct that the other issues that Florian found are not addressed
>> by any patch yet, and have not yet been widely published? Should I
>> delay an upload to sid until this can be fixed, too?
>
> Which issues? *phear*

Florian said that the new function gmallocn (used in xpdf >= 3.01 and
derivatives, but not in tetex-bin) isn't save, either.

I'm currently preparing an upload of tetex-bin linked against libpoppler.

Regards, Frank
--
Frank Küster
Inst. f. Biochemie der Univ. Zürich
Debian Developer

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Tue, 13 Dec 2005 18:17:03 +0100
From: =?iso-8859-1?q?Frank_K=FCster?= <email address hidden>
To: Martin Schulze <email address hidden>
Cc: <email address hidden>, Debian Security Team <email address hidden>,
 Martin Pitt <email address hidden>, Florian Weimer <email address hidden>
Subject: Re: Bug#342292: tetex-bin: Multiple exploitable heap overflows in
 embedded xpdf copy

Martin Schulze <email address hidden> wrote:

>> Am I correct that the other issues that Florian found are not addressed
>> by any patch yet, and have not yet been widely published? Should I
>> delay an upload to sid until this can be fixed, too?
>
> Which issues? *phear*

Florian said that the new function gmallocn (used in xpdf >=3D 3.01 and
derivatives, but not in tetex-bin) isn't save, either.

I'm currently preparing an upload of tetex-bin linked against libpoppler.

Regards, Frank
--=20
Frank K=FCster
Inst. f. Biochemie der Univ. Z=FCrich
Debian Developer

[Frank Küster (frank-debian)]

notfound 342292 3.0-12
thanks

<email address hidden> (Debian Bug Tracking System) wrote:

> * Because of the frequent security issues with xpdf, we do no longer use
> the included xpdf code, but libpoppler instead. Many thanks to Martin Pitt
> <email address hidden> for the patch (closes: #316546) [frank]

At least now this bug should no longer be shown as outstanding.

--
Frank Küster
Inst. f. Biochemie der Univ. Zürich
Debian Developer

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Tue, 13 Dec 2005 19:33:49 +0100
From: =?iso-8859-1?q?Frank_K=FCster?= <email address hidden>
To: Debian Bug Control Server <email address hidden>
Cc: teTeX maintainers <email address hidden>
Subject: Re: Bug#316546: marked as done (tetex-bin: Please use libpoppler
 instead of a copy of xpdf code)

notfound 342292 3.0-12
thanks

<email address hidden> (Debian Bug Tracking System) wrote:

> * Because of the frequent security issues with xpdf, we do no longer u=
se
> the included xpdf code, but libpoppler instead. Many thanks to Marti=
n Pitt
> <email address hidden> for the patch (closes: #316546) [frank]

At least now this bug should no longer be shown as outstanding.

--=20
Frank K=FCster
Inst. f. Biochemie der Univ. Z=FCrich
Debian Developer

[Martin Schulze (joey-infodrom)]

Frank Küster wrote:
> I'm currently preparing an upload of tetex-bin linked against libpoppler.

I'm attaching the current patch against the version in sarge. Please
let me know which version in sid fixes these problems.

The corresponding CVE names are:

CVE IDs : CAN-2005-3191 CAN-2005-3192 CVE-2005-3624 CVE-2005-3625
                 CVE-2005-3626 CVE-2005-3627 CVE-2005-3628

Regards,

 Joey

--
Never trust an operating system you don't have source for!

Please always Cc to me when replying to me on the lists.

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Wed, 11 Jan 2006 20:50:35 +0100
From: Martin Schulze <email address hidden>
To: Frank =?iso-8859-1?Q?K=FCster?= <email address hidden>
Cc: <email address hidden>, Debian Security Team <email address hidden>,
 Martin Pitt <email address hidden>, Florian Weimer <email address hidden>
Subject: Re: Bug#342292: tetex-bin: Multiple exploitable heap overflows in embedded xpdf copy

--yNb1oOkm5a9FJOVX
Content-Type: multipart/mixed; boundary="8t9RHnE3ZwKMSgU+"
Content-Disposition: inline

--8t9RHnE3ZwKMSgU+
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Frank K=FCster wrote:
> I'm currently preparing an upload of tetex-bin linked against libpoppler.

I'm attaching the current patch against the version in sarge. Please
let me know which version in sid fixes these problems.

The corresponding CVE names are:

CVE IDs : CAN-2005-3191 CAN-2005-3192 CVE-2005-3624 CVE-2005-3625
                 CVE-2005-3626 CVE-2005-3627 CVE-2005-3628

Regards,

 Joey

--=20
Never trust an operating system you don't have source for!

Please always Cc to me when replying to me on the lists.

--8t9RHnE3ZwKMSgU+
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: attachment; filename=x
Content-Transfer-Encoding: quoted-printable

diff -u tetex-bin-2.0.2/debian/changelog tetex-bin-2.0.2/debian/changelog
--- tetex-bin-2.0.2/debian/changelog
+++ tetex-bin-2.0.2/debian/changelog
@@ -1,3 +1,35 @@
+tetex-bin (2.0.2-30sarge4) stable-security; urgency=3Dhigh
+
+ * Non-maintainer upload by the Security Team
+ * Added more precautionary checks by Dirk M=FCller [xpdf/Stream.cc,
+ xpdf/JBIG2Stream.cc, debian/patches/patch-CVE-2005-3191]
+
+ -- Martin Schulze <email address hidden> Thu, 15 Dec 2005 17:02:52 +0100
+
+tetex-bin (2.0.2-30sarge3) stable-security; urgency=3Dhigh
+
+ * Non-maintainer upload by the Security Team
+ * Added more precautionary checks by Martin Pitt
+
+ -- Martin Schulze <email address hidden> Mon, 12 Dec 2005 08:32:05 +0100
+
+tetex-bin (2.0.2-30sarge2) stable-security; urgency=3Dhigh
+
+ * Non-maintainer upload by the Security Team
+ * Adjusted the former patch
+ * Applied missing bits found by Ludwig Nussel
+
+ -- Martin Schulze <email address hidden> Fri, 9 Dec 2005 11:25:16 +0100
+
+tetex-bin (2.0.2-30sarge1) stable-security; urgency=3Dhigh
+
+ * Non-maintainer upload by the Security Team
+ * Partially applied patch from xpdf upstream to fix buffer overflows
+ [libs/xpdf/xpdf/Stream.cc, libs/xpdf/xpdf/Stream.h, CAN-2005-3191,
+ debian/patches/patch-CVE-2005-3191]
+
+ -- Martin Schulze <email address hidden> Thu, 8 Dec 2005 10:19:45 +0100
+
 tetex-bin (2.0.2-30) unstable; urgency=3Dlow
=20
   * Restore debian/watch and don't keep the recovered control file in
diff -u tetex-bin-2.0.2/debian/rules tetex-bin-2.0.2/debian/rules
--- tetex-bin-2.0.2/debian/rules
+++ tetex-bin-2.0.2/debian/rules
@@ -57,6 +57,8 @@
  patch -p1 -Ni debian/patches/patch-CAN-2005-0064
  patch -p1 -NRi debian/patches/patch-mandash || true
  patch -p1 -Ni debian/patches/patch-mandash
+ patch -p1 -NRi debian/patches/patch-CVE-2005...

[Frank Küster (frank-kuesterei)]

Martin Schulze <email address hidden> wrote:

> Frank Küster wrote:
>> I'm currently preparing an upload of tetex-bin linked against libpoppler.
>
> I'm attaching the current patch against the version in sarge. Please
> let me know which version in sid fixes these problems.

None: Since the version in sid links against libpoppler, no changes need
to be made to it. We just need an up-to-date poppler - and according to
its changelog

poppler (0.4.3-2) unstable; urgency=high

  [ Martin Pitt ]
  * SECURITY UPDATE: Multiple integer/buffer overflows.
  * Add debian/patches/003-CVE-2005-3624_5_7.patch:
[...]
  * Add debian/patches/004-fix-CVE-2005-3192.patch:
[...]
poppler (0.4.3-1) unstable; urgency=high

  * New upstream release.
  * New maintainer (Closes: #344738)
  * CVE-2005-3191 and CAN-2005-2097 fixes merged upstream.

it seems everything is okay there.

Regards, Frank
--
Frank Küster
Inst. f. Biochemie der Univ. Zürich
Debian Developer

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Thu, 12 Jan 2006 10:43:05 +0100
From: =?iso-8859-1?q?Frank_K=FCster?= <email address hidden>
To: Martin Schulze <email address hidden>
Cc: <email address hidden>, Debian Security Team <email address hidden>,
 Martin Pitt <email address hidden>, Florian Weimer <email address hidden>
Subject: Re: Bug#342292: tetex-bin: Multiple exploitable heap overflows in
 embedded xpdf copy

Martin Schulze <email address hidden> wrote:

> Frank K=FCster wrote:
>> I'm currently preparing an upload of tetex-bin linked against libpoppler.
>
> I'm attaching the current patch against the version in sarge. Please
> let me know which version in sid fixes these problems.

None: Since the version in sid links against libpoppler, no changes need
to be made to it. We just need an up-to-date poppler - and according to
its changelog

poppler (0.4.3-2) unstable; urgency=3Dhigh

  [ Martin Pitt ]
  * SECURITY UPDATE: Multiple integer/buffer overflows.
  * Add debian/patches/003-CVE-2005-3624_5_7.patch:
[...]
  * Add debian/patches/004-fix-CVE-2005-3192.patch:
[...]
poppler (0.4.3-1) unstable; urgency=3Dhigh

  * New upstream release.
  * New maintainer (Closes: #344738)
  * CVE-2005-3191 and CAN-2005-2097 fixes merged upstream.

it seems everything is okay there.

Regards, Frank
--=20
Frank K=FCster
Inst. f. Biochemie der Univ. Z=FCrich
Debian Developer

[Martin Pitt (pitti)]

Hi Joey!

Martin Schulze [2006-01-11 20:50 +0100]:
> I'm attaching the current patch against the version in sarge. Please
> let me know which version in sid fixes these problems.

BTW, in order to keep a record of these duplicates, I recently created

  http://wiki.debian.org/EmbeddedCodeCopies

Martin
--
Martin Pitt http://www.piware.de
Ubuntu Developer http://www.ubuntu.com
Debian Developer http://www.debian.org

In a world without walls and fences, who needs Windows and Gates?

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Thu, 12 Jan 2006 11:57:46 +0100
From: Martin Pitt <email address hidden>
To: Martin Schulze <email address hidden>
Cc: Frank =?iso-8859-1?Q?K=FCster?= <email address hidden>, <email address hidden>,
 Debian Security Team <email address hidden>, Florian Weimer <email address hidden>
Subject: Re: Bug#342292: tetex-bin: Multiple exploitable heap overflows in embedded xpdf copy

--5mCyUwZo2JvN/JJP
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hi Joey!

Martin Schulze [2006-01-11 20:50 +0100]:
> I'm attaching the current patch against the version in sarge. Please
> let me know which version in sid fixes these problems.

BTW, in order to keep a record of these duplicates, I recently created

  http://wiki.debian.org/EmbeddedCodeCopies

Martin
--=20
Martin Pitt http://www.piware.de
Ubuntu Developer http://www.ubuntu.com
Debian Developer http://www.debian.org

In a world without walls and fences, who needs Windows and Gates?

--5mCyUwZo2JvN/JJP
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFDxjYqDecnbV4Fd/IRAgM2AJ98BbndEqf0Gbk6fB0Hra5M1KsI5ACgoJRe
csES6kRGhKGA6R2zLDRHJfw=
=Idd1
-----END PGP SIGNATURE-----

--5mCyUwZo2JvN/JJP--