|Summary:||CVE-2008-2327 libtiff: use of uninitialized memory in LZW decoder|
|Product:||[Other] Security Response||Reporter:||Tomas Hoger <thoger>|
|Component:||vulnerability||Assignee:||Red Hat Product Security <security-response-team>|
|Status:||CLOSED ERRATA||QA Contact:|
|Version:||unspecified||CC:||kreilly, mmalik, skakar, tgl, than|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2009-01-09 09:40:26 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Cloudforms Team:||---||Target Upstream Version:|
|Bug Depends On:||458809, 458810, 458812, 458813, 458814, 458815, 809174|
Description Tomas Hoger 2008-08-11 14:24:08 UTC
Drew Yao of Apple Product Security reported a flaw in the LZW decoder used by libtiff to handle LZW-encoded images. Translation table used by decoding algorithm is not properly re-initialized after "code clear" code is read from the stream being decoded. When reading that code, decoder should discard previous translation table and start filling it again. Later during the processing, no longer valid table entries may be indexed by the input stream, causing libtiff to follow no longer valid pointer. This can result in crash, memory corruption and possibly allow code execution. References: http://www.remotesensing.org/libtiff/ http://en.wikipedia.org/wiki/Lzw Acknowledgements: Red Hat would like to thank Drew Yao of the Apple Product Security team for reporting this issue.
Comment 1 Tomas Hoger 2008-08-11 14:27:10 UTC
Created attachment 313969 [details] Patch proposed by Drew Yao Makes sure all invalid translation table entries are re-seeded with zeros whenever CODE_CLEAR is read, not only during the decoder initialization phase.
Comment 3 Tomas Hoger 2008-08-11 15:26:36 UTC
Another flaws in LZW decoder used by libtiff was reported by Clay Wood in the upstream bugzilla: http://bugzilla.maptools.org/show_bug.cgi?id=1929 This problem may occur when 2 subsequent CODE_CLEAR codes are read, as CODE_CLEAR translation table entry does not have any valid pointer to previous code.
Comment 14 Tomas Hoger 2008-08-18 14:42:01 UTC
The kdegraphics / kfax as shipped in Red Hat Enterprise Linux 2.1 and 3 contain embedded copy of libtiff library. It contains affected LZW decoder code, however, it is not used by kfax. kfax (in versions shipped in Red Hat Enterprise Linux 2.1 and 3) only uses libtiff when printing faxes. However, kfax will refuse to open any tiff file that does not use one of CCITT-based compressions (compression types 2, 3, or 4, ), all files using any other compression methods are rejected (see notetiff() in faxinput.cpp). LZW compression id is 5.  http://www.awaresystems.be/imaging/tiff/tifftags/compression.html
Comment 15 Tomas Hoger 2008-08-26 12:41:17 UTC
Public now via: http://secunia.com/advisories/31610/ http://security-tracker.debian.net/tracker/CVE-2008-2327 Lifting embargo.
Comment 18 Fedora Update System 2008-08-26 16:17:28 UTC
libtiff-3.8.2-11.fc9 has been submitted as an update for Fedora 9. http://admin.fedoraproject.org/updates/libtiff-3.8.2-11.fc9
Comment 19 Fedora Update System 2008-08-26 16:17:30 UTC
libtiff-3.8.2-11.fc8 has been submitted as an update for Fedora 8. http://admin.fedoraproject.org/updates/libtiff-3.8.2-11.fc8
Comment 20 Fedora Update System 2008-09-10 06:37:20 UTC
libtiff-3.8.2-11.fc9 has been pushed to the Fedora 9 stable repository. If problems still persist, please make note of it in this bug report.
Comment 21 Fedora Update System 2008-09-10 06:39:54 UTC
libtiff-3.8.2-11.fc8 has been pushed to the Fedora 8 stable repository. If problems still persist, please make note of it in this bug report.
Comment 22 Red Hat Product Security 2009-01-09 09:40:26 UTC
This issue was addressed in: Red Hat Enterprise Linux: http://rhn.redhat.com/errata/RHSA-2008-0847.html http://rhn.redhat.com/errata/RHSA-2008-0848.html http://rhn.redhat.com/errata/RHSA-2008-0863.html Fedora: https://admin.fedoraproject.org/updates/F9/FEDORA-2008-7370