Comment 31 for bug 26650

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

Message-ID: <email address hidden>
Date: Thu, 08 Dec 2005 22:55:39 +0100
From: =?iso-8859-1?q?Frank_K=FCster?= <email address hidden>
To: Florian Weimer <email address hidden>
Cc: <email address hidden>, Martin Pitt <email address hidden>, Martin Pitt <email address hidden>
Subject: Re: Bug#342292: Fwd: Re: [vendor-sec] xpdf update - patch wrong?

Florian Weimer <email address hidden> wrote:

> * Frank K=FCster:
>
>> Would=20
>>
>> if (nTiles >=3D INT_MAX / sizeof(JPXTile) {
>> error(getPos(), "Bad tile count in JPX SIZ marker segment");
>> return gFalse;
>>
>> be okay?
>
> It might still be a DoS issue, I think. Allocating arbitrary amounts
> of memory upon user request is usually a bad idea. But gmallocn does
> not touch the memory it allocates, so even very large allocations are
> very cheap initially.

The function that is called in *tetex-bin* is not gmallocn, but gmalloc
- it's based on xpdf 3.00, not 3.01, and this is the very reason why I
need to check for an overflow in nTiles * sizeof(JPXTile).

> As long as you initialize the allocated data
> structure as you read more input, it should be a minor issue (because
> you need an enormous file size to cause problems on even slightly
> dated machines).

I have no idea what the code does, and I'm only starting to learn C and
know next to nothing about C++. Somebody else should check.

> By the way, the gmallocn function suffers from undefined integer
> overflow, too:
>
> void *gmallocn(int nObjs, int objSize) {
> int n;
>
> n =3D nObjs * objSize;
> if (objSize =3D=3D 0 || n / objSize !=3D nObjs) {
> fprintf(stderr, "Bogus memory allocation size\n");
> exit(1);
> }
> return gmalloc(n);
> }

What's the problem here? That the value in "n" is undefined, and
therefore the comparison n / objSize !=3D nObjs is undefined, too?

This xpdf stuff seems to be a security nightmare by itself, even if not
copied to everybodies orig.tar.gz.

> The error handling is not suitable for library use, either. I don't
> know if this is a problem.

Only if the poppler people didn't notice...

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