Secure testing team - Mar 2006 - Re: xpdf vulnerability?

Hamish Moffatt <hamish@debian.org> wrote:
> On Fri, Mar 18, 2005 at 09:38:14AM +0100, Hilmar Preusse wrote:
>> As thex extension to CAN-2004-0888 (CAN-2005-0206) came in after the
>> latest tetex-bin upload we can''t have the fix in sarge.
I''ll file a
>> bug against tetex-bin and I guess Frank will upload ASAP. I''ll
check
>> the woody version too.
>
> I''m a bit confused.
>
> We have the 2005-0206 fix in Xpdf 3.00-10 (last November).
>
> However it''s marked as being a followup to for 2004-0889, not
-0888.
> The Xpdf changelog mentions 0889, but not 0888. I''m no longer sure
which
> patch is which.
Me neither.  I find these CVE pages on mitre.org annyoing, giving no
real information, only meta-information which is again just vendor stuff
without code.
> It looks like we are missing part of 2005-0064. I am about to upload
> that change (upstream patch 3.00pl3).
>
> I was tempted to revert all the security patches and apply
upstream''s
> versions, but I''m not sure that all the changes are there.
Especially as
> I don''t know how 0888 and 0889 differ.
Note also that the security team advised not to use the upstream patches
which rely on specific compiler properties, namely the non-optimizing of
constructs like 

    if (size*sizeof(XRefEntry)/sizeof(XRefEntry) != size) {

which are intended to be triggered if size is too large
(size*sizeof(XRefEntry) would then be more than what fits in an int,
truncated to an int (or does it start again with negative numbers?), and
not give size if divided again by sizeof(XRefEntry).  The security team
instead suggested to use

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

which I think is safe also on 64bit platforms.  Since I don''t speak
C++,
however, I am not sure about that.  I would be grateful if you could
check my analysis at

http://lists.debian.org/debian-tetex-maint/2005/03/msg00237.html

- nobody else has responded so far.

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

Hamish Moffatt <hamish@debian.org> wrote:
> On Tue, Mar 22, 2005 at 11:57:01AM +0100, Frank K?ster wrote:
>> Hamish Moffatt <hamish@debian.org> wrote:
>> > I was tempted to revert all the security patches and apply
upstream''s
>> > versions, but I''m not sure that all the changes are
there. Especially as
>> > I don''t know how 0888 and 0889 differ.
>> 
>> Note also that the security team advised not to use the upstream
patches
>> which rely on specific compiler properties, namely the non-optimizing
of
>> constructs like 
>
> Good point. However I just checked the three upstream patches for Xpdf
> 3.0 and I can''t see these type of changes in there at all?!
I have no idea what the upstream patches 1 and 3 are about.  However, I
only cared about xpdf < 3.0 so far, since that is what is included in
tetex and pdftohtml. patch 2 seems to address CAN-2004-1125.
>>     if (size*sizeof(XRefEntry)/sizeof(XRefEntry) != size) {
> or
>>     if (size < 0 || size >= INT_MAX/sizeof(XRefEntry)) {
>
> INT_MAX is still 2^31 and XRefEntry is an enum, so I guess it''s
OK.
> (I checked my amd64 system, but I expect INT_MAX is actually defined by
> the C spec.)
Wikipedia says the C standard is ISO/IEC 9899, with a downloadable pdf
(but from a non-authorative site).  According to that, INT_MAX may be
larger on "larger" architectures:

,----
| The contents of the header <limits.h> are given below, in alphabetical
| order. The minimum magnitudes shown shall be replaced by
| implementation-defined magnitudes with the same sign.
`----

However, that doesn''t invalidate the check.  

The main point of CAN-2004-0206, as I understand it, is that the
upstream/original check will be performed in the limits of the widest
integer type involved, sizeof(XRefEntry) which is 64bit on 64bit
platforms, whereas gmalloc (which is fed the size parameter) has a
prototype of "int".

Therefore it shouldn''t matter at all what INT_MAX is, as long as
gmalloc
savely accepts INT_MAX, and doesn''t get more than that.

Am I right?

TIA, Frank
-- 
Frank K?ster
Inst. f. Biochemie der Univ. Z?rich
Debian Developer

On Tue, Mar 22, 2005 at 02:01:37PM +0100, Frank K?ster
wrote:
> 
> Thank you, I found it extremely difficult (as someone who follows their
> own upstream, but not security-related mailinglists) to find ressources
> of information.  Currently, the CVE IDs are often used to indicate which
> issue is talked about (like in the original mail from the
> secure-testing-team), but e.g. for CAN-2005-0206 there are no
> cross-references except the RedHat and Mandrake advisories, which
aren''t
> too helpful, either.
Why not? RedHat should probably have references to their Bugzilla database 
in their advisories...
> So I checked the bugtraq list at http://marc.theaimsgroup.com/, but
> again these are only security advisories by vendors, not actually
> information about patches, right?  And vendors often just link to the
> CVE... 
Actually, you looked at the Bugtraq mailing list and I was suggesting the 
Bugtraq database, actually Securityfocus'' vulnerability database
available
at http://www.securityfocus.com/bid/

For example, if you search by CVE the Xpdf vulnerability related to 
CAN-2005-0206 you will get to BID-11501: 
http://www.securityfocus.com/bid/11501

In the ''solution'' section you can see references to other
vendors, and can
go searching for information on their bug tracking systems or security 
advisories. Since you have a link to the version fixing it, you might do 
best if you go and check their sources too. SRPM packages, for example, are 
provided including both the original sources and the patches to those and 
you cand download those directly from RPM vendors (RedHat, SuSE, Mandrake, 
etc..) Gentoo sources include the patches to the sources in their CVS and 
usually reference the Bugzilla entries in their advisories (and the 
bugzilla entry usually includes the patch too).

Moreover, if you go to the ''credit'' section you will see links
to either
the advisories themselves or to the discussion in the Bugtraq mailing list 
related to the vulnerability. Some vulnerabilities are first disclosed in 
the mailing list and then fixed by software provides, some others are only 
first noticed (and added to the database) when a vendor produces and 
advisory.
> 
> The Xforce link you gave is a little more helpful to me; but the best I
> found (and remembered to have seen before...) was the iDefense page I
> found linked from Xforce:
> 
> http://www.idefense.com/application/poi/display?type=vulnerabilities
> 
> (Unfortunately, there''s nothing there about CAN-2005-0206). 
Probably because CVE entries were generated after the iDefense advisory.
> 
> As for NIST''s ICAT - what is freeyl downloadable there?  Again, I
only
> found references to vendor advisories, no patches.  
NIST''s ICAT can be found at http://icat.nist.gov. You can find CSV
dumps of
the database but you are right, it does not include patches, no 
vulnerability holds patches at most they hold a reference to who disclosed 
the issue (maybe providing a patch) and what vendors were affected.
> Specifically, on all those pages I couldn''t find anything about
the
> differences between CAN-2004-0888 and CAN-2004-0889.
GLSA-200410-20, which is referenced to bug 69662 in Gentoo''s BTS (
http://bugs.gentoo.org/show_bug.cgi?id=69662) includes both CVE references 
and provides two patches

Gentoo''s GLSA 200410-30 references additional bugs ( #68558, #68665, 
#68571, #69936, and  #69624) so maybe they are worth reviewing.

In any case, from the Gentoo''s BTS, it looks like this was disclosed
first
on Vendor-Sec (a private mailing list used by open source distributions) so 
you might want to send off a mail to the Security Team asking them to 
forward you the relevant mails.
> 
> If you keep me (or debian-tetex-maint) in the Cc, I''ll happily
write a
> patch for the Developer''s Reference about security ressources.
Done.

Regards

Javier
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url :
http://lists.alioth.debian.org/pipermail/secure-testing-team/attachments/20050323/bf6465a6/attachment.pgp

On Fri, Mar 18, 2005 at 09:38:14AM +0100, Hilmar Preusse
wrote:
> As thex extension to CAN-2004-0888 (CAN-2005-0206) came in after the
> latest tetex-bin upload we can''t have the fix in sarge.
I''ll file a
> bug against tetex-bin and I guess Frank will upload ASAP. I''ll
check
> the woody version too.
I''m a bit confused.

We have the 2005-0206 fix in Xpdf 3.00-10 (last November).

However it''s marked as being a followup to for 2004-0889, not -0888.
The Xpdf changelog mentions 0889, but not 0888. I''m no longer sure
which
patch is which.

It looks like we are missing part of 2005-0064. I am about to upload
that change (upstream patch 3.00pl3).

I was tempted to revert all the security patches and apply upstream''s
versions, but I''m not sure that all the changes are there. Especially
as
I don''t know how 0888 and 0889 differ.


Hamish
-- 
Hamish Moffatt VK3SB <hamish@debian.org> <hamish@cloud.net.au>

On 18.03.05 Micah Anderson (micah@debian.org) wrote:
> On Wed, 16 Mar 2005, Frank K?ster wrote:
Hi .*,
> > Can anybody point me to a place where I can find the patch for
> > the 64-bit-specific issue?  The CVE only lists the RedHat and
> > Mandrake security announcements, but I don''t know how to get
> > those source-rpm''s. I found
> > ftp://ftp.foolabs.com/pub/xpdf/xpdf-3.00pl3.patch - if that''s
the
> > right one, tetex-bin in sarge/unstable is vulnerable.  In woody
> > the code looks very different.
> 
> Unfortunately, it takes some deep digging sometimes. I''ve had to
> email the security announce mailing address to find specific
> patches before. Surprisingly, they responded...
> 
Great! Now  I found out that the patch was only two links away from
the RHSA :-(.
> 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 thex extension to CAN-2004-0888 (CAN-2005-0206) came in after the
latest tetex-bin upload we can''t have the fix in sarge. I''ll
file a
bug against tetex-bin and I guess Frank will upload ASAP. I''ll check
the woody version too.

H.
-- 
Deliver yesterday, code today, think tomorrow.

[restricting Cc to the lists]

Javier Fern?ndez-Sanguino Pe?a <jfs@computer.org> wrote:
> On Tue, Mar 22, 2005 at 11:57:01AM +0100, Frank K?ster wrote:
>> 
>> Me neither.  I find these CVE pages on mitre.org annyoing, giving no
>> real information, only meta-information which is again just vendor
stuff
>> without code.
>
> CVE is not a database, it''s a dictionary. If you are looking into
more
> information on vulnerabilities please use either Symantec''s
Bugtraq, ISS''s
> Xforce or NIST''s ICAT. The first two are cross-referenced with
CVE, the
> last one has CVE references and is freely downloadable.
Thank you, I found it extremely difficult (as someone who follows their
own upstream, but not security-related mailinglists) to find ressources
of information.  Currently, the CVE IDs are often used to indicate which
issue is talked about (like in the original mail from the
secure-testing-team), but e.g. for CAN-2005-0206 there are no
cross-references except the RedHat and Mandrake advisories, which
aren''t
too helpful, either.

So I checked the bugtraq list at http://marc.theaimsgroup.com/, but
again these are only security advisories by vendors, not actually
information about patches, right?  And vendors often just link to the
CVE... 

The Xforce link you gave is a little more helpful to me; but the best I
found (and remembered to have seen before...) was the iDefense page I
found linked from Xforce:

http://www.idefense.com/application/poi/display?type=vulnerabilities

(Unfortunately, there''s nothing there about CAN-2005-0206). 

As for NIST''s ICAT - what is freeyl downloadable there?  Again, I only
found references to vendor advisories, no patches.  

Specifically, on all those pages I couldn''t find anything about the
differences between CAN-2004-0888 and CAN-2004-0889.

If you keep me (or debian-tetex-maint) in the Cc, I''ll happily write a
patch for the Developer''s Reference about security ressources.

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

On 2005-03-22 08:20:32 -0500 Frank K?ster <frank@kuesterei.ch> wrote:
> However, that doesn''t invalidate the check.
> The main point of CAN-2004-0206, as I understand it, is that the
> upstream/original check will be performed in the limits of the widest
> integer type involved, sizeof(XRefEntry) which is 64bit on 64bit
> platforms, whereas gmalloc (which is fed the size parameter) has a
> prototype of "int".
Is it an int or a size_t (like what malloc uses)?  If it is an int,
then INT_MAX would work as expected.  If it''s size_t, then you should
use SIZE_MAX (defined in stdint.h).

-- 
Hubert Chan <hubert@uhoreg.ca> - http://www.uhoreg.ca/
PGP/GnuPG key: 1024D/124B61FA
Fingerprint: 96C5 012F 5F74 A5F7 1FF7  5291 AF29 C719 124B 61FA
Key available at wwwkeys.pgp.net.   Encrypted e-mail preferred.

Hi Javier,

I''m following up on this because I want to learn, and because
I''d like
to write something about it for developers reference.  Please don''t
take
me as "playing dumb", at most I''m playing devils advocate,
but mostly I
simply didn''t see the things when looking at the available information.
Maybe I am dumb, but then probably other Debian maintainers are, too...

Javier Fern?ndez-Sanguino Pe?a <jfs@computer.org> wrote:
> On Tue, Mar 22, 2005 at 02:01:37PM +0100, Frank K?ster wrote:
>> 
>> Thank you, I found it extremely difficult (as someone who follows their
>> own upstream, but not security-related mailinglists) to find ressources
>> of information.  Currently, the CVE IDs are often used to indicate
which
>> issue is talked about (like in the original mail from the
>> secure-testing-team), but e.g. for CAN-2005-0206 there are no
>> cross-references except the RedHat and Mandrake advisories, which
aren''t
>> too helpful, either.
>
> Why not? RedHat should probably have references to their Bugzilla database 
> in their advisories...
Oh, yes, they have some at the very bottom.  However the page about
CAN-2005-0206 only mentions bugs that fix the older CAN''s.  No, you
have
to look at the oldest bug, in there is the newest information.

However, my point is still that this is not the information I like.  In
this particular case it is sufficient, probably.  But in other cases the
patches need not be in the BTS.  Anyway, this is always information
about what vendors did, not what I as a Debian maintainer should do.
Aren''t there any closed lists that actually discuss vulnerabilities and
possible fixes before the embargo ends?  And couldn''t these lists be
opened afterwards?
> For example, if you search by CVE the Xpdf vulnerability related to 
> CAN-2005-0206 you will get to BID-11501: 
> http://www.securityfocus.com/bid/11501
>
> In the ''solution'' section you can see references to other
vendors, and can
> go searching for information on their bug tracking systems or security 
> advisories. Since you have a link to the version fixing it, you might do 
> best if you go and check their sources too. SRPM packages, for example, are
> provided including both the original sources and the patches to those and 
> you cand download those directly from RPM vendors (RedHat, SuSE, Mandrake, 
> etc..) 
There is no occurence of "srpm" on
http://www.securityfocus.com/bid/11501/solution/.  And the last time I
klicked on some srpm link (I think by RedHat), it required me to pay for
some support contract before I would be allowed to download the
sources.  I''m sure there are simple ftp servers, but one first has to
find them.  

I just checked ftp.suse.com.  There are patches and src.rpm e.g. fixing
CAN-2005-0064 in the i386 directory, but nothing in the ia64
directory. In the x86-64 directory, there''s an xpdf file at
http://ftp.suse.com/pub/suse/x86_64/update/9.0/rpm/src/xpdf-2.02pl1-148.src.rpm,
but it is dated 21-Jan-2005 02:18 and can hardly fix 2004-0206.  Anyway,
this is *very* tedious for a maintainer who simply wants to check
whether their package *is* affected at all.
> Gentoo sources include the patches to the sources in their CVS and 
> usually reference the Bugzilla entries in their advisories (and the 
> bugzilla entry usually includes the patch too).
Yes, the Gentoo bugzilla is quite informative.  Sigh, yet an other
possibility to fix this:  They changed libgoo so that g*alloc accept
t_int instead of int...  Can''t the upstream author once get things
straight?
> GLSA-200410-20, which is referenced to bug 69662 in Gentoo''s BTS (
> http://bugs.gentoo.org/show_bug.cgi?id=69662) includes both CVE references 
> and provides two patches
Things get even more strange: According to this, the problem that the
original patches were not 64bit-safe were already known on 2004-10-31.
And it does not make things clearer with respect to 0888 vs. 0889; the
two patches are just one against libgoo, the other against XRef (and not
patching Catalog.cc...).  

It seems to me every distribution, and every upstream using xpdf code
have used a different fix.  We should really ask Foolabs to provide a
libxpdf (Debian bug #252104), or else switch to libpoppler as much as
possible.
> In any case, from the Gentoo''s BTS, it looks like this was
disclosed first
> on Vendor-Sec (a private mailing list used by open source distributions) so
> you might want to send off a mail to the Security Team asking them to 
> forward you the relevant mails.
I thought they were Cc''ed with my first mails, but I always mix up
"debian-security@lists.debian.org" with
"team@security.debian.org".

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

Micah Anderson <micah@debian.org> 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 Developer

On Tue, Mar 22, 2005 at 11:57:01AM +0100, Frank K?ster
wrote:
> 
> Me neither.  I find these CVE pages on mitre.org annyoing, giving no
> real information, only meta-information which is again just vendor stuff
> without code.
CVE is not a database, it''s a dictionary. If you are looking into more 
information on vulnerabilities please use either Symantec''s Bugtraq,
ISS''s
Xforce or NIST''s ICAT. The first two are cross-referenced with CVE, the
last one has CVE references and is freely downloadable.

Regards

Javier
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url :
http://lists.alioth.debian.org/pipermail/secure-testing-team/attachments/20050322/bc648453/attachment.pgp

On Tue, Mar 22, 2005 at 11:57:01AM +0100, Frank K?ster
wrote:
> Hamish Moffatt <hamish@debian.org> wrote:
> > I was tempted to revert all the security patches and apply
upstream''s
> > versions, but I''m not sure that all the changes are there.
Especially as
> > I don''t know how 0888 and 0889 differ.
> 
> Note also that the security team advised not to use the upstream patches
> which rely on specific compiler properties, namely the non-optimizing of
> constructs like 
Good point. However I just checked the three upstream patches for Xpdf
3.0 and I can''t see these type of changes in there at all?!
>     if (size*sizeof(XRefEntry)/sizeof(XRefEntry) != size) {
or
>     if (size < 0 || size >= INT_MAX/sizeof(XRefEntry)) {
INT_MAX is still 2^31 and XRefEntry is an enum, so I guess it''s OK.
(I checked my amd64 system, but I expect INT_MAX is actually defined by
the C spec.)


Thanks,

Hamish
-- 
Hamish Moffatt VK3SB <hamish@debian.org> <hamish@cloud.net.au>

Hubert Chan <hubert@uhoreg.ca> wrote:
> On 2005-03-22 08:20:32 -0500 Frank K?ster <frank@kuesterei.ch> wrote:
>
>> However, that doesn''t invalidate the check.
>> The main point of CAN-2004-0206, as I understand it, is that the
>> upstream/original check will be performed in the limits of the widest
>> integer type involved, sizeof(XRefEntry) which is 64bit on 64bit
>> platforms, whereas gmalloc (which is fed the size parameter) has a
>> prototype of "int".
>
> Is it an int or a size_t (like what malloc uses)?  If it is an int,
> then INT_MAX would work as expected.  If it''s size_t, then you
should
> use SIZE_MAX (defined in stdint.h).
from sarge''s tetex:

,---- xpdf/goo/gmem.h of xpdf 2.01 
| /*
|  * Same as malloc, but prints error message and exits if malloc()
|  * returns NULL.
|  */
| extern void *gmalloc(int size);
| 
| /*
|  * Same as realloc, but prints error message and exits if realloc()
|  * returns NULL.  If <p> is NULL, calls malloc instead of realloc().
|  */
| extern void *grealloc(void *p, int size);
`----

same in xpdf-3.00 in experimental''s tetex.

Regards, Frank

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

On 2005-03-23 04:07:47 -0500 Frank K?ster <frank@debian.org> wrote:
> Hubert Chan <hubert@uhoreg.ca> wrote:
> 
>> Is it an int or a size_t (like what malloc uses)?  If it is an int,
>> then INT_MAX would work as expected.  If it''s size_t, then you
should
>> use SIZE_MAX (defined in stdint.h).
> 
> from sarge''s tetex:
> 
> ,---- xpdf/goo/gmem.h of xpdf 2.01 | /*
> | extern void *gmalloc(int size);
> | extern void *grealloc(void *p, int size);
> `----
OK, then assuming that gmalloc is sane when it calls malloc (I think a
size_t will always be at least as big as an int anyways, so it
shouldn''t
cause a problem), then checking against INT_MAX should be safe.

-- 
Hubert Chan <hubert@uhoreg.ca> - http://www.uhoreg.ca/
PGP/GnuPG key: 1024D/124B61FA
Fingerprint: 96C5 012F 5F74 A5F7 1FF7  5291 AF29 C719 124B 61FA
Key available at wwwkeys.pgp.net.   Encrypted e-mail preferred.

On Wed, 16 Mar 2005, Frank K?ster wrote:
> Frank K?ster <frank@debian.org> wrote:
> 
> > Micah Anderson <micah@debian.org> wrote:
> >
> >> 7. Is our xpdf vulnerable to CAN-2005-0206[13]?
> >
> > This also needs to be checked for pdftex (in tetex-bin) and pdftohtml,
> > and perhaps others that include xpdf code.
> 
> Can anybody point me to a place where I can find the patch for the
> 64-bit-specific issue?  The CVE only lists the RedHat and Mandrake
> security announcements, but I don''t know how to get those
source-rpm''s.
> I found ftp://ftp.foolabs.com/pub/xpdf/xpdf-3.00pl3.patch - if
that''s the
> right one, tetex-bin in sarge/unstable is vulnerable.  In woody the code
> looks very different.
Unfortunately, it takes some deep digging sometimes. I''ve had to email
the security announce mailing address to find specific patches before.
Surprisingly, they responded...

I searched Redhat''s Bugzilla, and found this:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=135393

Apparantly this patch:
https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=110599

plus the following missing hunk:

@@ -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;
+        }


Can you determine if tetex-bin, pdftohtml and xpdf have this in Sarge?

Micah