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.