2009.05.05 18:09 "Re: [Tiff] Packbits worst case encoded length", by Albert Cahalan

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

<bfriesen@simple.dallas.tx.us> wrote:

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.

They don't help in the case where memory is overwritten in some other allocated buffer,

In a buffer you didn't protect? Of course. I'm not trying to sell you a silver bullet.

or the case where the attacker is aware of the guard pages and assures that the overwrite data retains the original guard content.

No, you're thinking of canaries or poisoning.

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".

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.