You need to log in before you can comment on or make changes to this bug.
Created an attachment (id=862) [details] crash files There are two heap-based buffer overflow bugs in tiffcp.c of LibTIFF 4.0.9. An attacker could use this flaw to crash or even execute arbitrary code with the permission of the user running such an application compiled against libtiff. To reproduce with the attachment files: tiffcp -i poc1 result.tif ==5231==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x7f52cf6ff000 at pc 0x0000004068b1 bp 0x7ffe97c26f70 sp 0x7ffe97c26f60 WRITE of size 1 at 0x7f52cf6ff000 thread T0 #0 0x4068b0 in cpSeparateBufToContigBuf /home/s2e/1/tiff-4.0.9/tools/tiffcp.c:1228 #1 0x4075fb in readSeparateTilesIntoBuffer /home/s2e/1/tiff-4.0.9/tools/tiffcp.c:1458 #2 0x4069b5 in cpImage /home/s2e/1/tiff-4.0.9/tools/tiffcp.c:1253 #3 0x408986 in cpSeparateTiles2SeparateTiles /home/s2e/1/tiff-4.0.9/tools/tiffcp.c:1747 #4 0x404e62 in tiffcp /home/s2e/1/tiff-4.0.9/tools/tiffcp.c:814 #5 0x402dc2 in main /home/s2e/1/tiff-4.0.9/tools/tiffcp.c:303 #6 0x7f52d293982f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2082f) #7 0x401b78 in _start (/home/s2e/1/tiff-4.0.9/tmp/bin/tiffcp+0x401b78) 0x7f52cf6ff000 is located 0 bytes to the right of 8390656-byte region [0x7f52ceefe800,0x7f52cf6ff000) allocated by thread T0 here: #0 0x7f52d30b3602 in malloc (/usr/lib/x86_64-linux-gnu/libasan.so.2+0x98602) #1 0x7f52d2dcacfa in _TIFFmalloc /home/s2e/1/tiff-4.0.9/libtiff/tif_unix.c:316 #2 0x406991 in cpImage /home/s2e/1/tiff-4.0.9/tools/tiffcp.c:1251 #3 0x408986 in cpSeparateTiles2SeparateTiles /home/s2e/1/tiff-4.0.9/tools/tiffcp.c:1747 #4 0x404e62 in tiffcp /home/s2e/1/tiff-4.0.9/tools/tiffcp.c:814 #5 0x402dc2 in main /home/s2e/1/tiff-4.0.9/tools/tiffcp.c:303 #6 0x7f52d293982f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2082f) SUMMARY: AddressSanitizer: heap-buffer-overflow /home/s2e/1/tiff-4.0.9/tools/tiffcp.c:1228 cpSeparateBufToContigBuf tiffcp -i poc2 result.tif ==32163==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x62f00000c404 at pc 0x000000406654 bp 0x7fff7c31bdd0 sp 0x7fff7c31bdc0 READ of size 1 at 0x62f00000c404 thread T0 #0 0x406653 in cpStripToTile /home/s2e/1/tiff-4.0.9/tools/tiffcp.c:1190 #1 0x406fe8 in readContigTilesIntoBuffer /home/s2e/1/tiff-4.0.9/tools/tiffcp.c:1373 #2 0x4069b5 in cpImage /home/s2e/1/tiff-4.0.9/tools/tiffcp.c:1253 #3 0x408890 in cpContigTiles2ContigTiles /home/s2e/1/tiff-4.0.9/tools/tiffcp.c:1714 #4 0x404e62 in tiffcp /home/s2e/1/tiff-4.0.9/tools/tiffcp.c:814 #5 0x402dc2 in main /home/s2e/1/tiff-4.0.9/tools/tiffcp.c:303 #6 0x7fcc39be282f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2082f) #7 0x401b78 in _start (/home/s2e/1/tiff-4.0.9/tmp/bin/tiffcp+0x401b78) 0x62f00000c404 is located 0 bytes to the right of 49156-byte region [0x62f000000400,0x62f00000c404) allocated by thread T0 here: #0 0x7fcc3a35c602 in malloc (/usr/lib/x86_64-linux-gnu/libasan.so.2+0x98602) #1 0x7fcc3a073cfa in _TIFFmalloc /home/s2e/1/tiff-4.0.9/libtiff/tif_unix.c:316 #2 0x406e27 in readContigTilesIntoBuffer /home/s2e/1/tiff-4.0.9/tools/tiffcp.c:1348 #3 0x4069b5 in cpImage /home/s2e/1/tiff-4.0.9/tools/tiffcp.c:1253 #4 0x408890 in cpContigTiles2ContigTiles /home/s2e/1/tiff-4.0.9/tools/tiffcp.c:1714 #5 0x404e62 in tiffcp /home/s2e/1/tiff-4.0.9/tools/tiffcp.c:814 #6 0x402dc2 in main /home/s2e/1/tiff-4.0.9/tools/tiffcp.c:303 #7 0x7fcc39be282f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2082f) SUMMARY: AddressSanitizer: heap-buffer-overflow /home/s2e/1/tiff-4.0.9/tools/tiffcp.c:1190 cpStripToTile
This issue was assigned CVE-2018-12900
Testing without asan. When running under valgrind, I do not see any issue with poc1. poc2, however, gives: $ gdb -q --args tiffcp -i poc2 output.tiff (gdb) run [...] DumpModeDecode: Not enough data for scanline 0, expected a request for at most 152 bytes, got a request for 4195328 bytes. Program received signal SIGSEGV, Segmentation fault. 0x0000555555559094 in cpSeparateBufToContigBuf (bytes_per_sample=4097, spp=1024, inskew=0, outskew=<optimized out>, cols=1024, rows=0, in=0x7ffff5d74803 "", out=0x7ffff6974001 "ELF\002\001\001") at tiffcp.c:1228 1228 *out++ = *in++; (gdb) bt #0 0x0000555555559094 in cpSeparateBufToContigBuf (bytes_per_sample=4097, spp=1024, inskew=0, outskew=<optimized out>, cols=1024, rows=0, in=0x7ffff5d74803 "", out=0x7ffff6974001 "ELF\002\001\001") at tiffcp.c:1228 #1 readSeparateTilesIntoBuffer (in=0x55555575d940, buf=<optimized out>, imagelength=2, imagewidth=1, spp=1024) at tiffcp.c:1458 #2 0x0000555555558a33 in cpImage (in=0x55555575d940, out=0x55555575d010, fin=0x555555558cd0 <readSeparateTilesIntoBuffer>, fout=0x555555559450 <writeBufferToSeparateTiles>, imagelength=2, imagewidth=1, spp=1024) at tiffcp.c:1253 #3 0x0000555555558b73 in cpSeparateTiles2SeparateTiles (in=<optimized out>, out=<optimized out>, imagelength=<optimized out>, imagewidth=<optimized out>, spp=<optimized out>) at tiffcp.c:1747 #4 0x000055555555675f in tiffcp (out=0x55555575d010, in=0x55555575d940) at tiffcp.c:814 #5 main (argc=4, argv=0x7fffffffe858) at tiffcp.c:303 $
I have noticed these int overflows: 1394 int iskew = imagew - tilew*spp; (gdb) p tilew $40 = 4195328 (gdb) p spp $41 = 1024 (gdb) p tilew*spp $42 = 1048576 1447 if (colb + tilew*spp > imagew) { (gdb) p tilew $45 = 4195328 (gdb) p spp $46 = 1024 (gdb) p tilew*spp $47 = 1048576 These have influence on code paths and also on pointer arithmetics in cpSeparateBufToContigBuf().
What is actually point of -i option (i.e. 'Ignore non-fatal read errors and continue processing of the input file')? Is it still needed?
https://gitlab.com/libtiff/libtiff/merge_requests/44
https://gitlab.com/libtiff/libtiff/merge_requests/60 should have fixed it