Readers of this thread might want to hop over to VULN-DEV where I've been
actually trying to impliment various non-exec-stack smashing techniques
with the help of a few readers there. Pretty much what Michael writes is
correct, its not too hard to get around non-exec-stack protection and it
looks like even with the way Solar Designer's patch moves libc to an
address with a zero you can still jump to mapped dynamic library calls to
do what you need. So, on x86 he's entirely correct. On Alpha its not so
simple and its definitely not so simple that you can
write-once-run-anywhere an exploit. Also, for a binary that doesn't use
the system() call, you can't use it either and you're stuck doing
something like a strcpy() of shellcode to someplace executable and running
it there.
I'm definitely wishing that they'd release the StackGuard port to egcs
pretty soon. That isn't a silver bullet, but it does appear that for
vanilla buffer overflow coding mistakes it will protect you.
On Tue, 18 Apr 2000, Michael H. Warfield wrote:
> On Tue, Apr 18, 2000 at 05:38:37AM -0700, Linda Walsh wrote:
>
> > -- Vandoorselaere Yoann wrote:
> > > Agree,
> > > but executable stack will, *in all case* give a false sence of security.
> > ---
> > Just had to comment on this "false sense" stuff. Anything that
> > makes it more difficult for someone to break in "raises" security. There
> > isn't a binary value of security where a system goes from "unsecure" to
> > "secure". It is a continuum of increasing security. Having a non
> > executable stack is like hiding the shadow file. The don't make your
> > system secure, but both make it more difficult for certain types of
> > hacks to occur. Like cryptography -- it's not 100% secure -- it just
> > delays an attacker (hopefully for long enough that it's not worth it to
> > the attacker). But given the possibilities of quantum computers, today's
> > key's will seem like yesturday's 32-bit keys. Nano-computers w/more power
> > than today's fastest. Hello Borg, here we come. We better hope we have
> > alot more security on the internet before then...:-)
> > -l
>
> I use to be in the same school of though on this vis-a-vis
> the non-executable stack and then saw one example that changed my mind
> forever. It's basically a proof that for each and every executable
> stack exploit, there must be at least one non-executable stack exploit
> that is as easy or easier to impliment (no assembly required :-) ) than
> the executable stack exploit. All it requires is two addresses and a
> string for the payload of the exploit. The addresses are the address
> to access the system call and the address of the string and would be
> platform, application, and implimentation specific. Here is the string:
>
> echo "2222 stream tcp nowait root /bin/sh sh -i">> /tmp/h;/usr/sbin/inetd /tmp/h
>
> Smash the stack so the function returns back into the system()
> function with the parameter pointing at that string and it's game over.
> The attacker now can have as many shells on your system that he wants
> and you didn't execute a single byte of code on the stack.
>
> I use to think that making the stack non-executable would at
> least make it tougher. The existance of such a simple payload requiring
> no assembly language work at all, points out just what a lie that idea is.
> Sad to say but non-executable stacks are no help at all.
>
> > --
> > Linda A Walsh | Trust Technology, Core Linux, SGI
> > law@sgi.com | Voice: (650) 933-5338
>
> Mike
> --
> Michael H. Warfield | (770) 985-6132 | mhw@WittsEnd.com
> (The Mad Wizard) | (770) 331-2437 | http://www.wittsend.com/mhw/
> NIC whois: MHW9 | An optimist believes we live in the best of all
> PGP Key: 0xDF1DD471 | possible worlds. A pessimist is sure of it!
>
>
> -
> 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/
>
-
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/
This archive was generated by hypermail 2b29 : Sun Apr 23 2000 - 21:00:18 EST