[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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

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 <brian@linuxpenguins.xyz>

Reply to: