full-disclosure - No shell => secure?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

From: seth at tautology.org (Seth Alan Woolley)
Subject: No shell => secure?

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20040712/e48bcdca/attachment.bin