2015.11.14 14:33 "Re: [Tiff] ColorMap and high bit depth", by Bob Friesenhahn

I've noticed that currently we support ColorMap up to BitsPerSample=28. Since 3 * 2^28 * sizeof(uint16) = 1.6 GB (< 2 GB, which is the sanity check in TIFFReadDirEntryArray() ). And this is read by default at file opening, so it can be used as a sort of DoS due to excessive I/O and memory usage.

Does it make sense to support ColorMap with such high bit depths? Couldn't we limit reading ColorTable up to 24 bit for example (which would put the limit to 50 MB)? Another option would be to defer reading the color map until it is explicitly requested by the application, but do we need such complication?

28 bits seems excessive to me. GraphicsMagick (and likely ImageMagick) only support colormaps with a 16-bit index (it would be nice to support a bit more though). Colormaps decrease in value as they become larger.

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.

Bob
--
Bob Friesenhahn
bfriesen@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer, http://www.GraphicsMagick.org/