In December I spent my 10 hours continuing working on CVE-2017-9935 /
tiff / tiff3.
Fixing this was made difficult, because it is possible this code has
never been tested against an image containing an actual transfer
I submitted a patch upstream, and it was accepted.
I uploaded a fixed version of tiff to wheezy-security. The other
distributions are still vulnerable.
I looked at tiff3 in wheezy, and while it contains the vulnerable source
code, it isn't used to build a vulnerable tiff2pdf, so I concluded there
is not much point updating it. Although I did make a fixed version
available for testing.
I also looked into CVE-2017-11613 - also for tiff (and very much
probably tiff3). I found the correct upstream bug report and updated the
security tracking information.
Redhat have marked this bug as NOTABUG:
I am not entirely convinced that this is not a bug. Perhaps however, it
is a possibility that it isn't feasible fix. Fixing this problem might
require parsing the file two times - once to find out what the actual
size is, and another time to actually read in the data.
In one of the duplicate upstream bug reports, somebody suggested a
hardcoded upper limit (at least that is how I read it) for the maximum
size value. I don't think this is a good idea however.
Brian May <firstname.lastname@example.org>