Live data from Hacker News

Everything you need to know about the Shellshock Bash bug

troyhunt.com

11–20 of 296 posts

Re: Everything you need to know about the Shellshock Bash bug

#11
post #4

So trying to understand the issue here, is this actually a bash thing or a problem with the web server forwarding commands to bash? I don't understand why bash would be listening to network traffic on its own.

Not just web servers, but anything that calls system() or popen() is really calling the system shell, /bin/sh. On many systems, /bin/sh is really bash in sh compatability mode. That means all those perl scripts, CGI scripts, even DHCP clients expose the vulnerability. Ubuntu runs dash as /bin/sh instead, and most BSDs run ash, so they're not as vulnerable.

Edit: also, if you have ssh access to a non-login account, like for git access, this could execute commands on the remote host as if you had a shell.

Re: Everything you need to know about the Shellshock Bash bug

#12
Keep an eye on the patches directory for whatever version you use:

http://ftp.gnu.org/pub/gnu/bash/

Just had to manually patch a CentOS4 legacy system.

What I find interesting is the patch has been around since the 16th, what took so long and what finally lit a fire under the mainstream *nix releases?

Re: Everything you need to know about the Shellshock Bash bug

#13
post #2

From the article: "Of course one means of mitigating this particular attack vector is simply to disable any CGI functionality that makes calls to a shell" If you're on Ubuntu: a2dismod cgi service apache2 restart If you're NOT running any CGI scripts this will disable CGI support in Apache. Not sure if that takes care of things 100%, but might be helpful.

Erm what about mod_php etc?

Re: Everything you need to know about the Shellshock Bash bug

#14

Does anybody has steps what to do really as a sysadmin? Do I only need to install newest bash (on Linux systems) or do I also need to restart daemons like nginx/apache etc. ?

The vulnerability only affects bash when it is parsing environment variables, when it is just starting. So if a process is already running, it's not vulnerable and you don't have to restart it. You should definitely apply the patch from Wednesday, but be aware there is a related vulnerability that has no patch yet.

Add the configuration from this page https://access.redhat.com/solutions/1207723 to your Apache or nginx config to deny malicious HTTP requests.

Re: Everything you need to know about the Shellshock Bash bug

#16
post #13
post #2

From the article: "Of course one means of mitigating this particular attack vector is simply to disable any CGI functionality that makes calls to a shell" If you're on Ubuntu: a2dismod cgi service apache2 restart If you're NOT running any CGI scripts this will disable CGI support in Apache. Not sure if that takes care of things 100%, but might be helpful.

Erm what about mod_php etc?

from my understanding mod_php is not affected. However, if you have any system() calls in your PHP code AND you allow user input to be used in those system calls, then /bin/bash could be executed via the system call. If you control what is running in your system call - i.e.

    system("echo 'hello world'");
then I believe you are OK. But that's "security 101" and you should never be opening a system call to user input.

Re: Everything you need to know about the Shellshock Bash bug

#17
post #12

Keep an eye on the patches directory for whatever version you use: http://ftp.gnu.org/pub/gnu/bash/ Just had to manually patch a CentOS4 legacy system. What I find interesting is the patch has been around since the 16th, what took so long and what finally lit a fire under the mainstream *nix releases?

>CentOS4 legacy system

Jesus. That's been out of support for well over 2 years. I can't imagine this is the only problem it has. I'm curious: what's keeping the organization from upgrading it?

Re: Everything you need to know about the Shellshock Bash bug

#18
There's no way that this bug could affect even a fraction of the number of users Heartbleed did. The number of affected machines is probably 1/10000th that of heartbleed, and heartbleed exposed hundreds of millions of users, the SSL keys of servers, etc to attack. The fact that legacy CGI scripts are the only attack vector being discussed right now is proof enough of how outdated this bug is.

Keep in mind that hackers constantly take advantage of old exploitable legacy software in servers around the world to get a shell, and nobody freaks out about it.

Re: Everything you need to know about the Shellshock Bash bug

#20

Can anyone explain what I should do on OSX? I've heard that replacing /bin/bash with a newer version of bash from homebrew or even zsh will work but is that going to break anything that assumes 3.2 bash??

Are you running an HTTP or SSH server that faces the public? If so you need to update or take mitigation steps ASAP. If not you can wait until apple patches.
Post reply on HN