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] [thread-next>] [day] [month] [year] [list]

Message-ID: <200407091446.i69EkKH5020947@turing-police.cc.vt.edu>
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks@...edu)
Subject: No shell => secure? 

On Thu, 08 Jul 2004 12:04:53 +0200, Matthias Benkmann <msbREMOVE-THIS@...terdrache.de>  said:
> 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)?

The problem is making sure that *everything* has been updated, and stays
updated.

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

It would also defeat standard ways to install patches and so on.  Don't
forget to grep all your shared libraries (hint - how many places doe
glibc look in /etc for stuff?)

Unless it's an embedded system that only needs like 6 binaries to do its
job, you will go nuts trying to maintain it.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 226 bytes
Desc: not available
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20040709/95c4e728/attachment.bin