Message-ID: <40EF3FA5.8581.4B96D548@localhost>
From: nick at virus-l.demon.co.uk (Nick FitzGerald)
Subject: No shell => secure?

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.  ...

For all?

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 
their tack...

> 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 
thing...


Regards,

Nick FitzGerald

Powered by blists - more mailing lists