Messages in this thread | | | Date | Wed, 3 Mar 1999 21:45:57 +0000 (GMT) | From | Matthew Kirkwood <> | Subject | Re: Linux Buffer Overflow Security Exploits |
| |
On Wed, 3 Mar 1999, Sarah Addams wrote:
> >> Excuse my ignorance, but would someone explain to me why Linux and other > >> Unices are vulnerable to buffer overflow exploits? I suspect it's = > > >Because like basically all computers you don't have hardware type and > >size tags on all pointers. There are approaches to reduce the probability > >of that error but reading and checking code is the most productive. Logic > >errors tend to be as big a problem > > Isn't it the case for Intel 386 and up processors, as is true for other > modern processors, that memory segments can be marked execute, read > and/or write by a process running at a sufficiently high privilege > level. So if you write your kernel to take advantage of these features, > you could guard against the case where a buffer overflow is used to > sneak code into an otherwise secure system?
Sort of. There are a few reasons why this isn't generally done: 1. Multi-segment stuff complicates the kernel and introduces some portability issues 2. Protection can be set on a per-page basis anyway 3. It doesn't close holes - search your local bugtraq archive for "return into libc". Basically instead of overflowing with code, you send a stack frame for your favourite library (or program) function and return into that instead 4. It does break some existing binaries.
> I suppose my original question could be boiled down into: > > Does a Linux (and/or other Unix) process inhabit a single read/write/execute > memory segment?
Linux does, and I think most other Unices do too.
Matthew.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |