[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120926065719.GA1295@suse.de>
Date: Wed, 26 Sep 2012 08:57:19 +0200
From: Sebastian Krahmer <krahmer@...e.de>
To: oss-security@...ts.openwall.com
Cc: Huzaifa Sidhpurwala <huzaifas@...hat.com>
Subject: Re: CVE Request: libtiff: Heap-buffer overflow when
processing a TIFF image with PixarLog Compression
On Tue, Sep 25, 2012 at 10:56:02AM -0600, Kurt Seifried wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 09/25/2012 03:06 AM, Huzaifa Sidhpurwala wrote:
> > On 09/23/2012 08:29 AM, Solar Designer wrote:
> >
> >> "libtiff 4.0.3 brings "various memory buffer access fixes". Does
> >> it fix more than CVE-2012-3401?"
> >>
> >> to which I have no answer. The change log does in fact mention
> >> "Various memory buffer access fixes." as the very first change
> >> listed for libtiff. Perhaps someone should review code changes.
> >>
> >
> > I had a look at the libtiff-4.0.3 commit logs and found one issue
> > which seems to bring a possibility of heap-based buffer overflow
> > when using a tiff file with PixarLog compression format.
> >
> > More details at:
> > https://bugzilla.redhat.com/show_bug.cgi?id=860198
> >
> > Though memory overwrite outside the heap-buffer is only a few
> > bytes, one cannot really overwrite possible arbitrary code
> > execution.
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.
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.
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
--
~ perl self.pl
~ $_='print"\$_=\47$_\47;eval"';eval
~ krahmer@...e.de - SuSE Security 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.
