扫码分享
验证：
体验盒子Source: http://bugzilla.maptools.org/show_bug.cgi?id=2693
On 4.0.7:
# tiffsplit $FILE
==2007== Invalid read of size 4
==2007==at 0x40CD1A: _TIFFVGetField (tif_dir.c:1072)
==2007==by 0x41B2C5: TIFFVGetField (tif_dir.c:1198)
==2007==by 0x41B2C5: TIFFGetField (tif_dir.c:1182)
==2007==by 0x404CCF: tiffcp (tiffsplit.c:220)
==2007==by 0x404CCF: main (tiffsplit.c:89)
==2007==Address 0x0 is not stack'd, malloc'd or (recently) free'd
------- Comment #1 From zhangtan 2017-05-15 01:20:26 -------
The place of Out of bound read:
ret_val = 0;
for (i = 0; i < td->td_customValueCount; i++) {
TIFFTagValue *tv = td->td_customValues + i;
if (tv->info->field_tag != tag)
continue;
------- Comment #2 From zhangtan 2017-05-15 01:29:10 -------
The place of Out of bound read:
The 1072 line of tif_dir.c
1068 ret_val = 0;
1069 for (i = 0; i < td->td_customValueCount; i++) {
1070 TIFFTagValue *tv = td->td_customValues + i;
1071
1072 if (tv->info->field_tag != tag)
1073 continue;
As tv increased in 1070, Out of bound read happened in 1072 when the pointer tv
was referenced.
------- Comment #3 From zhangtan 2017-05-15 01:46:33 -------
PoC:
Detailed information of the bug can be reproduced using the valgrind tool:
# valgrind tiffsplit $File(the testcase in the attachment)
Error Message:
==23520== Invalid read of size 4
==23520==at 0x40CD1A: _TIFFVGetField (tif_dir.c:1072)
==23520==by 0x41B2C5: TIFFVGetField (tif_dir.c:1198)
==23520==by 0x41B2C5: TIFFGetField (tif_dir.c:1182)
==23520==by 0x404CCF: tiffcp (tiffsplit.c:220)
==23520==by 0x404CCF: main (tiffsplit.c:89)
==23520==Address 0x0 is not stack'd, malloc'd or (recently) free'd
==23520==
==23520==
==23520== Process terminating with default action of signal 11 (SIGSEGV)
==23520==Access not within mapped region at address 0x0
==23520==at 0x40CD1A: _TIFFVGetField (tif_dir.c:1072)
==23520==by 0x41B2C5: TIFFVGetField (tif_dir.c:1198)
==23520==by 0x41B2C5: TIFFGetField (tif_dir.c:1182)
==23520==by 0x404CCF: tiffcp (tiffsplit.c:220)
==23520==by 0x404CCF: main (tiffsplit.c:89)
==23520==If you believe this happened as a result of a stack
==23520==overflow in your program's main thread (unlikely but
==23520==possible), you can try to increase the size of the
==23520==main thread stack using the --main-stacksize= flag.
==23520==The main thread stack size used in this run was 8388608.
==23520==
==23520== HEAP SUMMARY:
==23520== in use at exit: 17,821 bytes in 42 blocks
==23520== total heap usage: 96 allocs, 54 frees, 59,223 bytes allocated
==23520==
==23520== LEAK SUMMARY:
==23520==definitely lost: 0 bytes in 0 blocks
==23520==indirectly lost: 0 bytes in 0 blocks
==23520==possibly lost: 0 bytes in 0 blocks
==23520==still reachable: 17,821 bytes in 42 blocks
==23520== suppressed: 0 bytes in 0 blocks
==23520== Rerun with --leak-check=full to see details of leaked memory
==23520==
==23520== For counts of detected and suppressed errors, rerun with: -v
==23520== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
Segmentation fault
Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/42301.zip
体验盒子
