Re: Basic security question about buffer overflows

[Peter Varga <peter_(_dot_)_varga_(_at_)_screaminet_(_dot_)_com>]

Dr. Evil, see inline.

On Thu, Feb 07, 2002 at 05:42:56PM -0700, Tobias Weingartner wrote:
> On Thursday, February 7, "Dr. Evil" wrote:
> > 
> > Another solution is to do what OpenBSD does, which is to exhuastively
> > verify the correctness of the code.  With an experienced and dedicated
> > team (such as the OpenBSD team) this works well.
> 
> Ultimately, this is the only way.
> 
> 
> > Here's my question: Would it be possible to design a CPU in such a way
> > that areas of memory (pages, I guess) can be labeled in different
> > ways, much like files can.  These labels would include "execute only,
> > read only", "data only, never execute", and they could also have other
> > restrictions such as "user level process only" or other things such as
> > MAC information.
> 
> Nope.  Every one of these has been circumvented at some point.
> 
> 
> > With a ssytem like that, what would happen when a process is executed
> > by the kernel is this: The kernel loads the executable binary into
> > ram, marks it "executable, read-only", and then transfers control to
> > that process.  When the process is executing, and it requets more
> > memory from the kernel, the kernel would label this extra memory "data
> > only, no execution".
> 
> Well, for starters this would make dynamic linking somewhat difficult
> for certain architectures/file-formats.  Not all of them, just some of
> them.
> 
> Also, what is to prevent you from overwriting the stack frame and jumping
> to a location in the existing code that does what you wish?  Whats to
> prevent you from overwriting a buffer that nukes some integer, that does
> a range-check of some packet, etc, etc.  It may just crash the program in
> the end, but that is usually enough to be an annoyance.
> 
> 
> The only correct way is correct code.  There is no substitute.

  ^--------^
   Agreed.

> 
> --Toby.