An exploitable remote code execution vulnerability exists in the handling of TIFF images in LibTIFF. A crafted TIFF document can lead to a type confusion vulnerability resulting in remote code execution. This vulnerability can be triggered via a TIFF file delivered to the application using LibTIFF’s tag extension functionality. External References: http://www.talosintelligence.com/reports/TALOS-2016-0190
Created libtiff tracking bugs for this issue: Affects: fedora-all [bug 1389231]
Created mingw-libtiff tracking bugs for this issue: Affects: fedora-all [bug 1389232] Affects: epel-7 [bug 1389233]
Analysis: The flaw is possibly caused by expecting a double value on the argument list, va_arg and there is none. This results in a possible sizeof(double) OOB read/write. This may result in a crash, or a difficult to pull off code exec.
Analysis: The reproducer reads BadFaxLines tag like this: uint32 *a; TiffGetField(tiff, TIFFTAG_BADFAXLINES, &a); Despite the documentation, which says: Tag Name Count Types TIFFTAG_BADFAXLINES 1 uint32* the correct way how to read the tag is this: uint32 count; uint16 *values; TIFFGetField(tiff, TIFFTAG_BADFAXLINES, &count, &values); That is because TIFFTAG_BADFAXLINES is considered an anonymous custom tag, and as such is has to be read as count and array of values. The reproducer does exactly what thumbnail utility is doing when it is processing BadFaxLines tag. However, processing this tag has been disabled in RHEL with patch for CVE-2016-3632. That means RHEL packages are not affected.