> >> 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/