About the CVEs in libtiff 4.0.3

There has been a lot of afl fuzzing going on, a lot of image libraries were targeted, I also fuzzed some libraries, for example libtiff (back when it was still on remotesensing.org…). I sent around 10 to 20 crash files for the different tools to the maintainer that seemed to be kind of unique crash cases, although I didn’t analyze a lot of the crashes in-depth. Others found similar issues and CVEs like CVE-2014-8129, CVE-2014-8128, CVE-2014-8127 and CVE-2014-9330 were assigned, additionally I got CVE-2015-8870.

Here’s the example that I analyzed a little bit more closely (and that got the identifier CVE-2015-8870) in libtiff version 4.0.3 (until this month the last stable). It’s one of the errors in the bmp2tiff command line tool. Here’s what happens when you run it with one of my crash files (bmp2tiff crash-file.bmp outfile.tiff).

First, width and length variables are read from the bmp file header. Then the needed memory for the uncompressed image is calculated and allocated (line 595 in bmp2tiff.c):

uncompr_size = width * length;
...
uncomprbuf = (unsigned char *)_TIFFmalloc(uncompr_size);

However, there is no check for an integer overflow. So in my example afl made a file that results in the following values (gdb output):

(gdb) p width
$70 = 65536
(gdb) p length
$71 = 65544
(gdb) p uncompr_size
$72 = 524288

Where 524289 is (65536 * 65544) % MAX_INT. However, later on the width and length is used to calculate offsets on the uncomprbuf buffer, which results in pointers that are far off (heap buffer overflow).

Although I didn’t check the entire code, I think this is not easily exploitable, as it can only be used to read (more or less) arbitrary memory regions and write them to the output file. While this might be interesting in scenarios where you look for memory leaks, I doubt that it’s useful in any realistic attack scenario. Drop me a comment if I’m wrong. So the fix was to check if an integer overflow occurs on line 595 in bmp2tiff.c, which is done in the new version according to the maintainer.

Take a second and think about how many projects are probably using libtiff.

Looking into another crash file with an arbitrary WRITE and turning it into a fully weaponized exploit is still on my TODO list… we’ll see.

cheers,
floyd