Vulnerability Development mailing list archives

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


From: security <security () kalamiteit nl>
Date: Wed, 07 Jan 2004 17:21:30 +0100

Hi,
well actually most exploits are calling /bin/sh .. but anyways .. you cannot escape that by removing bash or anything like that .. you "GOTTA" have a /bin/sh as there are so many programs that need that .. what you can do is to add the shells and users that have access to them to a special group! and restrict access to those users!
cheers,
Amine


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




Current thread: