Bug 458674 (CVE-2008-2327)

Summary: CVE-2008-2327 libtiff: use of uninitialized memory in LZW decoder
Product: [Other] Security Response Reporter: Tomas Hoger <thoger>
Component: vulnerabilityAssignee: Red Hat Product Security <security-response-team>
Status: CLOSED ERRATA QA Contact:
Severity: high Docs Contact:
Priority: high    
Version: unspecifiedCC: kreilly, mmalik, skakar, tgl, than
Target Milestone: ---Keywords: Security
Target Release: ---   
Hardware: All   
OS: Linux   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-01-09 09:40:26 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Bug Depends On: 458809, 458810, 458812, 458813, 458814, 458815, 809174    
Bug Blocks:    
Description Flags
Patch proposed by Drew Yao none

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.



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:


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, [1]), all files using any other compression methods are rejected (see notetiff() in faxinput.cpp).  LZW compression id is 5.

[1] http://www.awaresystems.be/imaging/tiff/tifftags/compression.html

Comment 15 Tomas Hoger 2008-08-26 12:41:17 UTC
Public now via:


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.

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.

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.