2009.04.30 22:30 "Re: [Tiff] Packbits worst case encoded length", by Toby Thain

On 30-Apr-09, at 3:31 PM, Albert Cahalan wrote:

On Thu, Apr 30, 2009 at 3:25 PM, Toby Thain <toby@telegraphics.com.au> wrote:

On 30-Apr-09, at 3:12 PM, Albert Cahalan wrote:

On Thu, Apr 30, 2009 at 9:58 AM, Toby Thain <toby@telegraphics.com.au> wrote:

At the very least, you can have an #ifdef to enable memory protection on platforms that can support it. Windows and all the typical UNIX-like systems offer this.

They offer it for processes for 'free', as far as an application developer is concerned.

Whether libtiff should use such a facility directly? Well, the debate is open, I guess.

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.

BTW, since infinite portability is far too costly for the value it provides,

I didn't suggest 'infinite portability', just questioning a nonportable (and difficult to maintain) 'feature'.

you do draw a line somewhere. Crummy platforms are likely to be writing files only, not reading them. (embedded OSes in cameras, scanners, etc.) At most they need to read their own files, which will of course be well-formed.

Going without the memory protection is really really bad.

I don't, and haven't since Mac OS 9. And my Linux and Solaris systems don't do without it either.

Ah, but you do. Regular malloc doesn't put guard pages around memory allocations. The memory protection is there in your OS, but it's not getting full use.

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.

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

If you are going to do this, why put it in every library, and not it where it belongs, underneath? That's where similar stack protection tricks belong as well.

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.

--Toby

[1] https://buildsecurityin.us-cert.gov/daisy/bsi/articles/knowledge/ coding/301-BSI.html

[2] http://kerneltrap.org/node/5584 [3] http://www.scribd.com/doc/14282306/Using-OpenBSD-Security- Features-to-Find-Software-Bugs (p 19)