[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5062A892.6070105@redhat.com>
Date: Wed, 26 Sep 2012 12:32:42 +0530
From: Huzaifa Sidhpurwala <huzaifas@...hat.com>
To: Sebastian Krahmer <krahmer@...e.de>
CC: oss-security@...ts.openwall.com, Tom Lane <tgl@...hat.com>
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.
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
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.
