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.01 06:34 "Re: Packbits worst case encoded length", by Albert Cahalan
On Thu, Apr 30, 2009 at 6:30 PM, Toby Thain <toby@telegraphics.com.au> wrote: > On 30-Apr-09, at 3:31 PM, Albert Cahalan wrote: >> The alternative is that every app is structured >> like Google Chrome. It's a really sad result. > > I'm not sure what you mean here. I have avoided Chrome so far. Google Chrome developers pretty much assume that all libraries have security holes. They run the libraries in separate low-privilege processes. (yet still, the protection isn't perfect) Much the same has been discussed for GNOME and Firefox. Image rendering libraries run in separate processes, fenced in by SE Linux policy. > My objection (in so far that 'my' anything is relevant to this list, which > isn't much) is not that I'm a super-programmer whose code is always > bug-free. It is that such mechanism may not belong in a library like > libtiff. Suppose the library did this: void (*guarded_malloc)(size_t); // *.h file void (*guarded_malloc)(size_t) = malloc; // *.c file buffer = guarded_malloc(nbytes); // usage Library users could then do: guarded_malloc = my_guarded_malloc_function; You'd also need to cover any functions that need to be compatible: free, realloc, calloc, and strdup. > IIRC, OpenBSD has a memory allocator which fences with unmapped guard > pages[1,2]. ALL applications & libraries benefit. But this won't catch *all* > buffer overflows, or even any dangerous ones, necessarily. It could be a > useful debugging tool, though[3]. IIRC, that's only for the large chunks of memory that malloc gets from the kernel. If you ask for a pair of half-page allocations you may get them adjacent to each other. You'll get guard pages around the **pair** of half-page allocations. > In any case, I write as many bugs as anyone else. My approach to finding > bugs in a file format parser is to test. And test more. Fuzz testing with > random input I find is revealing. Memory protection hacks, while a nice > extra safety net, and definitely valuable in an operating system, are not a > substitute for that. That's an excellent idea, but you might not catch everything.