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

71–80 of 296 posts

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

#71

Post by lambda »

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…

No, you are not OK. Replace "sh" in that command with "bash" and you should still see the issue.

There is a lower likelihood that you'll see the issue, as anything which just uses sh (including the "system" function, and similar ones) will use dash indeed of Bash; but there will still be places where bash is called explicitly, including many shell scripts that depend on bash features, which are vulnerable.

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

#73

Post by peterwwillis »

MichaelGG wrote: post #49
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…

Plenty of stuff uses environment variables and in places one may not think it vulnerable. Reviewing some of our own software, it's unclear, just from documentation, which third-party systems actually pass some environment when shelling or not. "Legacy CGI" might be discussed as a clear-and-easy example but this will impact many, many other systems.

Even if this bug affects every single *NIX server in the world, it still hasn't exposed, for example, CloudFlare's private keys, or your Gmail/Yahoo mail, or the clients (and keys) connected to VPNs around the globe. Heartbleed exposed so much private information, immediately, that it was the biggest private data leak in history, and will remain so for decades.

This bash bug lets you run code, but on a much smaller number of servers, without an immediate impact on the world's most important services, and won't give up things like ssl keys without a local privilege escalation. It's much, much more limited in the scope of the immediate threat. It's still an immediate threat. I'm just saying it is nothing compared to Heartbleed.

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

#74

Post by mmcclellan »

jgrahamc wrote: post #50
mkoryak wrote: post #47

Earlier quoted context omitted.

and if I am not a paying customer, can I enable them manually?

No, the WAF is not included in the free plan.

Still, publishing suggested rulesets or at least sending them over to OWASP would be Good Guy.

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

#76

Post by fennecfoxen »

rainforest wrote: post #5
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.

The latter. Some daemons, like CGI scripts will spawn a shell populated with environment variables from the client. With a vulnerable bash, commands in these get executed.

A little more accurately and pedantically:

All HTTP servers invoking scripts over the Common Gateway Interface (CGI) put user-supplied input into environment variables as part of their invocation process, because that's what the CGI spec says to do. Many other daemons perform similar techniques to communicate with subprocesses that they spawn to do work. And when launching a new process, environment variables are (by default) copied from the parent process.

The CGI script itself is neither a daemon nor responsible for populating the environment (merely for invoking system()). Also, most HTTP servers try to go out of their way to avoid invoking shells and instead invoke CGI scripts directly, saving on overhead.

More broadly, if ANY process puts ANY client-supplied input into environment variables and subsequently that process or a subprocess happens to spawn a copy of bash by calling system(3), then you're in trouble.

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

#77

Post by drzaiusapelord »

spilk wrote: post #27

I've seen a lot of talk regarding the impact on embedded devices, but how many of these actually run GNU Bash? I can't think of many embedded devices that don't use Busybox instead.

>I can't think of many embedded devices that don't use Busybox instead.

What about all these shitty wireless routers out there? I think in the past they were QNX-based but they've long moved to being linux based. We know popular projects like dd-wrt and pfsense are probably okay (ash instead of bash), but what about the thousands of others? My own router is supplied by AT&T for its u-verse service. God knows what its running. Or all the NAS devices out there and load balancers, etc.

I guess we'll find out when the whitehats are done scanning the entire internet for vulnerable hosts.

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

#78

Post by jgrahamc »

mmcclellan wrote: post #74
jgrahamc wrote: post #50

Earlier quoted context omitted.

No, the WAF is not included in the free plan.

Still, publishing suggested rulesets or at least sending them over to OWASP would be Good Guy.

The RedHat advisory had mod_security rules in it. Our rules are our version of that.

https://access.redhat.com/articles/1200223

    SecRule REQUEST_HEADERS: "^\(\) {" "phase:1,deny,id:1000000,t:urlDecode,status:400,log,msg:'CVE-2014-6271 - Bash Attack'"
    SecRule REQUEST_LINE "\(\) {" "phase:1,deny,id:1000001,status:400,log,msg:'CVE-2014-6271 - Bash Attack'"
    SecRule ARGS_NAMES "^\(\) {" "phase:2,deny,id:1000002,t:urlDecode,t:urlDecodeUni,status:400,log,msg:'CVE-2014-6271 - Bash Attack'"
    SecRule ARGS "^\(\) {" "phase:2,deny,id:1000003,t:urlDecode,t:urlDecodeUni,status:400,log,msg:'CVE-2014-6271 - Bash Attack'"
    SecRule FILES_NAMES "^\(\) {"  "phase:2,deny,id:1000004,t:urlDecode,t:urlDecodeUni,status:400,log,msg:'CVE-2014-6271  - Bash Attack'"

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

#79

Post by drzaiusapelord »

krapp wrote: post #44
weavie wrote: post #26

I bet Microsoft are enjoying the fact that it is Linux that seems to have all the security vulnerabilities these days!

On the one hand, if this had been in Windows, no one in the public would have been able to stumble across it, though you would expect them to be paying rooms full of engineers to make sure that's never necessary (and yet stuff happens.) On the other hand, despite the premise of open source that 'many eyes make all bugs shallow', the amount of code in the wild and the complexity of it (and the diversity of implementat…

Considering most exploits are found via fuzzing tools, I think your assumption is pretty far away from reality.

If people could casually look at code and see vulnerabilities, then we wouldn't have any.

Also: MS Shared Source initiative

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

#80

Post by diydsp »

mrfusion wrote: post #75

I see how Apache passes request information through environment variables but I don't see how bash comes into play in typical CGI. Is anyone up for educating me? I see http request -> apache -> env variables -> php What am I missing?

I think I have the same question.. why is this called a "bash" bug? Is it not a webserver bug? Why does the webserver send data to bash through environment variables? Is there no better way to do it?
Post reply on HN