Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 26 Sep 2012 12:32:42 +0530
From: Huzaifa Sidhpurwala <>
To: Sebastian Krahmer <>
CC:, Tom Lane <>
Subject: Re: CVE Request: libtiff: Heap-buffer overflow when
 processing a TIFF image with PixarLog Compression

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.
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

Powered by blists - more mailing lists

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.