> 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
Received on Jan 07 2004
Intro
