Full Disclosure mailing list archives
Re: No shell => secure?
From: Seth Alan Woolley <seth () tautology org>
Date: Mon, 12 Jul 2004 10:46:14 -0700
On Thu, Jul 08, 2004 at 12:04:53PM +0200, 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. 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)? 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. 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?
Matthias, nice to see you. We're using a slight fork of your
simpleinit-msb fork for our init system at Source Mage, but anyways, to
the point:
I'd rather see the real /bin/sh be an 'ACL-enforcing' wrapper around the
real /bin/sh that say checks $PWD and $0 for sanity, like not being in
/tmp and /home. Not as big a hammer as mount -o remount,noexec /tmp but
probably as effective as what you want -- something to buy you some
time. I'd find your sledgehammer approach of deleting the whole thing
kind of pointless -- what you really want is a way to whitelist
acceptable invokers from unacceptables. The attempt to find the correct
way to invoke it should buy you the time you need. Something with 100% bash
builtins that invokes using the exec builtin should work well in most cases.
cp /bin/sh /bin/sh-4d3T5 # it might be a symlink to bash as well.
cat > /bin/sh <<EOF
#!/bin/bash
# do some stuff here with bash builtins as you wish
INVNAME="$PWD$0"
[ "\$INVNAME" != "\${INVNAME#/tmp}" ] &&
echo "sh: unauthorized access from /tmp" > /dev/stderr && return 1
# get around the above with . and .. in the dir ;)
exec /bin/sh-4d3T5 "\$@"
EOF
or just modify /bin/sh directly with a patch that enforces some of these
things for higher performance.
You'd have to be really sophisticated to make sure the logic is good,
but I imagine this method to be a lot easier than, say, your
sledgehammer.
You could even check to see if it's invoked as non-root so that all your
non-root services are better off, but then again, I chroot _everything_
and there's no /bin/sh in those chroots.
Seth
--
Seth Alan Woolley [seth at positivism.org], SPAM/UCE is unauthorized
Key id EF10E21A = 36AD 8A92 8499 8439 E6A8 3724 D437 AF5D EF10 E21A
http://smgl.positivism.org:11371/pks/lookup?op=get&search=0xEF10E21A
Security Team Leader Source Mage GNU/Linux http://www.sourcemage.org
Attachment:
_bin
Description:
Current thread:
- Re: No shell => secure?, (continued)
- Re: No shell => secure? Nick FitzGerald (Jul 09)
- Re: No shell => secure? Ron DuFresne (Jul 09)
- Re: No shell => secure? Valdis . Kletnieks (Jul 09)
- Re: No shell => secure? Matthias Benkmann (Jul 09)
- Re: No shell => secure? Valdis . Kletnieks (Jul 09)
- Re: No shell => secure? hax (Jul 09)
- Re: No shell => secure? st3ng4h (Jul 09)
- Re: No shell => secure? hax (Jul 09)
- Re: No shell => secure? Matthias Benkmann (Jul 09)
- Re: No shell => secure? Kurt Seifried (Jul 09)
- Re: No shell => secure? Seth Alan Woolley (Jul 12)
- Re: No shell => secure? Wall, Kevin (Jul 09)
- Re: No shell => secure? Martin Fallon (Jul 09)
- RE: No shell => secure? Deckard, Jason (Jul 09)
- Re: No shell => secure? John Creegan (Jul 12)
