> * Frank Küster:
>
>> Would
>>
>> if (nTiles >= 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 = nObjs * objSize;
> if (objSize == 0 || n / objSize != 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 != 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
--
Frank Küster
Inst. f. Biochemie der Univ. Zürich
Debian Developer
Florian Weimer <email address hidden> wrote:
> * Frank Küster:
>
>> Would
>>
>> if (nTiles >= 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 = nObjs * objSize;
> if (objSize == 0 || n / objSize != 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 != 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
--
Frank Küster
Inst. f. Biochemie der Univ. Zürich
Debian Developer