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. 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). 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. 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. 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. 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. 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. 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. The file has been symmetrically encrypted to avoid inadvertently disrupting MUAs, etc. Please use `gpg --output tiff-testcases.tar.gz --decrypt`, with password "google". These issues will be reported to the upstream authors once an embargo date has been finalised. Please credit "Tavis Ormandy, Google Security Team" in any advisories relating to these issues. Thanks, Tavis.