|
Bugtraq
mailing list archives
Re: [Full-Disclosure] Re: Buffer overflow prevention
From: KF <dotslash () snosoft com>
Date: Thu, 14 Aug 2003 16:51:05 +0000
Hrmm why does this bring HP to mind... oh yeah I remember...
HP-> "... oh you say you found a bunch of overflows... that does not
matter... there is no way you will bypass our non-executable stack.. we
are not going to fix any of them... we are gonna let em fester... our
non-exec stack is Hack proof"
(time elapse... 2 months)
SNO-> "...oh yeah we bypassed your non-exec stack and have successfully
exploited several of those overflows we told you about a few months ago...
bash-2.05a$ id
uid=201(dotslash) gid=15(users) groups=0(system)
bash-2.05a$ ./TRU64_su
# id
uid=0(root) gid=15(users) groups=15(users),0(system)
# sysconfig -q proc executable_stack
proc:
executable_stack = 0
(hrmm your stack REALLY helped out)
HP-> "ok thanks we will procede to sue you now"
-KF
It's been proved many times that non-executable stack adds NO security at
all.
Every single class of vulnerabilities exploitable with executable stack
can be also exploited with non-executable stack.
See for example our article (http://www.phrack.org/show.php?p=56&a=5)
which shows how to bypass a stack protector even with a non-executable
stack.
What we're discussing here is an internal structures and data protecting.
IMHO the ProPolice (http://www.research.ibm.com/trl/projects/security/ssp/),
is the best protection in this kind, even comparing to "two stack"
approach.
Beside that it's an existing, well tested and wide used (for example
OpenBSD uses it by default now).
I see no real reason why the major Linux companies are not using it for
its products.
Best regards,
--
Mariusz Woloszyn
Internet Security Specialist, GTS - Internet Partners
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html
By Date
By Thread
Current thread:
Re: [Full-Disclosure] Re: Buffer overflow prevention KF (Aug 15)
RE: Buffer overflow prevention Brian Glover (Aug 14)
Re: Buffer overflow prevention noir (Aug 14)
Re: Buffer overflow prevention Matt D. Harris (Aug 15)
RE: Buffer overflow prevention Avery Buffington (Aug 15)
|