18 Aug
2006
18 Aug
'06
12:51 p.m.
On Fri, 18 Aug 2006, Don wrote:
But, I understand your point. Why can't you put
the stack in
a separate "segment" (intel-speak) and give that segment *only*
read/write attributes (i.e. no execute). This stops hackers
from executing code on the stack. Same could apply to purely
*data* "segments".
This is commonly done, and called W^X (write xor execute). See:
http://en.wikipedia.org/wiki/W%5EX
But, it doesn't prevent someone diddling
(that's a technical
term; it means "screwing with" :> ) the contents of the stack
and thereby effecting a return to some portion of the *text*
space that does their bidding for them. Perhaps returning
to the middle of a multibyte/word instruction sequence that
*coincidentally* does something they want?
Of course, they have access to *your* binaries (if you
are running an O-t-S OS) so they can hunt around for whatever
byte sequence they happen to want.
Still, seems like a longshot. I'd imagine most exploits could
be prevented just by removing the execute ability from segments
that are known NOT to contain code.
Many can be, which is why OpenBSD among others implements it. This is how
they were able to make the "no remote root vulnerabilities in X years"
claim. However, securlty experts have been able to exploit many stack bugs
despite this protection, usually with "return to libc" attacks. There are
many papers out there on how to exploit a W^X protected process, and many
others on additional protections that defeat these attacks. Mostly these
protections rely on randomizing the address space of a running process or
changing the calling convention so stack integrity is verified somehow
before each return.
[I'm intensely interested in this as to how it can
be done
to make applications in consumer devices "hacker hardened"]
There is a ton of work in this area, W^X is just the simplest and most
efficient (and maybe oldest) method. Some people have gone so far as to
statistically profile the pattern of system calls an application makes,
and to kill it if the pattern suddenly changes (this is the least
practical approach I've heard of :-).
Alexey