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

[Kenneth Peiruza <kenneth () gnunetworks com>]

Isn't it easier to avoid executing code at stack?

Trusted-HP-UX, Trustix and some other systems do it that way.

Far safe that blocking some files 'cause  you'll ever use another way to
enter:
        An exploit might be able to add a new user with a known pass and
therefore log in.

Regards!


On Wed, 2004-01-07 at 13:39, Alex Schütz wrote:
> Dear Vuln-Dev's,
>
> 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.
>
> However, if we do not have any shell, what is going to happen ? There's no 
> /bin/bash to call, thus, the exploit will surely crash some application, 
> but its final goal will be thwarted.
>
> Ofcourse we could rename /bin/bash to /bin/whatever_we_want, and thus add 
> some security by obscurity, but the next exploit is going to cat 
> /etc/shells or /etc/passwd, and then the attacker knows the name of the shell.
>
> Anyhow, if we delete all shells... how safe are we, then ? (Ignoring the 
> case that crontab might not work anymore...)
>
> 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.
>
> 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 .
>
> What do you think ? Please let me know.
>
> Yours, Alex
-- 
Regards,

Kenneth Peiruza
Systems Engineer
+34-666.23.64.33
GNUnetworks Catalunya
http://www.gnunetworks.com