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

2009.05.05 18:42 "[Tiff] Guard pages - was Re: Packbits worst case encoded length", by Toby Thain

On 5-May-09, at 2:09 PM, Albert Cahalan wrote:

On Tue, May 5, 2009 at 12:39 PM, Bob Friesenhahn

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.

Sure, but this is a **very** common and dangerous case.

Guard pages are pages of memory that you can't read or write. There is no "original guard content" to preserve. Any attempt to read or write to a guard page will cause an immediate crash. Unlike canaries or poisoning, there is no need to keep checking a guard page. A guard page is enforced by the CPU's MMU.

To create a guard page on Linux, use mprotect.

To create a guard page on Windows, use VirtualProtect. Use PAGE_NOACCESS, not PAGE_GUARD. (!)

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

You need both. We call it "defense in depth".

We all agree, but why put it in libtiff specifically?



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.

Sure, though decompression code isn't dealing with those. Decompression code is a common source of trouble.