It is possible to craft a TIFF document where the IFD list is circular,
leading to an infinite loop while traversing the chain. The libtiff
directory reader has a failsafe that will break out of this loop after
reading 65535 directory entries, but it will continue processing,
consuming time and resources to process what is essentially a bogus TIFF
document.
This change fixes the above behavior by breaking out of processing when
a TIFF document has >= 65535 directories and terminating with an error.
Fix for http://bugzilla.maptools.org/show_bug.cgi?id=2704
This vulnerability - at least for the supplied test case - is because we
assume that a tiff will only have one transfer function that is the same
for all pages. This is not required by the TIFF standards.
We than read the transfer function for every page. Depending on the
transfer function, we allocate either 2 or 4 bytes to the XREF buffer.
We allocate this memory after we read in the transfer function for the
page.
For the first exploit - POC1, this file has 3 pages. For the first page
we allocate 2 extra extra XREF entries. Then for the next page 2 more
entries. Then for the last page the transfer function changes and we
allocate 4 more entries.
When we read the file into memory, we assume we have 4 bytes extra for
each and every page (as per the last transfer function we read). Which
is not correct, we only have 2 bytes extra for the first 2 pages. As a
result, we end up writing past the end of the buffer.
There are also some related issues that this also fixes. For example,
TIFFGetField can return uninitalized pointer values, and the logic to
detect a N=3 vs N=1 transfer function seemed rather strange.
It is also strange that we declare the transfer functions to be of type
float, when the standard says they are unsigned 16 bit values. This is
fixed in another patch.
This patch will check to ensure that the N value for every transfer
function is the same for every page. If this changes, we abort with an
error. In theory, we should perhaps check that the transfer function
itself is identical for every page, however we don't do that due to the
confusion of the type of the data in the transfer function.
compressed images. Reported by Tyler Bohan of Cisco Talos as
TALOS-CAN-0187 / CVE-2016-5652.
Also prevents writing 2 extra uninitialized bytes to the file stream.
t2p_readwrite_pdf_image_tile(), causing crash, when reading a
JPEG compressed image with TIFFTAG_JPEGTABLES length being one.
Reported as MSVR 35101 by Axel Souchet and Vishal Chauhan from
the MSRC Vulnerabilities & Mitigations team.
in heap or stack allocated buffers. Reported as MSVR 35093,
MSVR 35096 and MSVR 35097. Discovered by Axel Souchet and Vishal
Chauhan from the MSRC Vulnerabilities & Mitigations team.
* tools/tiff2pdf.c: fix out-of-bounds write vulnerabilities in
heap allocate buffer in t2p_process_jpeg_strip(). Reported as MSVR
35098. Discovered by Axel Souchet and Vishal Chauhan from the MSRC
Vulnerabilities & Mitigations team.
* libtiff/tif_pixarlog.c: fix out-of-bounds write vulnerabilities
in heap allocated buffers. Reported as MSVR 35094. Discovered by
Axel Souchet and Vishal Chauhan from the MSRC Vulnerabilities &
Mitigations team.
* libtiff/tif_write.c: fix issue in error code path of TIFFFlushData1()
that didn't reset the tif_rawcc and tif_rawcp members. I'm not
completely sure if that could happen in practice outside of the odd
behaviour of t2p_seekproc() of tiff2pdf). The report points that a
better fix could be to check the return value of TIFFFlushData1() in
places where it isn't done currently, but it seems this patch is enough.
Reported as MSVR 35095. Discovered by Axel Souchet & Vishal Chauhan &
Suha Can from the MSRC Vulnerabilities & Mitigations team.
definitions that configure produces, including for WIN64. Still
needs to be tested.
'lld' is not assured by the run-time DLLs and so GCC warns.
Add TIFF_SIZE_T and TIFF_SIZE_FORMAT to provide a type definition
and printf format specifier to deal with printing values of
'size_t' type. In particular, this was necessary for WIN64.
Added a configure test for if the system headers provide 'optarg'
(normal case) and block out the many explicit 'extern' statements
in the utilities. This was found to be necessary under Windows
when getopt is in a DLL and the symbols are already imported with
dllimport via standard header files.
http://bugzilla.maptools.org/show_bug.cgi?id=2078#c9
The problem is that TIFF library attempts to write TIFF header as soon as the
tiff2pdf utility initializes the library. Fortunately, the library contains an
I/O abstraction feature, so there are no hardcoded writes to a file descriptor
anywhere. In particular, it appears that the utility's output suppression
feature can be used to suppress the initial write of the header.
There are a lot of code like this:
buflen=snprintf(buffer, sizeof(buffer), "%lu", (unsigned long)number);
written += t2pWriteFile(output, (tdata_t) buffer, buflen );
in tiff2pdf. This is seriously broken: when formatted string is larger than
buffer, snprintf return value is >= sizeof(buffer) [current standard] or -1
[legacy]. And in case of other errors, snprintf returns -1.
Both would result in reading unallocated memory and possible SIGSEGV (DoS).
I doubt it can be really exploitable (to begin with, in most cases buffer was
large enough and sprintf->snprintf change was pure paranoia, IMO), but /if/ you
decided previous code was not safe and snprintf is necessary, /then/ you MUST
check its return value.
