CVE-2017-9935 / tiff

[Brian May <brian@linuxpenguins.xyz>]

Looks like this vulnerability - at least for the first test case - is
because we assume that a tiff will only have one transfer function that
is the same for all pages. However, we 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.

I haven't yet looked at the other exploits in detail, however I suspect
they might be all variations on the same vulnerability.

Unfortunately, having trouble finding tiff specifications. At looks like
I need to be an Adobe partner to access the specifications at
<https://partners.adobe.com/public/developer/en/tiff/TIFF6.pdf>. In
particular, would like to know if different transfer functions for each
page are permitted. Regardless, it seems clear the code doesn't support
it. It seems to assume the transfer function will be the same for every
page.

Also can't find an upstream BTS, is this a project with a dead upstream?
http://www.libtiff.org/bugs.html contains dead links.

Suggested solutions:

* I could allocate 4 bytes for every page, regardless of the transfer
  function. This wouldn't necessarily give correct results, but would
  presumably solve the security issue. This is probably the simplist
  solution.
* I could allocate the memory required after it scans all pages, and we
  know what the final transfer function is. Again, may not necessarily
  give correct results, but would presumably solve the security
  issue. Probably not really worth it over the previous solution
  for a maximum potential savings of 2 bytes per page.
* I could alter the code to abort with an error if the transfer function
  changes to have different (or maybe just increased) memory requirements.
-- 
Brian May <brian@linuxpenguins.xyz>
https://linuxpenguins.xyz/brian/