In LibTIFF 4.0.10, the TIFFFdOpen function in tif_unix.c has a memory leak, when using pal2rgb. Upstream issue: http://bugzilla.maptools.org/show_bug.cgi?id=2836
Created libtiff tracking bugs for this issue: Affects: fedora-all [bug 1667124]
Created mingw-libtiff tracking bugs for this issue: Affects: epel-7 [bug 1667160]
Created mingw-libtiff tracking bugs for this issue: Affects: fedora-all [bug 1667167]
Low impact memory leak. Easy to reproduce: ``` valgrind --leak-check=full pal2rgb tiff /dev/null ==20504== Memcheck, a memory error detector ==20504== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==20504== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info ==20504== Command: pal2rgb tiff /dev/null ==20504== TIFFReadDirectory: Warning, Unknown field with tag 2056 (0x808) encountered. tiff: Expecting a palette image. ==20504== ==20504== HEAP SUMMARY: ==20504== in use at exit: 2,469 bytes in 12 blocks ==20504== total heap usage: 25 allocs, 13 frees, 7,279 bytes allocated ==20504== ==20504== 2,469 (1,085 direct, 1,384 indirect) bytes in 1 blocks are definitely lost in loss record 11 of 11 ==20504== at 0x4C29BC3: malloc (vg_replace_malloc.c:299) ==20504== by 0x4E6D197: TIFFClientOpen (in /usr/lib64/libtiff.so.5.2.0) ==20504== by 0x4E7A0B8: TIFFFdOpen (in /usr/lib64/libtiff.so.5.2.0) ==20504== by 0x4E7A116: TIFFOpen (in /usr/lib64/libtiff.so.5.2.0) ==20504== by 0x401077: ??? (in /usr/bin/pal2rgb) ==20504== by 0x5A453D4: (below main) (in /usr/lib64/libc-2.17.so) ==20504== ==20504== LEAK SUMMARY: ==20504== definitely lost: 1,085 bytes in 1 blocks ==20504== indirectly lost: 1,384 bytes in 11 blocks ==20504== possibly lost: 0 bytes in 0 blocks ==20504== still reachable: 0 bytes in 0 blocks ==20504== suppressed: 0 bytes in 0 blocks ==20504== ==20504== For counts of detected and suppressed errors, rerun with: -v ==20504== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0) ```
pal2rgb doesn't free memory in cases of errors (and then immediately exits and returns -1). It's just a tiny wrapper around some very specific libtiff functionality, so I'm a little unclear why this was assigned a CVE as I haven't divined a way in which this could have any sort of impact on the availability of a program. Good bug to fix, but doesn't really feel security relevant.
I submitted an upstream fix here. Not yet merged in: https://gitlab.com/libtiff/libtiff/merge_requests/50. To the best of my knowledge, this flaw poses no security impact to our customers.
Looked at this one last time as NVD has this rated as remote code execution. Before fix: ``` ./pal2rgb ../../poc /dev/null TIFFReadDirectory: Warning, Unknown field with tag 2056 (0x808) encountered. ../../poc: Expecting a palette image. ================================================================= ==27253==ERROR: LeakSanitizer: detected memory leaks Direct leak of 1090 byte(s) in 1 object(s) allocated from: #0 0x4eba0f (/root/tiff/libtiff/tools/.libs/pal2rgb+0x4eba0f) #1 0x7f4e89d5c46c (/usr/local/lib/libtiff.so.5+0x1a446c) #2 0x7f4e89d0c421 (/usr/local/lib/libtiff.so.5+0x154421) #3 0x7f4e89d5aef4 (/usr/local/lib/libtiff.so.5+0x1a2ef4) #4 0x7f4e89d5c405 (/usr/local/lib/libtiff.so.5+0x1a4405) #5 0x528bf2 (/root/tiff/libtiff/tools/.libs/pal2rgb+0x528bf2) #6 0x7f4e8978f412 (/lib64/libc.so.6+0x24412) Indirect leak of 1224 byte(s) in 1 object(s) allocated from: #0 0x4ebea6 (/root/tiff/libtiff/tools/.libs/pal2rgb+0x4ebea6) #1 0x7f4e89d5c50c (/usr/local/lib/libtiff.so.5+0x1a450c) #2 0x7f4e89bec167 (/usr/local/lib/libtiff.so.5+0x34167) #3 0x7f4e89c1cf4e (/usr/local/lib/libtiff.so.5+0x64f4e) #4 0x7f4e89c22af0 (/usr/local/lib/libtiff.so.5+0x6aaf0) #5 0x7f4e89d0f475 (/usr/local/lib/libtiff.so.5+0x157475) #6 0x7f4e89d5aef4 (/usr/local/lib/libtiff.so.5+0x1a2ef4) #7 0x7f4e89d5c405 (/usr/local/lib/libtiff.so.5+0x1a4405) #8 0x528bf2 (/root/tiff/libtiff/tools/.libs/pal2rgb+0x528bf2) #9 0x7f4e8978f412 (/lib64/libc.so.6+0x24412) ``` After fix: ./pal2rgb ../../poc /dev/null TIFFReadDirectory: Warning, Unknown field with tag 2056 (0x808) encountered. ../../poc: Expecting a palette image.
Statement: Red Hat Product Security believes that while this flaw can leak memory in certain situations, it is not a vulnerability and does not pose any risk to our customers.