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 function. I submitted a patch upstream, and it was accepted. https://gitlab.com/libtiff/libtiff/merge_requests/7 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. https://people.debian.org/~bam/debian/pool/main/t/tiff3/ 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. http://bugzilla.maptools.org/show_bug.cgi?id=2724 Redhat have marked this bug as NOTABUG: https://bugzilla.redhat.com/show_bug.cgi?id=1475530 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. http://bugzilla.maptools.org/show_bug.cgi?id=2760 Regards -- Brian May <br...@linuxpenguins.xyz> https://linuxpenguins.xyz/brian/
