You need to log in before you can comment on or make changes to this bug.
Created an attachment (id=885) [details] libtiff-tiffcp-heapoverflow-interceptor_strlen hi,libtiff team.i found a heap-buffer-overflow in interceptor_strlen The vuln is triggered by ./tiffcp -i poc /dev/null the asan info is blew: ================================================================= ==24144==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x602000000233 at pc 0x000000487fc0 bp 0x7ffced48d5d0 sp 0x7ffced48cd80 READ of size 1 at 0x602000000233 thread T0 #0 0x487fbf in __interceptor_strlen.part.31 (/root/fuzz/tiff-4.0.10/tools/tiffcp+0x487fbf) #1 0x519cac in tiffcp /root/fuzz/tiff-4.0.10/tools/tiffcp.c:800:57 #2 0x519cac in main /root/fuzz/tiff-4.0.10/tools/tiffcp.c:301 #3 0x7f2c2f61309a in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2409a) #4 0x41d4b9 in _start (/root/fuzz/tiff-4.0.10/tools/tiffcp+0x41d4b9) 0x602000000233 is located 0 bytes to the right of 3-byte region [0x602000000230,0x602000000233) allocated by thread T0 here: #0 0x4e2290 in malloc (/root/fuzz/tiff-4.0.10/tools/tiffcp+0x4e2290) #1 0x5a9249 in _TIFFmalloc /root/fuzz/tiff-4.0.10/libtiff/tif_unix.c:314:10 #2 0x52fc46 in TIFFVSetField /root/fuzz/tiff-4.0.10/libtiff/tif_dir.c:852:6 #3 0x52fc46 in TIFFSetField /root/fuzz/tiff-4.0.10/libtiff/tif_dir.c:796 #4 0x5588b5 in TIFFFetchNormalTag /root/fuzz/tiff-4.0.10/libtiff/tif_dirread.c:5210:9 #5 0x54e99a in TIFFReadDirectory /root/fuzz/tiff-4.0.10/libtiff/tif_dirread.c:3985:12 #6 0x594d60 in TIFFClientOpen /root/fuzz/tiff-4.0.10/libtiff/tif_open.c:464:8 #7 0x5a901f in TIFFFdOpen /root/fuzz/tiff-4.0.10/libtiff/tif_unix.c:209:8 #8 0x5a901f in TIFFOpen /root/fuzz/tiff-4.0.10/libtiff/tif_unix.c:248 SUMMARY: AddressSanitizer: heap-buffer-overflow (/root/fuzz/tiff-4.0.10/tools/tiffcp+0x487fbf) in __interceptor_strlen.part.31 Shadow bytes around the buggy address: 0x0c047fff7ff0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0c047fff8000: fa fa 00 00 fa fa fd fd fa fa 00 07 fa fa fd fa 0x0c047fff8010: fa fa 00 fa fa fa fd fa fa fa 02 fa fa fa fd fa 0x0c047fff8020: fa fa 04 fa fa fa fd fa fa fa fd fa fa fa 04 fa 0x0c047fff8030: fa fa 04 fa fa fa fd fa fa fa 04 fa fa fa 02 fa =>0x0c047fff8040: fa fa fd fa fa fa[03]fa fa fa 00 fa fa fa 02 fa 0x0c047fff8050: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c047fff8060: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c047fff8070: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c047fff8080: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c047fff8090: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07 Heap left redzone: fa Freed heap region: fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 Stack after return: f5 Stack use after scope: f8 Global redzone: f9 Global init order: f6 Poisoned by user: f7 Container overflow: fc Array cookie: ac Intra object redzone: bb ASan internal: fe Left alloca redzone: ca Right alloca redzone: cb ==24144==ABORTING
The problem is that the TIFF API offers no way to know how many bytes were effectively stored in a ASCII field. const char* inknames; if (TIFFGetField(in, TIFFTAG_INKNAMES, &inknames)) { ... } usually it is a null terminated string, so that causes no problem. But TIFFTAG_INKNAMES is a "list" of terminated string, ie a char array with TIFFTAG_NUMBEROFINKS null chars. If TIFFTAG_NUMBEROFINKS is greater than the real number of strings in TIFFTAG_INKNAMES, the reading code will run over the end of the data, thus the heapoverflow. I don't see any way to fix the issue without upgrading the API to add a way to retrieve the ASCII fields length.
Bugzilla is no longer used for tracking libtiff issues. Remaining open tickets, such as this one, have been migrated to the libtiff GitLab instance at https://gitlab.com/libtiff/libtiff/issues . The migrated tickets have their summary prefixed with [BZ#XXXX] where XXXX is the initial Bugzilla issue number.
