[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Basic security question about buffer overflows
- To: misc_(_at_)_openbsd_(_dot_)_org
- Subject: Re: Basic security question about buffer overflows
- From: Peter Varga <peter_(_dot_)_varga_(_at_)_screaminet_(_dot_)_com>
- Date: Thu, 7 Feb 2002 22:04:30 -0500
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
> 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.