> From: alan@lxorguk.ukuu.org.uk (Alan Cox)
> Date: Tue, 4 Aug 1998 18:36:29 +0100 (BST)
>
> Security patches aren't intended to fix bugs in software. They are a
> recogntion of the fact that nobody has mastered the art of writing highly
> secure software.
>
> The No-Exec Stack Hack does indeed raises the bar to make it harder to
> explict certain kinds of security holes. My only reason for being
> nervous is that it may null developers into a false sense of security,
> thinking that they no longer have to worry about stack overruns because
> the No-Exec Stack Hack will save them. That's a bad assumption, because
> it doesn't make it impossible to carry out these attacks; it just makes
> it harder. (For example, instead of executing on the stack, an attacker
> might be able to force the return address to be inside the libc
> implementation of system(); if he/she can force it to exec a /bin/sh,
> possibly with bogus arguments but enough so that it starts an
> interactive shell, the stack hack won't save you.)
>
> This is not a technical argument, then, but a social one. This doesn't
> mean that we shouldn't put the stack hack into mainline at some point.
> It just means we have to be careful how we market it, and make sure
> developers still worry about stack overruns.
>
> - Ted
I agree with that last comment, we dont want a false sence of security,
but buffer overruns have existed forever and arn't going away soon
(doesn't the compiler warn now of potential overrun contidions? :) )..
There is one solution: Teach computers to program or change all
programming languages so it's VERY hard to create overruns.
There are two 'fixes': 1) With a good capibilities system, the dangers
would be severly limited. 2) With a no exec stack patch it will make it
tougher to exploit the actual weeknesses. Perhaps make the noexec stack
patch drop the user into single user mode when an attack occures, I'd
rather my server go down then be hacked and at least there will still be
some fire under developers to fix overruns.
As for changing the address to someplace in libc, couldn't we relocated
all libs so that they have a null byte in their address?
-
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.altern.org/andrebalsa/doc/lkml-faq.html