[poppler] 13 commits - fofi/FoFiType1C.cc glib/poppler-action.cc glib/poppler-document.cc glib/poppler-page.cc makefile.vc poppler/ArthurOutputDev.cc poppler/CairoOutputDev.cc poppler/CharCodeToUnicode.cc poppler/Error.cc poppler/Gfx.cc poppler/G
Krzysztof Kowalczyk
kkowalczyk at gmail.com
Tue Sep 25 11:48:49 PDT 2007
Reverted. Sorry about that and thanks for noticing and explanation.
I have to say that I still don't get that code. Before making this
change I wrote a test program (see below) that ran the expression in
question (a * (int) b / b != a) on every integer and would say if for
any int a the result is any different than just testing for a < 0.
On my Ubuntu 7.04 with gcc 4.1.2, those are the exact equivalents.
I get your explanation but it seems that in those 3 specific cases
I've replaced, where a is an int and b is small unsigned value, those
tests are really equivalent to testing for a < 0, because an int
overflow of multiplying a postive value shows as negative number. Even
if you use a large b (like 16000), I couldn't find a single int a for
which the tests are not equivalent.
That being said, better be safe than sorry, so change reverted.
-- kjk
#include <stdio.h>
#include <limits.h>
#include <stdint.h>
#define MIN_INT 0x80000000
#define MAX_INT (MIN_INT - 1)
bool t(int a)
{
size_t b = sizeof(int);
if (a * (int)b / b != a)
{
if (! (a < 0) )
printf("t(%d) failed; a * (int)b / b = %d\n", a, (int)(a *
(int)b / b));
}
}
int main(int argc, char **argv)
{
for (int a=MIN_INT; a++; a < MAX_INT)
{
t(a);
}
}
On 9/25/07, Kristian Høgsberg <krh at bitplanet.net> wrote:
> On 9/24/07, Krzysztof Kowalczyk <kjk at kemper.freedesktop.org> wrote:
> 5a1f670a4d16affeed86cdf643ab22f481caa3a5)
> > Author: Krzysztof Kowalczyk <kkowalczyk at tlapx60ubu.(none)>
> > Date: Sun Sep 23 22:28:16 2007 -0700
> >
> > replace extremely confusing 'a*(int)sizeof(foo)/sizeof(foo) != a' which, due to type promotions, if a is int, is equivalent to a < 0; fix problems revealed by the change
>
> NO! Revert this commit right away. Those checks are integer overflow
> checks and prevent a class of security bugs. The problem is that when
> a pdf document specifies two (or more) numbers that poppler has to
> multiply to determine how much memory to use, integer overflows can
> happen. For example, suppose the document specifies the width and
> height of an image. Both width and height can be positive, innocent
> looking numbers, but when multiplied together, the results overflow
> 32bits. The result may be a small positive integer, say 17 bytes,
> which poppler then successfully allocates and then starts reading the
> (huge) image data into that 17 byte allocation. What you have is an
> exploitable security bug, and if you check the security history of
> xpdf and poppler, you'll see that we've fixed a great many of those
> over time.
>
> A nice patch would be to introduce a macro such as CHECK_OVERFLOW(a,b)
> that implements the above check, which makes the code more readable
> and isolates the implementation of this tricky check in place. But
> the checks have to stay.
>
> cheers,
> Kristian
>
More information about the poppler
mailing list