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

From: xenophi1e <oliver.lavery(at)sympatico.ca>
Date: Fri May 16 2003 - 12:46:57 EDT

('binary' encoding is not supported, stored as-is)
In-Reply-To: <75C025AE395F374B81F6416B1D4BDEFB01009380@mtv-corpmail.microfocus.com>

>AS/400, where C programs in essence run under a virtual machine, and most

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
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 Received on Fri May 16 18:54:47 2003