Re: vulndev-1 and a suggestion about the ensuing discussion

[xenophi1e <oliver.lavery () sympatico ca>]

In-Reply-To: <75C025AE395F374B81F6416B1D4BDEFB01009380 () mtv-corpmail microfocus com>

> AS/400, where C programs in essence run under a virtual machine, and most
> out-of-bounds accesses will immediately trap.

That's interesting. I'm passingly familiar with the VMs used by AS/400, 
but I wasn't aware that out of bound accesses would immediately trap. I 
wonder how they do this...

I was under the impression that VMs used in this way were really just a 
sort of defense in depth. They don't prevent an individual process from 
being compromised but prevent that compromise from expanding beyond the 
boundaries of the VM. Do they really trap overruns from one valid chunk 
of memory into an adjacent one? 

> With help from mprotect or equivalent these areas could further be 
protected
> with guard pages.  There'd be a performance penalty for such a scheme
> (versus having each malloc'd area carry its own information, as is 
typical),
> but besides making the heap harder to corrupt, it'd let the 
implementation
> catch invalid and duplicate free's.

Storing things differently would be smart. Would guard pages actually be 
useful, tho'? mprotect() and VirtualProtectEx() type functions only work 
with the granularity of memory pages. So to effectively prevent this 
exploit all your malloc()s would have to allocate at least an entire page 
plus a second guard page which wouldn't need any physical storage. That's 
not very practical; at this point there wouldn't really be any need to 
use an allocator at all since all allocated objects that were protected 
would already consume an entire page. Yeah, there would definitely be 
quite a performance penalty for such a scheme...

Cheers,
~x