Red Hat Bugzilla – Full Text Bug Listing
|Summary:||CVE-2010-2065 libtiff: TIFFroundup() integer overflow in TIFFFillStrip()|
|Product:||[Other] Security Response||Reporter:||Tomas Hoger <thoger>|
|Component:||vulnerability||Assignee:||Red Hat Product Security <security-response-team>|
|Status:||CLOSED ERRATA||QA Contact:|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2010-07-07 05:23:04 EDT||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Bug Depends On:||606708|
Description Tomas Hoger 2010-06-07 11:31:09 EDT
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
Comment 2 Tomas Hoger 2010-06-08 02:50:34 EDT
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().
Comment 3 Tomas Hoger 2010-06-09 08:01:18 EDT
Created attachment 422514 [details] Upstream patch This fix got committed upstream.
Comment 4 Tomas Hoger 2010-06-09 08:02:41 EDT
Statement: Not vulnerable. These issues did not affect the versions of libtiff as shipped with Red Hat Enterprise Linux 3, 4, or 5.
Comment 5 Tomas Hoger 2010-06-09 13:05:09 EDT
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.
Comment 7 Tom Lane 2010-06-11 14:49:15 EDT
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?
Comment 9 Tomas Hoger 2010-06-13 04:53:51 EDT
(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.
Comment 10 Tomas Hoger 2010-06-14 03:35:19 EDT
(In reply to comment #5) > Created an attachment (id=422624) [details] > Updated upstream patch This patch is included in libtiff 3.9.3.
Comment 11 Tomas Hoger 2010-06-15 03:22:42 EDT
Opening bug, fix is included in tiff 3.9.3, original launchpad bug is public now too.
Comment 13 Fedora Update System 2010-06-23 10:09:28 EDT
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
Comment 14 Fedora Update System 2010-06-23 10:10:52 EDT
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
Comment 15 Fedora Update System 2010-07-01 14:42:42 EDT
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.
Comment 16 Fedora Update System 2010-07-05 18:00:20 EDT
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.