LibTiff Mailing List
TIFF and LibTiff Mailing List Archive
April 2009
Previous Thread
Next Thread
Previous by Thread
Next by Thread
Previous by Date
Next by Date
Contact
The TIFF Mailing List Homepage
This list is run by Frank Warmerdam
Archive maintained by AWare Systems
Thread
2009.05.05 18:42 "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 > <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. > ... > 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? --Toby > >> 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.