December Report
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 <brian@linuxpenguins.xyz>
https://linuxpenguins.xyz/brian/
Reply to: