Sauli Pahlman of CERT-FI provided us with fuzzed TIFF file which crashes image viewers using libtiff library. TIFF image triggers an integer overflow in TIFFroundup() macro called from TIFFFillStrip(). Sufficient large bytecount from the file can cause TIFFroundup() to return 0 and cause TIFFReadBufferSetup() to allocate an insufficiently-sized buffer. Later in TIFFReadRawStrip1(), application-provided read callback is called via TIFFReadFile() that possibly overflows the buffer. This flaw occurs in libtiff 3.9.2, where bytecount in TIFFFillStrip() is defined as uint32. Older libtiff versions (e.g. those shipped with Red Hat Enterprise Linux 3, 4, and 5) use tsize_t (signed int32) as its type and reject bytecount values that may lead to integer overflow earlier. Issues was reported in launchpad (bug is currently restricted): https://bugs.launchpad.net/ubuntu/+source/tiff/+bug/589565
Created attachment 422062 [details] Possible fix This patch is inspired by libtiff 4.0 code. It does not do TIFFroundup() in TIFFFillStrip() (and TIFFFillTile()), as it's done in TIFFReadBufferSetup() anyway. Patch adds TIFFroundup() return value check to TIFFReadBufferSetup().
Created attachment 422514 [details] Upstream patch This fix got committed upstream.
Statement: Not vulnerable. These issues did not affect the versions of libtiff as shipped with Red Hat Enterprise Linux 3, 4, or 5.
Created attachment 422624 [details] Updated upstream patch Avoids malloc call completely in case of integer overflow in a similar way patch in comment #2 does.
Have we got an actual reproducer test case for this? None of the standard libtiff tools crash on this image on my x86_64 box. Perhaps the problem is 32-bit-only?
(In reply to comment #7) > Have we got an actual reproducer test case for this? None of the standard > libtiff tools crash on this image on my x86_64 box. Perhaps the problem is > 32-bit-only? Sorry, I failed to be more clear here. No, I was not able to reproduce with libtiff tools, but this should be reproducible with gtk-based image viewers (e.g. eog or gqview) on both 32 and 64 bits. libtiff tools seem to use mmaped files, so they follow different if-else branch in TIFFFillStrip.
(In reply to comment #5) > Created an attachment (id=422624) [details] > Updated upstream patch This patch is included in libtiff 3.9.3.
Opening bug, fix is included in tiff 3.9.3, original launchpad bug is public now too.
libtiff-3.9.4-1.fc12 has been submitted as an update for Fedora 12. http://admin.fedoraproject.org/updates/libtiff-3.9.4-1.fc12
libtiff-3.9.4-1.fc13 has been submitted as an update for Fedora 13. http://admin.fedoraproject.org/updates/libtiff-3.9.4-1.fc13
libtiff-3.9.4-1.fc13 has been pushed to the Fedora 13 stable repository. If problems still persist, please make note of it in this bug report.
libtiff-3.9.4-1.fc12 has been pushed to the Fedora 12 stable repository. If problems still persist, please make note of it in this bug report.