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

On Tue, May 5, 2009 at 2:32 PM, Bob Friesenhahn

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

> On Tue, 5 May 2009, Albert Cahalan wrote:

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

>

> Is it more dangerous than the other cases? What would > cause one case to be more dangerous than another?

Yes, a bit, though perhaps I should have said:

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

Some other types of bug are less exploitable. It's complicated.

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

>

> Ahhh, I see. This wastes a whole MMU page (4K, 8K, 16K, or ???) per memory > allocation.

Yes and no. You're wasting address space, not the RAM itself. There won't be a big chunk of unused RAM because of this.

At worst, some systems will reserve some swap space.

> It also needs to start on a MMU page boundary, which may be far

> beyond the user-requested allocation. If the user requests 128 bytes, then > that leaves a long region which is unchecked

The unchecked portion only matters if you are trying to find the bugs. It doesn't matter if you are just trying to prevent the bugs from being exploitable.

> and the underlying allocation

> really needs to be at least a page long. In order to be safe, there needs to > be protection against underflow, so the page below needs to be a guard page

> as well. The end result is that there is huge waste of memory if the user > allocations are small.

>

> It seems that the strategy taken can be controlled by which malloc library > is linked to at library link time, program link time, or preloaded via an OS

> specific means.

That would tend to affect all allocation done by the program, including ones that are very obviously safe. Things like tiny little linked list structs would eat 4 KB RAM and 12 KB address space.

I'm suggesting to use a different allocator for risky allocations. These would primarily be buffers that you decompress into.