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

21–30 of 296 posts

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

#21

Post by danso »

In another thread, I saw that this was an easy check to see if your bash was affected:

     env X="() { :;} ; echo busted" /bin/sh -c "echo stuff"
If you get "busted" back, then you're affected...which is what I get with Mac OS X 10.9...however, when I try it on an Ubuntu server (14.x) that hasn't been patched in awhile...I don't get the error...Er, why is that? I thought this pretty much affected every bash since 25 years ago?

(Someone else in this thread mentioned that Ubuntu uses dash...so...all modern Ubuntu servers are OK?)

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

#22

Post by s_kilk »

sp332 wrote: post #11
donatj wrote: 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, 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.

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

#23

Post by Moru »

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?

Usually time and money.

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

#24

Post by nodata »

jamroom wrote: post #16
nodata wrote: post #13

Earlier quoted context omitted.

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.

mod_php is just as vulnerable as running php cgi scripts.

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

#25

Post by spacehunt »

danso wrote: post #21

In another thread, I saw that this was an easy check to see if your bash was affected: env X="() { :;} ; echo busted" /bin/sh -c "echo stuff" If you get "busted" back, then you're affected...which is what I get with Mac OS X 10.9...however, when I try it on an Ubuntu server (14.x) that hasn't been patched in awhile...I don't get the error...Er, why is that? I thought this pretty much affected every bash since 25 year…

Debian-based systems use dash instead of bash for /bin/sh. But if you have scripts that explicitly use bash, you are still at risk.

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

#28

Post by jamroom »

nodata wrote: post #24
jamroom wrote: post #16

Earlier quoted context omitted.

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.

mod_php is just as vulnerable as running php cgi scripts.

in what way?
Post reply on HN