[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

[Kristian Høgsberg]

On 9/25/07, Krzysztof Kowalczyk <kkowalczyk at gmail.com> wrote:
> Right, those show the problem. However, in all the cases in XRef.cc,
> we know that b is very small, so effectively those tests are
> equivalent to checking for a < 0.

Maybe, I didn't check the surrounding code.  If there is a check that
each of the factors is below some small fixed number such that the
product of these numbers are below 2^31, the integer overflow can be
removed.  But keep in mind that there's a difference between "should
be small numbers" and "are always small numbers".  Exploits play on
the developer assuming that, say, number of color components is always
a small number.  Unless you explicitly enforce that assumption  with a
check in the code, there's nothing preventing a maliciously crafted
pdf from breaking poppler by specifying 2^30 color components.

cheers,
Kristian

> On 9/25/07, Kristian Høgsberg <krh at bitplanet.net> wrote:
> > On 9/25/07, Krzysztof Kowalczyk <kkowalczyk at gmail.com> wrote:
> > > Reverted. Sorry about that and thanks for noticing and explanation.
> >
> > Thanks, quick response :)
> >
> > > 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.
> >
> > Try this one:
> >
> > #include <stdio.h>
> >
> > int main(int argc, char *argv[])
> > {
> >         int a = (1 << 16) + 5, b = (1 << 16) + 17;
> >
> >         printf("a = %d, b = %d, a * b = %d, a * b / b = %d\n",
> >                a, b, a * b, a * b / b);
> >
> >         return 0;
> > }
> >
> > cheers,
> > Kristian
> >
>