You need to log in before you can comment on or make changes to this bug.
SHA1: 0e1a4889e24f03846f9353cb5f65e26e9f5a2587 Found by: Henri Salo from Nixu Corporation Used tools: - afl 2.35b - rc0r's afl-utils Can be reproduced at least with tiffcrop and tiff2bw from CVS. 5175 assert(fip->field_passcount==1); 5176 err=TIFFReadDirEntryByteArray(tif,dp,&data); 5177 if (err==TIFFReadDirEntryErrOk) 5178 { 5179 int m; 5180 if( data[dp->tdir_count-1] != '\0' ) 5181 { 5182 TIFFWarningExt(tif->tif_clientdata,module,"ASCII value for tag \"%s\" does not end in null byte. Forcing it to be null",fip->field_name); 5183 data[dp->tdir_count-1] = '\0'; 5184 } 5185 m=TIFFSetField(tif,dp->tdir_tag,(uint32)(dp->tdir_count),data); #0 0x00007ffff7a792e1 in TIFFFetchNormalTag (tif=tif@entry=0x606010, dp=dp@entry=0x606590, recover=recover@entry=1) at tif_dirread.c:5180 #1 0x00007ffff7a97cc0 in TIFFReadDirectory (tif=tif@entry=0x606010) at tif_dirread.c:3821 #2 0x00007ffff7b682b4 in TIFFClientOpen (name=name@entry=0x7fffffffe34f "crasher.tif", mode=mode@entry=0x404ef3 "r", clientdata=clientdata@entry=0x3, readproc=readproc@entry=0x7ffff7bb5aa0 <_tiffReadProc>, writeproc=writeproc@entry=0x7ffff7bb5770 <_tiffWriteProc>, seekproc=seekproc@entry=0x7ffff7bb5690 <_tiffSeekProc>, closeproc=0x7ffff7bb55b0 <_tiffCloseProc>, sizeproc=0x7ffff7bb5420 <_tiffSizeProc>, mapproc=0x7ffff7bb6150 <_tiffMapProc>, unmapproc=0x7ffff7bb5330 <_tiffUnmapProc>) at tif_open.c:466 #3 0x00007ffff7bb6423 in TIFFFdOpen (fd=fd@entry=3, name=name@entry=0x7fffffffe34f "crasher.tif", mode=mode@entry=0x404ef3 "r") at tif_unix.c:211 #4 0x00007ffff7bb6639 in TIFFOpen (name=0x7fffffffe34f "crasher.tif", mode=mode@entry=0x404ef3 "r") at tif_unix.c:250 #5 0x000000000040185e in main (argc=<optimized out>, argv=0x7fffffffe0f8) at tiff2bw.c:159 valgrind ./bin/tiff2bw crasher.tif test ==16676== Memcheck, a memory error detector ==16676== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al. ==16676== Using Valgrind-3.10.0 and LibVEX; rerun with -h for copyright info ==16676== Command: ./bin/tiff2bw crasher.tif test ==16676== TIFFReadDirectoryCheckOrder: Warning, Invalid TIFF directory; tags are not sorted in ascending order. TIFFReadDirectory: Warning, Unknown field with tag 12336 (0x3030) encountered. TIFFReadDirectory: Warning, Unknown field with tag 48 (0x30) encountered. ==16676== Invalid read of size 1 ==16676== at 0x4E852E1: TIFFFetchNormalTag (tif_dirread.c:5180) ==16676== by 0x4EA3CBF: TIFFReadDirectory (tif_dirread.c:3821) ==16676== by 0x4F742B3: TIFFClientOpen (tif_open.c:466) ==16676== by 0x4FC2422: TIFFFdOpen (tif_unix.c:211) ==16676== by 0x4FC2638: TIFFOpen (tif_unix.c:250) ==16676== by 0x40185D: main (tiff2bw.c:159) ==16676== Address 0xffffffffffffffff is not stack'd, malloc'd or (recently) free'd ==16676== ==16676== ==16676== Process terminating with default action of signal 11 (SIGSEGV) ==16676== Access not within mapped region at address 0xFFFFFFFFFFFFFFFF ==16676== at 0x4E852E1: TIFFFetchNormalTag (tif_dirread.c:5180) ==16676== by 0x4EA3CBF: TIFFReadDirectory (tif_dirread.c:3821) ==16676== by 0x4F742B3: TIFFClientOpen (tif_open.c:466) ==16676== by 0x4FC2422: TIFFFdOpen (tif_unix.c:211) ==16676== by 0x4FC2638: TIFFOpen (tif_unix.c:250) ==16676== by 0x40185D: main (tiff2bw.c:159) ==16676== If you believe this happened as a result of a stack ==16676== overflow in your program's main thread (unlikely but ==16676== possible), you can try to increase the size of the ==16676== main thread stack using the --main-stacksize= flag. ==16676== The main thread stack size used in this run was 8388608. ==16676== ==16676== HEAP SUMMARY: ==16676== in use at exit: 2,908 bytes in 8 blocks ==16676== total heap usage: 15 allocs, 7 frees, 9,800 bytes allocated ==16676== ==16676== LEAK SUMMARY: ==16676== definitely lost: 0 bytes in 0 blocks ==16676== indirectly lost: 0 bytes in 0 blocks ==16676== possibly lost: 0 bytes in 0 blocks ==16676== still reachable: 2,908 bytes in 8 blocks ==16676== suppressed: 0 bytes in 0 blocks ==16676== Rerun with --leak-check=full to see details of leaked memory ==16676== ==16676== For counts of detected and suppressed errors, rerun with: -v ==16676== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0) Segmentation fault
Created an attachment (id=693) [details] 2016-11-16-tiff2bw-invalid-read.tif
This fuzzing was sponsored by Kapsi internet-käyttäjät ry https://www.kapsi.fi/
Fixed per 2016-11-16 Even Rouault <even.rouault at spatialys.com> * libtiff/tif_dirread.c: in TIFFFetchNormalTag(), do not dereference NULL pointer when values of tags with TIFF_SETGET_C16_ASCII / TIFF_SETGET_C32_ASCII access are 0-byte arrays. Fixes http://bugzilla.maptools.org/show_bug.cgi?id=2593 (regression introduced by previous fix done on 2016-11-11 for CVE-2016-9297). Reported by Henri Salo. /cvs/maptools/cvsroot/libtiff/ChangeLog,v <-- ChangeLog new revision: 1.1163; previous revision: 1.1162 /cvs/maptools/cvsroot/libtiff/libtiff/tif_dirread.c,v <-- libtiff/tif_dirread.c new revision: 1.204; previous revision: 1.203
Please use CVE-2016-9448 for this issue. oss-security mailing list notified: http://www.openwall.com/lists/oss-security/2016/11/18/11 CVE assigned: http://www.openwall.com/lists/oss-security/2016/11/18/15
Note: I don't think a CVE was necessary. The bug resulted from a previous incomplete fix done a few days before. It shouldn't affect any officially released version.