tiff2pdf: Fix CVE-2017-9935
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.
Showing with 47 additions and 21 deletions