Ubuntu
tetex-bin package

tetex-bin still vulnerable to CAN-2004-0888 (CAN-2005-0206)

Bug #14171 reported by Debian Bug Importer
4
Affects Status Importance Assigned to Milestone
tetex-bin (Debian)
Fix Released
Unknown
tetex-bin (Ubuntu)
Invalid
High
Martin Pitt

Bug Description

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

See original description

CVE References

Revision history for this message
Debian Bug Importer (debzilla) wrote :

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

Revision history for this message
Debian Bug Importer (debzilla) wrote :
Download full text (4.6 KiB)

Message-ID: <20050318091619.GD2460@preusse>
Date: Fri, 18 Mar 2005 10:16:19 +0100
From: Hilmar Preusse <email address hidden>
To: Debian Bug Tracking System <email address hidden>
Subject: tetex-bin still vulnerable to CAN-2004-0888 (CAN-2005-0206)

--69pVuxX8awAiJ7fD
Content-Type: multipart/mixed; boundary="i9LlY+UWpKt15+FH"
Content-Disposition: inline

--i9LlY+UWpKt15+FH
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Package: tetex-bin
Version: 2.0.2-26
Severity: critical
Tags: security

Hi all,

As recently discovered the patch, which fixed CAN-2004-0888, seems to
be broken on all 64bit platforms (tested only on ia64 though).[1]

Attched are two patches, which should fix that. They are simply
stolen from the RedHat BTS.[2]

H.

[1] e.g.: http://www.auscert.org.au/render.html?it=3D4887
[2] https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=3D135393
--=20
sigmentation fault

--i9LlY+UWpKt15+FH
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="CAN-2005-0206-1.diff"

@@ -186,6 +192,11 @@
       }
       if (start >= pagesSize) {
        pagesSize += 32;
+ if (pagesSize*(int)sizeof(Page *)/sizeof(Page *) != pagesSize ||
+ pagesSize*(int)sizeof(Ref)/sizeof(Ref) != pagesSize) {
+ error(-1, "Invalid 'pagesSize' parameter.");
+ goto err3;
+ }

--i9LlY+UWpKt15+FH
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="CAN-2005-0206.diff"
Content-Transfer-Encoding: quoted-printable

--- XRef.cc.orig 2004-09-17 23:54:38.000000000 -0700
+++ XRef.cc 2004-09-25 17:59:36.000000000 -0700
@@ -76,6 +76,12 @@
=20
   // trailer is ok - read the xref table
   } else {
+ if (size*(int)sizeof(XRefEntry)/sizeof(XRefEntry) !=3D size) {
+ error(-1, "Invalid 'size' inside xref table.");
+ ok =3D gFalse;
+ errCode =3D errDamaged;
+ return;
+ }
     entries =3D (XRefEntry *)gmalloc(size * sizeof(XRefEntry));
     for (i =3D 0; i < size; ++i) {
       entries[i].offset =3D 0xffffffff;
@@ -267,6 +273,10 @@
     // table size
     if (first + n > size) {
       newSize =3D size + 256;
+ if (newSize*(int)sizeof(XRefEntry)/sizeof(XRefEntry) !=3D newSize) {
+ error(-1, "Invalid 'newSize'");
+ goto err2;
+ }
       entries =3D (XRefEntry *)grealloc(entries, newSize * sizeof(XRefEntr=
y));
       for (i =3D size; i < newSize; ++i) {
  entries[i].offset =3D 0xffffffff;
@@ -410,6 +420,10 @@
      if (!strncmp(p, "obj", 3)) {
        if (num >=3D size) {
   newSize =3D (num + 1 + 255) & ~255;
+ if (newSize*(int)sizeof(XRefEntry)/sizeof(XRefEntry) !=3D newSize=
) {
+ error(-1, "Invalid 'obj' parameters.");
+ return gFalse;
+ }
   entries =3D (XRefEntry *)
               grealloc(entries, newSize * sizeof(XRefEntry));
   for (i =3D size; i < newSize; ++i) {
@@ -431,6 +445,11 @@
     } else if (!strncmp(p, "endstream", 9)) {
       if (streamEndsLen =3D=3D streamEndsSize) {
  streamEndsSize +=3D 64;
+ if (streamEndsSize*(int)sizeof(int)/sizeof(int) !=3D streamEndsSiz=
e) {
+ error(-1, "Invalid 'endstream' par...

Read more...

Revision history for this message
In , Frank Küster (frank-debian) wrote : Re: xpdf vulnerability?
Download full text (3.1 KiB)

Micah Anderson <email address hidden> wrote:

> Unfortunately, it takes some deep digging sometimes.

Thank you very much for that work.

> I searched Redhat's Bugzilla, and found this:
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=135393
[...]
> Can you determine if tetex-bin, pdftohtml and xpdf have this in Sarge?

As for tetex-bin, I *think* it is not vulnerable. But I really want
others to check this, since I don't know much about types in C++, or C++
anyway. Here comes my analysis:

1. The original patch for xpdf, as issued by xpdf upstream, and
   according to the above URL used by RH for tetex, does the following:

+ if (size*sizeof(XRefEntry)/sizeof(XRefEntry) != size) {
+ error(-1, "Invalid 'size' inside xref table.");
+ ok = gFalse;
+ errCode = errDamaged;
+ return;
+ }

   This is a kind of silly way to do it, and relies on the compiler not
   optimizing away the construct. Joey has indicated this to me, and
   suggested a different patch, which I used:

+ if (size < 0 || size >= INT_MAX/sizeof(XRefEntry)) {
+ error(-1, "Invalid 'size' inside xref table.");
+ ok = gFalse;
+ errCode = errDamaged;
+ return;
+ }

   The 64bit problem now happens on the left hand side of the original
   patch, quoting from the above URL:

,----
| won't succeed, because the left side of the condition is evaluated as
| 64bit integer by default. (all the arithmetic in the expression is
| done in the widest integer type, which is 64bit, because of
| sizeof(XRefEntry), even if "size" is 32bit so the explicit casting in
| the numerator of the fraction has to be added).
 `----

   Therefore, if size would overflow a 32bit integer, but not a 64bit
   integer, it will still not trigger the condition. Later on in the
   code,

,----
| In case of memory allocation:
|
| entries = (XRefEntry *)gmalloc(size * sizeof(XRefEntry));
|
| it's truncated to 32bits as prototype of gmalloc is:
|
| void *gmalloc(int);
|
| so the overflow check won't detect the overflow presented by bad5.pdf
| and leads to segfault,
 `----

   So the question is whether our changed patch is vulnerable to this:

+ if (size < 0 || size >= INT_MAX/sizeof(XRefEntry)) {

   The value of INT_MAX, as defined in /usr/include/limits.h, does not
   depend on the architecture (just compared the values on my i386
   against merulo (ia64)). Therefore this will *always* check whether
   size times sizeof(XRefEntry) fits into a (32bit) int, as needed for
   gmalloc, and all is well.

   Am I wrong? If not, then tetex-bin has no problem, also not in
   woody. And then also pdftohmtl is okay, because I used the same patch
   for pdftohml back then.

   xpdf seems safe, too. The code is different, of course, beeing 3.0
   and not 1.something, but at least there are safe checks in it:

,---- XRef.cc
| if (newSize >= INT_MAX/sizeof(XRefEntry)) {
| error(-1, "Invalid 'obj' parameters'");
| goto err1;
| }
|
| entries = (XRefEntry *)grealloc(entries, newSize * sizeof(XRefEntry));
| for (i = size; i < newSize; ++i) {
 `----

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

Read more...

Revision history for this message
Debian Bug Importer (debzilla) wrote :
Download full text (3.6 KiB)

Message-ID: <email address hidden>
Date: Fri, 18 Mar 2005 15:53:49 +0100
From: =?iso-8859-1?q?Frank_K=FCster?= <email address hidden>
To: Micah Anderson <email address hidden>
Cc: debian-tetex-maint <email address hidden>,
 <email address hidden>, <email address hidden>, <email address hidden>,
 <email address hidden>, <email address hidden>
Subject: Re: xpdf vulnerability?

Micah Anderson <email address hidden> wrote:

> Unfortunately, it takes some deep digging sometimes.=20

Thank you very much for that work.

> I searched Redhat's Bugzilla, and found this:
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=3D135393
[...]
> Can you determine if tetex-bin, pdftohtml and xpdf have this in Sarge?

As for tetex-bin, I *think* it is not vulnerable. But I really want
others to check this, since I don't know much about types in C++, or C++
anyway. Here comes my analysis:

1. The original patch for xpdf, as issued by xpdf upstream, and
   according to the above URL used by RH for tetex, does the following:

+ if (size*sizeof(XRefEntry)/sizeof(XRefEntry) !=3D size) {
+ error(-1, "Invalid 'size' inside xref table.");
+ ok =3D gFalse;
+ errCode =3D errDamaged;
+ return;
+ }

   This is a kind of silly way to do it, and relies on the compiler not
   optimizing away the construct. Joey has indicated this to me, and
   suggested a different patch, which I used:

+ if (size < 0 || size >=3D INT_MAX/sizeof(XRefEntry)) {
+ error(-1, "Invalid 'size' inside xref table.");
+ ok =3D gFalse;
+ errCode =3D errDamaged;
+ return;
+ }

   The 64bit problem now happens on the left hand side of the original
   patch, quoting from the above URL:

,----
| won't succeed, because the left side of the condition is evaluated as
| 64bit integer by default. (all the arithmetic in the expression is
| done in the widest integer type, which is 64bit, because of
| sizeof(XRefEntry), even if "size" is 32bit so the explicit casting in
| the numerator of the fraction has to be added).
 `----

   Therefore, if size would overflow a 32bit integer, but not a 64bit
   integer, it will still not trigger the condition. Later on in the
   code,=20

,----
| In case of memory allocation:
|=20
| entries =3D (XRefEntry *)gmalloc(size * sizeof(XRefEntry));
|=20
| it's truncated to 32bits as prototype of gmalloc is:
|=20
| void *gmalloc(int);
|=20
| so the overflow check won't detect the overflow presented by bad5.pdf
| and leads to segfault,
 `----

   So the question is whether our changed patch is vulnerable to this:

+ if (size < 0 || size >=3D INT_MAX/sizeof(XRefEntry)) {

   The value of INT_MAX, as defined in /usr/include/limits.h, does not
   depend on the architecture (just compared the values on my i386
   against merulo (ia64)). Therefore this will *always* check whether
   size times sizeof(XRefEntry) fits into a (32bit) int, as needed for
   gmalloc, and all is well.

   Am I wrong? If not, then tetex-bin has no problem, also not in
   woody. And then also pdftohmtl is okay, because I used the same patch
   for pdftohml back then.

   xpdf seems safe, too. The ...

Read more...

Revision history for this message
In , Joey Hess (joeyh) wrote : Re: Bug#300182: tetex-bin still vulnerable to CAN-2004-0888 (CAN-2005-0206)

Hilmar Preusse wrote:
> As recently discovered the patch, which fixed CAN-2004-0888, seems to
> be broken on all 64bit platforms (tested only on ia64 though).[1]

Note that CAN-2005-0206 has been assigned for this issue.

BTW, since you were able to track this one down, do you have any info
about the other packages (cupsys, xpdf, etc) that also has
CAN-2004-0888? Do they also need fixes, and do you have a patch for
them?

--
see shy jo

Revision history for this message
Debian Bug Importer (debzilla) wrote :

Message-ID: <email address hidden>
Date: Fri, 18 Mar 2005 17:14:22 -0500
From: Joey Hess <email address hidden>
To: Hilmar Preusse <email address hidden>, <email address hidden>
Subject: Re: Bug#300182: tetex-bin still vulnerable to CAN-2004-0888 (CAN-2005-0206)

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

Hilmar Preusse wrote:
> As recently discovered the patch, which fixed CAN-2004-0888, seems to
> be broken on all 64bit platforms (tested only on ia64 though).[1]

Note that CAN-2005-0206 has been assigned for this issue.

BTW, since you were able to track this one down, do you have any info
about the other packages (cupsys, xpdf, etc) that also has
CAN-2004-0888? Do they also need fixes, and do you have a patch for
them?

--=20
see shy jo

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

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

iD8DBQFCO1K+d8HHehbQuO8RAv8rAKCV6DDdlNIC0t7z1tTcnfW/w6epnQCg229q
BrTNMgyXteo7q1FKujGye1Q=
=cNYr
-----END PGP SIGNATURE-----

--VbJkn9YxBvnuCH5J--

Revision history for this message
In , Frank Küster (frank-debian) wrote :

Joey Hess <email address hidden> schrieb:

> Hilmar Preusse wrote:
>> As recently discovered the patch, which fixed CAN-2004-0888, seems to
>> be broken on all 64bit platforms (tested only on ia64 though).[1]
>
> Note that CAN-2005-0206 has been assigned for this issue.
>
> BTW, since you were able to track this one down, do you have any info
> about the other packages (cupsys, xpdf, etc) that also has
> CAN-2004-0888? Do they also need fixes, and do you have a patch for
> them?

Cupsys not. They don't use the code any more, instead they use system
calls to the programs in xpdf-utils.

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

Revision history for this message
In , Frank Küster (frank-debian) wrote :

Joey Hess <email address hidden> schrieb:

> Hilmar Preusse wrote:
>> As recently discovered the patch, which fixed CAN-2004-0888, seems to
>> be broken on all 64bit platforms (tested only on ia64 though).[1]
>
> Note that CAN-2005-0206 has been assigned for this issue.
>
> BTW, since you were able to track this one down, do you have any info
> about the other packages (cupsys, xpdf, etc) that also has
> CAN-2004-0888? Do they also need fixes, and do you have a patch for
> them?

Did you read my analysis I sent to the bug address? I think we are not
vulnerably, but I am not sure; I'd be glad if somebody else looked over
it and agreed with me...

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

Revision history for this message
Debian Bug Importer (debzilla) wrote :

Message-ID: <email address hidden>
Date: Sat, 19 Mar 2005 20:18:42 +0100
From: =?iso-8859-1?q?Frank_K=FCster?= <email address hidden>
To: Joey Hess <email address hidden>
Cc: <email address hidden>, Hilmar Preusse <email address hidden>
Subject: Re: Bug#300182: tetex-bin still vulnerable to CAN-2004-0888
 (CAN-2005-0206)

Joey Hess <email address hidden> schrieb:

> Hilmar Preusse wrote:
>> As recently discovered the patch, which fixed CAN-2004-0888, seems to
>> be broken on all 64bit platforms (tested only on ia64 though).[1]
>
> Note that CAN-2005-0206 has been assigned for this issue.
>
> BTW, since you were able to track this one down, do you have any info
> about the other packages (cupsys, xpdf, etc) that also has
> CAN-2004-0888? Do they also need fixes, and do you have a patch for
> them?

Cupsys not. They don't use the code any more, instead they use system
calls to the programs in xpdf-utils.

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

Revision history for this message
Debian Bug Importer (debzilla) wrote :

Message-ID: <email address hidden>
Date: Sat, 19 Mar 2005 20:46:17 +0100
From: =?iso-8859-1?q?Frank_K=FCster?= <email address hidden>
To: Joey Hess <email address hidden>
Cc: <email address hidden>, Hilmar Preusse <email address hidden>
Subject: Re: Bug#300182: tetex-bin still vulnerable to CAN-2004-0888
 (CAN-2005-0206)

Joey Hess <email address hidden> schrieb:

> Hilmar Preusse wrote:
>> As recently discovered the patch, which fixed CAN-2004-0888, seems to
>> be broken on all 64bit platforms (tested only on ia64 though).[1]
>
> Note that CAN-2005-0206 has been assigned for this issue.
>
> BTW, since you were able to track this one down, do you have any info
> about the other packages (cupsys, xpdf, etc) that also has
> CAN-2004-0888? Do they also need fixes, and do you have a patch for
> them?

Did you read my analysis I sent to the bug address? I think we are not
vulnerably, but I am not sure; I'd be glad if somebody else looked over
it and agreed with me...

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

Revision history for this message
In , Martin Pitt (pitti) wrote :

Hi!

Hilmar, where did you see patches like

+ if (pagesSize*(int)sizeof(Page *)/sizeof(Page *) != pagesSize ||
+ pagesSize*(int)sizeof(Ref)/sizeof(Ref) != pagesSize) {

in the current tetex-bin package? debian/patches/patch-CAN-2004-0888
already has correct patches. Also, "advanced static code analysis"
shows that the wrong approach is not used:

~/tex/tetex-bin-2.0.2 $ grep -r 'pagesSize.*sizeof' .
./libs/xpdf/xpdf/Catalog.cc: pages = (Page **)gmalloc(pagesSize * sizeof(Page *));
./libs/xpdf/xpdf/Catalog.cc: pageRefs = (Ref *)gmalloc(pagesSize * sizeof(Ref));
./libs/xpdf/xpdf/Catalog.cc: pages = (Page **)grealloc(pages, pagesSize * sizeof(Page *));
./libs/xpdf/xpdf/Catalog.cc: pageRefs = (Ref *)grealloc(pageRefs, pagesSize * sizeof(Ref));
./debian/patches/patch-CAN-2004-0888:+ if (pagesSize >= INT_MAX/sizeof(Page *) ||
./debian/patches/patch-CAN-2004-0888:+ pagesSize >= INT_MAX/sizeof(Ref)) {
./debian/patches/patch-CAN-2004-0888: pages = (Page **)gmalloc(pagesSize * sizeof(Page *));
./debian/patches/patch-CAN-2004-0888: pageRefs = (Ref *)gmalloc(pagesSize * sizeof(Ref));
./debian/patches/patch-CAN-2004-0888:+ if (pagesSize >= INT_MAX/sizeof(Page *) ||
./debian/patches/patch-CAN-2004-0888:+ pagesSize >= INT_MAX/sizeof(Ref)) {
./debian/patches/patch-CAN-2004-0888: pages = (Page **)grealloc(pages, pagesSize * sizeof(Page *));
./debian/patches/patch-CAN-2004-0888: pageRefs = (Ref *)grealloc(pageRefs, pagesSize * sizeof(Ref));

At the time the patch was fixed, the new CAN number was not yet
assigned, so it does not appear in the changelog. So it would be nice
to add the CAN to the changelog.

This was the relevant upload (I think):

tetex-bin (2.0.2-24) unstable; urgency=high

  * SECURITY UPDATE: more buffer overflows in xpdf library, thanks to
    Martin Pitt <email address hidden> for the tetex-bin-specific patch, which
    fixes more integer overflows discovered by Markus Meissner
    <email address hidden>, thanks to him for discovering this.
  * Added debian/patches/patch-CAN-2004-0888. This patch contains the
    first fix included in the last upload, as well as the additional fixes
    from this upload, which are:
  [...]

Please close this bug.

Martin

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

Revision history for this message
Martin Pitt (pitti) wrote :

This was already fixed ages ago, and does not affect any Ubuntu/Debian
distribution. Detailed analysis was sent to debbugs, will appear here soon.

Revision history for this message
Debian Bug Importer (debzilla) wrote :
Download full text (3.2 KiB)

Message-ID: <email address hidden>
Date: Mon, 21 Mar 2005 10:09:36 +0100
From: Martin Pitt <email address hidden>
To: <email address hidden>
Subject: Re: tetex-bin still vulnerable to CAN-2004-0888 (CAN-2005-0206)

--k1lZvvs/B4yU6o8G
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hi!

Hilmar, where did you see patches like

+ if (pagesSize*(int)sizeof(Page *)/sizeof(Page *) !=3D pagesSize ||
+ pagesSize*(int)sizeof(Ref)/sizeof(Ref) !=3D pagesSize) {

in the current tetex-bin package? debian/patches/patch-CAN-2004-0888
already has correct patches. Also, "advanced static code analysis"
shows that the wrong approach is not used:

~/tex/tetex-bin-2.0.2 $ grep -r 'pagesSize.*sizeof' .
=2E/libs/xpdf/xpdf/Catalog.cc: pages =3D (Page **)gmalloc(pagesSize * size=
of(Page *));
=2E/libs/xpdf/xpdf/Catalog.cc: pageRefs =3D (Ref *)gmalloc(pagesSize * siz=
eof(Ref));
=2E/libs/xpdf/xpdf/Catalog.cc: pages =3D (Page **)grealloc(pages, pagesS=
ize * sizeof(Page *));
=2E/libs/xpdf/xpdf/Catalog.cc: pageRefs =3D (Ref *)grealloc(pageRefs, pa=
gesSize * sizeof(Ref));
=2E/debian/patches/patch-CAN-2004-0888:+ if (pagesSize >=3D INT_MAX/sizeof=
(Page *) ||
=2E/debian/patches/patch-CAN-2004-0888:+ pagesSize >=3D INT_MAX/sizeof=
(Ref)) {
=2E/debian/patches/patch-CAN-2004-0888: pages =3D (Page **)gmalloc(pagesS=
ize * sizeof(Page *));
=2E/debian/patches/patch-CAN-2004-0888: pageRefs =3D (Ref *)gmalloc(pages=
Size * sizeof(Ref));
=2E/debian/patches/patch-CAN-2004-0888:+ if (pagesSize >=3D INT_MAX/=
sizeof(Page *) ||
=2E/debian/patches/patch-CAN-2004-0888:+ pagesSize >=3D INT_MAX/=
sizeof(Ref)) {
=2E/debian/patches/patch-CAN-2004-0888: pages =3D (Page **)grealloc(pages=
, pagesSize * sizeof(Page *));
=2E/debian/patches/patch-CAN-2004-0888: pageRefs =3D (Ref *)grealloc(page=
Refs, pagesSize * sizeof(Ref));

At the time the patch was fixed, the new CAN number was not yet
assigned, so it does not appear in the changelog. So it would be nice
to add the CAN to the changelog.

This was the relevant upload (I think):

tetex-bin (2.0.2-24) unstable; urgency=3Dhigh

  * SECURITY UPDATE: more buffer overflows in xpdf library, thanks to
    Martin Pitt <email address hidden> for the tetex-bin-specific patch, which
    fixes more integer overflows discovered by Markus Meissner
    <email address hidden>, thanks to him for discovering this.
  * Added debian/patches/patch-CAN-2004-0888. This patch contains the
    first fix included in the last upload, as well as the additional fixes
    from this upload, which are:
  [...]

Please close this bug.

Martin

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

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

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

iD8DBQFCPo9QDecnbV4Fd/IRAmp8AKCzqlbeY+sXs6DdrSO+YKZPShnPwgCdGPDg
ujfOgg0b+mZ7f8hsaTKIgMQ=
=8nIL
-----END PGP ...

Read more...

Revision history for this message
In , Hilmar Preusse (hille42) wrote :

On 18.03.05 Joey Hess (<email address hidden>) wrote:
> Hilmar Preusse wrote:

Hi,

> > As recently discovered the patch, which fixed CAN-2004-0888,
> > seems to be broken on all 64bit platforms (tested only on ia64
> > though).[1]
>
> Note that CAN-2005-0206 has been assigned for this issue.
>
> BTW, since you were able to track this one down, do you have any
> info about the other packages (cupsys, xpdf, etc) that also has
> CAN-2004-0888? Do they also need fixes, and do you have a patch for
> them?
>
Martin Pitt <martin <at> piware.de> told me, that tetex-bin is not
vulnerable as the file debian/patches/patch-CAN-2004-0888 continas
not the original patch form the xpdf developer, but already a fixed
version of the patch. So we should not be affected.

Sorry for the confusion!
  Hilmar
--
sigmentation fault

Revision history for this message
Debian Bug Importer (debzilla) wrote :

Message-ID: <20050322103959.GD2336@preusse>
Date: Tue, 22 Mar 2005 11:39:59 +0100
From: Hilmar Preusse <email address hidden>
To: Joey Hess <email address hidden>, <email address hidden>
Cc: Martin Pitt <email address hidden>
Subject: Re: Bug#300182: tetex-bin still vulnerable to CAN-2004-0888 (CAN-2005-0206)

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

On 18.03.05 Joey Hess (<email address hidden>) wrote:
> Hilmar Preusse wrote:

Hi,

> > As recently discovered the patch, which fixed CAN-2004-0888,
> > seems to be broken on all 64bit platforms (tested only on ia64
> > though).[1]
>=20
> Note that CAN-2005-0206 has been assigned for this issue.
>=20
> BTW, since you were able to track this one down, do you have any
> info about the other packages (cupsys, xpdf, etc) that also has
> CAN-2004-0888? Do they also need fixes, and do you have a patch for
> them?
>=20
Martin Pitt <martin <at> piware.de> told me, that tetex-bin is not
vulnerable as the file debian/patches/patch-CAN-2004-0888 continas
not the original patch form the xpdf developer, but already a fixed
version of the patch. So we should not be affected.

Sorry for the confusion!
  Hilmar
--=20
sigmentation fault

--XsQoSWH+UP9D9v3l
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (Cygwin)

iQB1AwUBQj/10zwKFtukZhFxAQJ2dgMAjj/XLSOBGmZQ1h8NFby9JpjBmgEWLi0T
1vHVLirSQXAZMrrJsZ0I2KxXUt1dasrIhP6F8LjXdRg5LOCgxL6l2pt2AH41zZFv
6FdLu2R/JJJ/MY4jYjge3iN3vbc6j5M0
=OTL+
-----END PGP SIGNATURE-----

--XsQoSWH+UP9D9v3l--

Revision history for this message
In , Frank Küster (frank-debian) wrote :

Hi Martin,

Hilmar Preusse <email address hidden> wrote:

> On 18.03.05 Joey Hess (<email address hidden>) wrote:
>> Hilmar Preusse wrote:
>
> Hi,
>
>> > As recently discovered the patch, which fixed CAN-2004-0888,
>> > seems to be broken on all 64bit platforms (tested only on ia64
>> > though).[1]
>>
>> Note that CAN-2005-0206 has been assigned for this issue.
>>
>> BTW, since you were able to track this one down, do you have any
>> info about the other packages (cupsys, xpdf, etc) that also has
>> CAN-2004-0888? Do they also need fixes, and do you have a patch for
>> them?
>>
> Martin Pitt <martin <at> piware.de> told me, that tetex-bin is not
> vulnerable as the file debian/patches/patch-CAN-2004-0888 continas
> not the original patch form the xpdf developer, but already a fixed
> version of the patch.

Martin, good to hear that. Did you also read the other messages in this
thread, namely Hamish's confusion about CAN-2004-0888 vs. CAN-2004-0889?
And, by the way, why didn't you answer to the bug, or the security
list(s)?

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

Revision history for this message
In , Frank Küster (frank-kuesterei) wrote : Re: xpdf vulnerability?

Please please keep the bugnumber in the Cc!

Bastian Blank wrote:

> On Fri, Mar 18, 2005 at 12:04:21PM -0500, Hubert Chan wrote:
> > (which, if you're using from C++ code, you'll
> > have to #define __STDC_LIMIT_MACROS before you include stdint.h).
>
> This name is reserved. It is undefined behaviour if you define it.

So what is the recommended way to do this correctly? And why is my
analysis wrong that INT_MAX is defined in limits.h?

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

Revision history for this message
In , Martin Pitt (pitti) wrote : Re: Bug#300182: tetex-bin still vulnerable to CAN-2004-0888 (CAN-2005-0206)

Hi!

Frank Küster [2005-03-22 12:49 +0100]:
> Martin, good to hear that. Did you also read the other messages in this
> thread, namely Hamish's confusion about CAN-2004-0888 vs. CAN-2004-0889?

He is certainly not the only one who is confused about these. All
patches that I ever saw fix both CANs, and the description of both
CANs are nearly identical. I really don't know which particular fix
belongs to which CAN.

> And, by the way, why didn't you answer to the bug, or the security
> list(s)?

Hmm, I replied to <email address hidden> and I can see my
reply at

  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=300182

Didn't you get this mail? If not, I shall probably reply to
<email address hidden> in addition, but I thought this would happen
automatically.

Martin

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

Revision history for this message
Debian Bug Importer (debzilla) wrote :

Message-ID: <email address hidden>
Date: Tue, 22 Mar 2005 12:49:06 +0100
From: =?iso-8859-1?q?Frank_K=FCster?= <email address hidden>
To: Martin Pitt <email address hidden>
Cc: <email address hidden>, Joey Hess <email address hidden>,
        Hilmar Preusse
 <email address hidden>
Subject: Re: Bug#300182: tetex-bin still vulnerable to CAN-2004-0888
 (CAN-2005-0206)

Hi Martin,

Hilmar Preusse <email address hidden> wrote:

> On 18.03.05 Joey Hess (<email address hidden>) wrote:
>> Hilmar Preusse wrote:
>
> Hi,
>
>> > As recently discovered the patch, which fixed CAN-2004-0888,
>> > seems to be broken on all 64bit platforms (tested only on ia64
>> > though).[1]
>>=20
>> Note that CAN-2005-0206 has been assigned for this issue.
>>=20
>> BTW, since you were able to track this one down, do you have any
>> info about the other packages (cupsys, xpdf, etc) that also has
>> CAN-2004-0888? Do they also need fixes, and do you have a patch for
>> them?
>>=20
> Martin Pitt <martin <at> piware.de> told me, that tetex-bin is not
> vulnerable as the file debian/patches/patch-CAN-2004-0888 continas
> not the original patch form the xpdf developer, but already a fixed
> version of the patch.

Martin, good to hear that. Did you also read the other messages in this
thread, namely Hamish's confusion about CAN-2004-0888 vs. CAN-2004-0889?
And, by the way, why didn't you answer to the bug, or the security
list(s)?=20

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

Revision history for this message
Debian Bug Importer (debzilla) wrote :

Message-ID: <email address hidden>
Date: Tue, 22 Mar 2005 12:52:20 +0100
From: <email address hidden> (=?iso-8859-1?q?Frank_K=FCster?=)
To: <email address hidden>
Cc: <email address hidden>
Subject: Re: xpdf vulnerability?

Please please keep the bugnumber in the Cc!

Bastian Blank wrote:

> On Fri, Mar 18, 2005 at 12:04:21PM -0500, Hubert Chan wrote:
> > (which, if you're using from C++ code, you'll
> > have to #define __STDC_LIMIT_MACROS before you include stdint.h).
>=20
> This name is reserved. It is undefined behaviour if you define it.

So what is the recommended way to do this correctly? And why is my
analysis wrong that INT_MAX is defined in limits.h?

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

Revision history for this message
Debian Bug Importer (debzilla) wrote :

Message-ID: <email address hidden>
Date: Tue, 22 Mar 2005 13:09:12 +0100
From: Martin Pitt <email address hidden>
To: Frank =?iso-8859-1?Q?K=FCster?= <email address hidden>
Cc: <email address hidden>, Joey Hess <email address hidden>,
 Hilmar Preusse <email address hidden>
Subject: Re: Bug#300182: tetex-bin still vulnerable to CAN-2004-0888 (CAN-2005-0206)

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

Hi!

Frank K=FCster [2005-03-22 12:49 +0100]:
> Martin, good to hear that. Did you also read the other messages in this
> thread, namely Hamish's confusion about CAN-2004-0888 vs. CAN-2004-0889?

He is certainly not the only one who is confused about these. All
patches that I ever saw fix both CANs, and the description of both
CANs are nearly identical. I really don't know which particular fix
belongs to which CAN.

> And, by the way, why didn't you answer to the bug, or the security
> list(s)?=20

Hmm, I replied to <email address hidden> and I can see my
reply at

  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=3D300182

Didn't you get this mail? If not, I shall probably reply to
<email address hidden> in addition, but I thought this would happen
automatically.

Martin

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

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

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

iD8DBQFCQAroDecnbV4Fd/IRAjLnAJwJmvXiLldXhutmdxPQUKfxlkY1/wCgnSPy
K9+8fZ91eQpw6vgGl/4TujA=
=TqgV
-----END PGP SIGNATURE-----

--HcAYCG3uE/tztfnV--

Revision history for this message
In , Frank Küster (frank-kuesterei) wrote : tetex-bin not vulnerable

After the discussion on -security, starting with

http://lists.debian.org/debian-security/2005/03/msg00057.html

it is clear that tetex-bin is not vulnerably in woody, sarge or sid.

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

Revision history for this message
Debian Bug Importer (debzilla) wrote :

Message-ID: <email address hidden>
Date: Tue, 29 Mar 2005 15:25:37 +0200
From: <email address hidden> (=?iso-8859-1?q?Frank_K=FCster?=)
To: <email address hidden>
Subject: tetex-bin not vulnerable

After the discussion on -security, starting with

http://lists.debian.org/debian-security/2005/03/msg00057.html

it is clear that tetex-bin is not vulnerably in woody, sarge or sid.

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

Bug Watch Updater (bug-watch-updater)
Changed in tetex-bin:
status: Unknown → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.