AWARE SYSTEMS
TIFF and LibTiff Mail List Archive

Thread

2015.11.14 13:19 "[Tiff] ColorMap and high bit depth", by Even Rouault
2015.11.14 14:33 "Re: [Tiff] ColorMap and high bit depth", by Bob Friesenhahn
2015.11.14 14:45 "Re: [Tiff] ColorMap and high bit depth", by Even Rouault
2015.11.16 13:35 "Re: [Tiff] ColorMap and high bit depth", by Even Rouault
2015.11.16 14:49 "Re: [Tiff] ColorMap and high bit depth", by Bob Friesenhahn
2015.11.16 14:56 "Re: [Tiff] ColorMap and high bit depth", by Even Rouault
2015.11.14 15:11 "Re: [Tiff] ColorMap and high bit depth", by Olivier Paquet

2015.11.16 14:56 "Re: [Tiff] ColorMap and high bit depth", by Even Rouault

Le lundi 16 novembre 2015 15:49:13, Bob Friesenhahn a écrit:

The colormap is not compressed so the best defense against DOS is to check that the file has provided the backing data for the colormap before making the memory allocation. It is easy to declare a 1.6 GB colormap, but much more difficult to supply it.

The code currently would error out after some time if the file isn't 1.6 GB large, but 1.6 GB TIFF files are not uncommon at all in my area of interest (GIS) for example. But ingesting it in a single gulp for a fake colormap isn't really expected :-)

So is there any opposition to me committing the following?

My own preference is that 'large' allocations should be validated against the underlying file.

That wouldn't catch my above example of a potentially large file that could potentially looks legit, but that is not in fact.

Denial of service is then not possible unless rogue software constructs or modifies files on the target machine.

That said, it does not seem like the added restriction is going to cause harm for existing usages.

--
Spatialys - Geospatial professional services
http://www.spatialys.com