On Tue, Apr 18, 2000 at 08:15:17AM -0700, Linda Walsh wrote:
> "Michael H. Warfield" wrote:
> > 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.
> ---
> That's where real-time audit monitoring and response come in.
> The log monitor sees UID=root, LUID=daemon, 'exec'ing any programs not
> on an 'allowed' list and it can shut down the port/process immediately --
> The list of programs spawned by a system daemon and UID=root is or can be a
> fairly small list. Programs like inetd shouldn't be writing to any file
> directly AFAIK. Suppose you hack in through sendmail (assuming you still
> run it as root) -- you can be alarmed about any files written outside
> of /var/mail or a user's directory. I still think all of these things
> provide increasing layers of difficulty.
Hmmm... Afraid you seemed to have missed several points.
One, look closely at that string. Inetd does not write to any
file. Echo writes to the file and creates a configuration file for inetd.
It then execs inetd specifying that as a configuration file.
Two, this doesn't have to be run as root. Run it as a plain user
(or even a user without a shell) and you can get in as that user. From
there you can worry about elevation of priviledge attacks. This just
establishes a backdoor from which the real dirty work can proceed.
Three, other layers of defense are important in any case. This was
just an example of why the non-executable stack option is no defense under
any circumstance, since simpler, easier, exploits are always available
which do not require it.
Four, the string is just an example. Pick any string you like.
Run the command to mail you the password file if you wish. The point
here is that you can ALWAYS execute a command without recourse to
executing code on the stack under ANY circumstance where you could
execute a command by executing code on the stack. If you don't
like the system call, use another call. The increase in complexity
is insignificant compared to the complexity of the executable stack
exploits, so it's still a win.
Five, the non-executable stack option does not even add a layer
of complexity. If anything, it forces to lamers to use and distribute
exploits that are actually easier to develop and deploy. Instant
backdoor in a can. Why bother with all that assembly language gunk
which takes more work, when all you have to do is know where the data
falls (which you would need for the executable stack even more) and
the entry point to the system call.
I'm not arguing against any other layer than just the non-executable
stack option. Some would argue that it provides less than a defense simply
because it provides a sham or an illusion of a defense when the attackers
really know better. I'm not sure I totally agree with that position, but
I do know, now, that it offers zero protection. It closes no holes and
provides no increased difficulty in exploit creation or deployment. None.
Zero. Worthless.
> --
> 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/
This archive was generated by hypermail 2b29 : Sun Apr 23 2000 - 21:00:13 EST