Bug 2593 - CVE-2016-9448: Invalid read of size 1 in TIFFFetchNormalTag (tif_dirread.c:5180)
: CVE-2016-9448: Invalid read of size 1 in TIFFFetchNormalTag (tif_dirread.c:5180)
Status: RESOLVED FIXED
: libtiff
default
: unspecified
: PC Linux
: P1 critical
: ---
Assigned To:
:
:
:
:
:
  Show dependency treegraph
 
Reported: 2016-11-16 08:38 by
Modified: 2016-11-19 05:30 (History)


Attachments
2016-11-16-tiff2bw-invalid-read.tif (1.21 KB, image/tiff)
2016-11-16 08:38, Henri Salo
Details


Note

You need to log in before you can comment on or make changes to this bug.


Description From 2016-11-16 08:38:17
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
------- Comment #1 From 2016-11-16 08:38:45 -------
Created an attachment (id=693) [details]
2016-11-16-tiff2bw-invalid-read.tif
------- Comment #2 From 2016-11-16 08:41:02 -------
This fuzzing was sponsored by Kapsi internet-käyttäjät ry https://www.kapsi.fi/
------- Comment #3 From 2016-11-16 10:19:16 -------
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
------- Comment #4 From 2016-11-19 04:16:10 -------
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
------- Comment #5 From 2016-11-19 05:30:58 -------
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.