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 08:57:19 +0200
From: Sebastian Krahmer <>
Cc: Huzaifa Sidhpurwala <>
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:

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



~ perl
~ $_='print"\$_=\47$_\47;eval"';eval
~ - 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.