Re: [Full-Disclosure] No shell => secure?
From: Nick FitzGerald (nick_at_virus-l.demon.co.uk)
Date: 07/09/04
- Previous message: Jelmer: "[Full-Disclosure] IE sucks : sun java virtual machine insecure tmp file creation"
- In reply to: Matthias Benkmann: "[Full-Disclosure] No shell => secure?"
- Next in thread: Ron DuFresne: "Re: [Full-Disclosure] No shell => secure?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
To: full-disclosure@lists.netsys.com 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. ...
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
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html
- Previous message: Jelmer: "[Full-Disclosure] IE sucks : sun java virtual machine insecure tmp file creation"
- In reply to: Matthias Benkmann: "[Full-Disclosure] No shell => secure?"
- Next in thread: Ron DuFresne: "Re: [Full-Disclosure] No shell => secure?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
|
