[Secure-testing-team] Re: xpdf vulnerability?

Frank Küster frank at kuesterei.ch
Tue Mar 22 13:20:32 UTC 2005


Hamish Moffatt <hamish at debian.org> wrote:

> On Tue, Mar 22, 2005 at 11:57:01AM +0100, Frank Küster wrote:
>> Hamish Moffatt <hamish at 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





More information about the Secure-testing-team mailing list