2009.04.26 17:22 "[Tiff] Packbits worst case encoded length", by Simon Berger

2009.05.05 16:39 "Re: [Tiff] Packbits worst case encoded length", by Bob Friesenhahn

Somehow I just received a bunch of tiff list email which was choked up somewhere since April 30. This means that I missed joining the fray.

My only contribution is that on my system there must be at least five different memory allocation libraries to choose from, and I can add more if needed. Each one has some sort of special properties. I normally use one which is both thread-friendly, fast, and includes memory debugging support with guard pages and the other popular goodies.

Malloc checking libraries only go so far and a multitude of things can go wrong that the malloc library can not detect. Guard pages are only somewhat useful since they only cover the case where there is a linear overwrite past the end of the allocated buffer. They don't help in the case where memory is overwritten in some other allocated buffer, or the case where the attacker is aware of the guard pages and assures that the overwrite data retains the original guard content.

There really is no substitute for careful implementation and inspection of the code for oversights and errors.

Among popular file formats, it seems that TIFF is among the most difficult to make secure against the whiley hacker since it is a file format which stores file offsets.

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