Re: CVE Request: libtiff: Heap-buffer overflow when processing a TIFF image with PixarLog Compression

[Huzaifa Sidhpurwala <huzaifas () redhat com>]

On 09/26/2012 12:27 PM, Sebastian Krahmer wrote:
> This conclusion leaves me a bit puzzled. :) Even just "a few bytes" are
> often enough to trigger code exec. In particular if you get a big bounty for it.
Sure :)

> As well as the patch:
>
>
> -     sp->tbuf = (uint16 *) _TIFFmalloc(tbuf_size);
> +     sp->tbuf = (uint16 *) _TIFFmalloc(tbuf_size+sizeof(uint16)*sp->stride);
>
> If there were sizeof(uint16)*sp->stride bytes missing before, this is really
> more than just a few bytes. I checked that the mult cannot overflow,
> as sp->stride seems to be uint16. However, I think the add can actually wrap,
> (at least on ILP32) as tbuf_size can be 0xffffffff or so.
> I think the patch is broken and just shifts the hole.
It seems that sp->stride is at most td_samplesperpixel.

Re-thinking about the patch, it does seem a bit broken now.
Tom,
Any inputs on this?


> Plus, there are more occurences of _TIFFmalloc(tbuf_size) inside this file,
> one in PixarLogSetupEncode() and one in PixarLogSetupDecode() (but it might be
> that the Encode can never be triggered like so by attackers).
>
> Sebastian


-- 
Huzaifa Sidhpurwala / Red Hat Security Response Team