mailing list archives
Re: No shell => secure?
From: Nick FitzGerald <nick () virus-l demon co uk>
Date: Sat, 10 Jul 2004 01:00:21 +1200
Matthias Benkmann wrote:
I can't say I've looked at much exploit-code so far but the POC exploits
to gain root I've seen for Linux all executed /bin/sh. I'd like to know if
this is true for in-the-wild exploits to root a box, too. ...
I don't know, but I'd be very surprised if it were (and if it it was,
I'm sure that it wouldn't remain thus for much longer).
... If so, would it
be a useful security measure to rename /bin/sh and other shells (after
making sure that everything that needs them has been updated to the new
name, of course)?
Well, that may be (short-term) effective, but if much of the "low
hanging fruit" were removed through widespread adoption of that
approach, I suspect that you'd see the (smarter) exploiters change
I'm aware that a dedicated attacker who targets my box specifically will
not be stopped by this but I don't think I have such enemies. I also know
that DOS is still possible, but that's also not my concern. I'm simply
worried about script kiddies using standard exploits against random
servers on the Internet rooting my box faster than I can patch it.
You may well beat them with such an approach, though at what cost of
other increased complexity of system admin? A great deal of common
sysadmin (and end-use) practice is based on an assumption of standard
path locations and executable names.
If renaming the shell is not enough, how about renaming all of the
standard Unix top-level directories (such as /bin, /etc,...)? Would that
defeat standard exploits to root a box?
Note that although it is common to refer to the "shellcode" part of a
buffer overflow and other remote network service exploits, in reality
the purpose of that code is probably better thought of as the "payload"
of the overflow (or other exploit method). More generally, it is the
code that is run with the elevated privileges, etc obtained by
exploiting the vulnerability. Historically this has tended to be code
to get a local shell on the exploited machine to connect back to a port
listening on the "attacking" machine (or some other machine of the
attackers choice), but it need not be... Because of the common
practice of making the payload a reverse shell, the term "shellcode"
has tended to stick as the accepted terminology, rather than the more
generally correct "exploit payload code". Of course, with the common
architecture and configuration of so many *nix-ish platforms, it has
also become something of an art-form writing "generic" shellcode that
is as small as possible so it can be used in as many (PoC) exploits as
possible. And smaller == better if you are dealing with tight buffer
overflows with only a few dozen bytes of reliable overflow space to
stash your payload, so very tight generic "shellcode" has become a big
Full-Disclosure - We believe in it.