Re: Thwarting /bin/bash, an anti-overflow concept ?

[Josh Bressers <bress () progeny com>]

> Recently I had a simple idea about preventing hack attacks. Most buffer 
> overflows are pretty happy calling /bin/bash as a final means to get an 
> unauthorized root shell.

While this is partially true, there are many other things can be done
without a shell.  Look at nimda or code-red.  Neither of those needed root
shells, and I don't think anyone will question their disruptiveness.

> Anyhow, if we delete all shells... how safe are we, then ? (Ignoring the 
> case that crontab might not work anymore...)

This doesn't really solve much.  Any attacker with a little bit of
knowledge could execute any script interpreter to execute commands (ie
perl, python, ruby, ...), or a wide range of other commands to gain their
"shell" (This assumes they want a shell and don't just have a payload to
drop off).

> Thinking this farther, we are going to force the exploit developer to bring 
> along his own binary code of /bin/bash. This may not be possible in every 
> case, since the buffer overflow cannot hold so much data.

You would be surprised how little code is needed for a very trivial shell.

> Or we could code some kernel module that restricts any permission to call 
> /bin/bash by only a few selected trusted programs, i.e. /bin/login .

This also doesn't solve many problems.  What happens when /bin/login or the
kernel itself has a vulnerability?

Some of these ideas do have merritt, and have been investigated by many in
the past.  You should take a look at the Security-enhanced Linux project to
get some ideas about what others have done and are doing on this front.

-- 
    JB