http://scary.beasts.org/security/CESA-2004-006.txt

CESA-2004-006 - rev 3

libtiff-3.8.1 image decoder parsing flaws
=========================================

Programs: libtiff, and users of libtiff such as GNOME and KDE
(konqueror and mail clients are of particular concern).
Severity: Compromise of account used to browse malicious TIFF file.
CAN identifier(s): CAN-2004-0803

This advisory lists code flaws discovered by inspection of the libtiff code.
Specifically, libtiff-3.8.1 was investigated. Unfortunately, due to the size
of libtiff, only a limited scan for flaws was possible. These flaws are
likely to typify others present.

Very brief libtiff summary: libtiff is an encoder / decoder for the TIFF image
format. The TIFF image format is an incredibly rich format featuring multiple
possible encodings and formats. The encodings include JPEG, LZW, ZIP, log-based
encodings and many more - from many different companies such as NeXT, SGI and
Pixar.

Flaw 1. Heap-based overflow during RLE decoding in tif_next.c

off = (bp[0] * 256) + bp[1];
n = (bp[2] * 256) + bp[3];
if (cc < 4+n)
goto bad;
_TIFFmemcpy(row+off, bp+4, n);

Here, off and n are arbitrary values from the TIFF. Bounds checking is
performed on the data source buffer, but not the data destination buffer.

Demo TIFF: http://scary.beasts.org/misc/bad_next.tiff
(note that memory is subtly corrupted but may not result in an immediate
crash)

Flaw 2. Heap-based overflow during RLE decoding in tif_thunder.c

case THUNDER_RUN: /* pixel run */
/*
* Replicate the last pixel n times,
* where n is the lower-order 6 bits.
*/
if (npixels & 1) {
op[0] |= lastpixel;
lastpixel = *op++; npixels++; n--;
} else
lastpixel |= lastpixel << 4;
npixels += n;
for (; n > 0; n -= 2)
*op++ = (tidataval_t) lastpixel;

Here, n is an arbitrary value from the TIFF, and is used to drive a copy count
into the output without bounds checking.

Demo TIFF: http://scary.beasts.org/misc/bad_thunder.tiff
(note that memory is subtly corrupted but may not result in an immediate
crash)

Flaw 3. Possible overflow in tif_luv.c

A TIFF file to confirm this has not been crafted - but it appears that there
may be heap-based overflows when doing RLE decoding:

for (shft = 2*8; (shft -= 8) >= 0; ) {
for (i = 0; i < npixels && cc > 0; )
if (*bp >= 128) { /* run */
rc = *bp++ + (2-128);
b = (int16)(*bp++ << shft);
cc -= 2;
while (rc--)
[*] tp[i++] |= b;
} else { /* non-run */
rc = *bp++; /* nul is noop */
while (--cc && rc--)
[*] tp[i++] |= (int16)*bp++ << shft;

Lines marked with a [*] exhibit a suspicious lack of checking on the size of
the output buffer. Note that tif_luv.c contains multiple versions of the RLE
decoder for different image depths, and all look similarly dangerous.

CESA-2004-006 - rev 3
Chris Evans
chris (at) scary.beasts (dot) org [email concealed]

[ reply ]