CVE-2013-4231

An attacker supplies a crafted GIF image or a TIFF image with a long filename. For the GIF LZW decoder issue, the malicious file provides a `datasize` value (e.g., 22) that causes the decoder to compute a `clear` code of 4194304 (`1 << 22`). The subsequent loop `for (code = 0; code < clear; code++)` writes beyond the bounds of the fixed-size `prefix[]` and `suffix[]` arrays, corrupting memory. Similarly, a crafted GIF extension block can supply a `count` larger than 255 that is passed directly to `fread(buf,1,count,infile)`, overflowing a 255-byte buffer. For the `rgb2ycbcr` overflow, a filename longer than 2048 characters triggers a buffer overflow via `sprintf` [CWE-119].

The vulnerabilities reside in the `tools/gif2tiff.c` and `tools/rgb2ycbcr.c` tools of libtiff before 4.0.3. In `gif2tiff.c`, the GIF LZW decoder lacks a check on the `datasize` value read from the input file, causing an out-of-bounds memory write during the buffer clearing loop. Another overflow in `gif2tiff.c` occurs when `fread(buf,1,count,infile)` reads attacker-controlled `count` bytes into a fixed 255-byte buffer. In `rgb2ycbcr.c`, a `sprintf` call writes a potentially oversized filename into a 2048-byte stack buffer.

The upstream CVS commit (revision 1.13, 2013-08-14) addressed the GIF LZW datasize issue by adding input validation that rejects corrupt or hostile `datasize` values before they reach the decoding loop. For the `rgb2ycbcr` filename overflow, the earlier fix for CVE-2013-1961 already replaced the vulnerable `sprintf` call with `snprintf`, limiting the copy to the buffer size. These changes prevent out-of-bounds memory writes from crafted input files [ref_id=2].