Bug 199111 (CVE-2006-3459, CVE-2006-3460, CVE-2006-3461, CVE-2006-3462, CVE-2006-3463, CVE-2006-3464, CVE-2006-3465)

Summary: CVE-2006-3459 Multiple libtiff flaws (CVE-2006-3460 CVE-2006-3461 CVE-2006-3462 CVE-2006-3463 CVE-2006-3464 CVE-2006-3465)
Product: [Other] Security Response Reporter: Mark J. Cox <mjc>
Component: vulnerabilityAssignee: Matthias Clasen <mclasen>
Status: CLOSED ERRATA QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: unspecifiedCC: mmalik, security-response-team, than
Target Milestone: ---Keywords: Security
Target Release: ---   
Hardware: All   
OS: Linux   
Fixed In Version: RHSA-2006-0603 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2006-08-02 10:05:52 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Description Flags
Proposed patch none

Description Mark J. Cox 2006-07-17 10:18:29 UTC
From: Tavis Ormandy <taviso>
(with edits from Mark Cox)

Hi there, Google have sponsored me to perform a security audit of
libtiff-3.8.2, in which a number  of critical security flaws have been
uncovered. These flaws could be leveraged by an attacker to compromise
or disrupt any services that support the processing of tiff images.

Several buffer overflows have been discovered, including a stack
buffer overflow via TIFFFetchShortPair() in tif_dirread.c, which is
used to read two unsigned shorts from the input file. While a bounds
check is performed via CheckDirCount(), no action is taken on the
result allowing a pathological tdir_count to read an arbitrary number
of unsigned shorts onto a stack buffer. Exploitation of this error is
trivial, a tiff file with a pathological 'DotRange' (0x0150),
'YCbCrSubsampling' (0x0212), 'HalftoneHints' (0x0141) or 'PageNumber'
(0x0129) tag can be used to execute arbitrary code with the privileges
of the application using libtiff. (CVE-2006-3459)

A heap overflow vulnerability was discovered in the jpeg decoder,
where TIFFScanLineSize() is documented to return the size in bytes
that a subsequent call to TIFFReadScanline() would write, however the
encoded jpeg stream may disagree with these results and overrun the
buffer with more data than expected (tiff_jpeg.c ~725). A sanity check
is performed and prints a warning, however execution is permitted to
continue (presumbaly to permit truncated datastreams).  (CVE-2006-3460)

Another heap overflow exists in the PixarLog decoder where a run
length encoded data stream may specify a stride that is not an exact
multiple of the number of samples. The result is that on the final
decode operation the destination buffer is overrun, potentially
allowing an attacker to execute arbitrary code. (CVE-2006-3461)

The NeXT RLE decoder was also vulnerable to a heap overflow
vulnerability, where no bounds checking was performed on the result of
certain RLE decoding operations. This was solved by ensuring the
number of pixels written did not exceed the size of the scanline
buffer already prepared. (CVE-2006-3462)

An infinite loop was discovered in EstimateStripByteCounts(), where a
16bit unsigned short was used to iterate over a 32bit unsigned value,
should the unsigned int (td_nstrips) have exceeded USHORT_MAX, the
loop would never terminate and continue forever. This could have been
leveraged as a particularly effective DoS attack. The flaw was
corrected by widening the loop iterator to 32 bits.  (CVE-2006-3463)

Multiple unchecked arithmetic operations were uncovered, including a
number of the range checking operations deisgned to ensure the offsets
specified in tiff directories are legitimate. These  can be caused to
wrap for extreme values, bypassing sanity checks. (CVE-2006-3464)

Additionally, a number of codepaths were uncovered where assertions did not hold
true, resulting in the client application calling abort().

A flaw was also uncovered in libtiffs custom tag support, as
documented here http://www.libtiff.org/v3.6.0.html. While well formed
tiff files must have correctly ordered directories, libtiff attempts
to support broken images that do not. However in certain
circumstances, creating anonymous fields prior to merging field
information from codec information can result in recognised fields
with unexpected values. This state results in abnormal behaviour,
crashes, or potentially arbitrary code execution. It is likely the
tiff maintainers may implement a different fix to my solution, I have
decided to disregard all unknown directories encoutered prior to
finding a 'Compression' tag.  (CVE-2006-3465)

Testcases have been created to demonstrate some of these bugs, the
file tiff-testcases.tgz.gpg attached to this mail includes an INDEX
file that describes the bug.


Comment 1 Mark J. Cox 2006-07-17 10:18:30 UTC
Created attachment 132539 [details]
Proposed patch

Comment 3 Mark J. Cox 2006-07-17 10:20:37 UTC
Also affects RHEL2.1 and RHEL3 (maybe some subset of the issues, not investigated)

Comment 4 Mark J. Cox 2006-07-17 10:22:54 UTC
Than, it's possible these also affect kfax, can you investigate?  Thanks

Comment 5 Than Ngo 2006-07-17 11:56:29 UTC
it's not affected in RHEL3/RHEL4 because kdegraphics uses system libtiff,
but it could be affected in RHEL2.1.

Comment 6 Matthias Clasen 2006-07-24 18:44:31 UTC
I have built 
3.5.7-30.el2.3 for RHEL2.1
3.5.7-25.el3.3 for RHEL3
3.6.1-12 for RHEL4

and there is a RHTS testcase using the reference images

Comment 7 Matthias Clasen 2006-07-25 13:24:57 UTC
Tests succeed locally, and the RHEL3 tests passed in RHTS. 
There are some issues getting the RHEL2.1 and RHEL4 tests to run 
in RHTS, that could be RHTS, though.

Comment 10 Red Hat Bugzilla 2006-08-02 10:05:52 UTC
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.