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

171–180 of 296 posts

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

#171

Post by zorbo »

sequoia wrote: post #138

Read a bit about this because I didn't understand CGI. tl;dr version of what's going on here, if I'm not mistaken (assuming apache/php for this example): 1. Web server (apache) gets request to route to CGI script (PHP) 2. Per the CGI spec, apache passes the request body to PHP as stdin & sets the HTTP headers as environment variables , so PHP can access them 3. In the PHP script, `exec`/`passthru`/`shell_exec` etc. i…

As far as I can see, this is largely correct. But do realize:

- that environments are inherited by child processes. - It's not just Web servers that might execute scripts (DHCP could also be vulnerable, SSH with command restrictions, many other things too).

That's the big shitstorm about this bug. It's very hard to determine when you're actually vulnerable. The safest thing to do is to upgrade bash everywhere. But wait! The patches they rolled out don't actually fix the issue all that well. So there's no easy one-stop guide you can follow to fix this. Everybody actually has to think about every single system that might potentially be vulnerable and come up with a good solution all by themselves.

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

#172

Post by earlz »

fiedzia wrote: post #92
earlz wrote: post #72

Has anyone constructed this exploit as a simple `wget` command?

wget --header='Referer: () { :;}; touch /tmp/vulnerable ' www.example.com

Is there some easy way of detecting a site you don't control is vulnerable without bringing it down?

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

#174

Post by nostrademons »

sillysaurus3 wrote: post #93
jgrahamc wrote: post #84

Earlier quoted context omitted.

It's less about trying to monetize it than about the cost to us of suddenly inspecting every request that goes through us. We service a huge volume of traffic and part of our core value is performance so keeping our processing latency is low as possible is important. (Note: I removed sentence about CloudFlare pricing from previous comment to avoid any confusion about monetization)

Would it be possible to enable it temporarily to see whether the change significantly impacts your processing latency?

Or do so on a small percentage of free traffic and see how much CPU headroom you still have left.

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

#175

Post by shangxiao »

informatimago wrote: post #170
fiedzia wrote: post #54

Earlier quoted context omitted.

Out of curiosty: did it cause any problems with intended use of this shell feature? Did anyone complained that it broke something that worked before?

There is no intended use, it's a pure evil bug in bash. I wouldn't be surprised if it was discovered that it has been implanted intentionnally.

How can a bug be evil? Don't attach morals to things which should be amoral.

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

#176

Post by bjornsing »

tokenizerrr wrote: post #112
mrfusion wrote: post #99

Earlier quoted context omitted.

Sort of I guess, but why does bash need to loop over all of the env variables and execute them? I don't think CGI had any reason to think that would ever happen? (I guess that's basically what it's doing?)

Bash is a shell, part of it's purpose is to deal with enviroment variables. The bug here is that the parser is getting confused, the feature being abused here is being able to declare functions as part of an enviroment variable, which is used to transfer functions to subshells in bash. Now this itself is fine, but since the parser gets confused it also executes commands after the function definition.

I honestly can't see why this is "fine"... I understand it's not the security critical bug, but feeding all environment variables into some sort of interpreter...?!?

Ok, bash needs to transfer function definitions to child processes in order to implement something called inherited functions, and I guess you could argue that an environment variable is a reasonable place to store them. But WHY THE HELL does bash have to use the function name as the variable name?!? That's just insane to me...

Any sane programmer would store that shit in an environment variable with a known name (e.g. "BASH_INHERITED_FUNCTIONS"). Why doesn't bash do that?!?

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

#177

Post by shangxiao »

TorKlingberg wrote: post #134
fiedzia wrote: post #54

Earlier quoted context omitted.

Out of curiosty: did it cause any problems with intended use of this shell feature? Did anyone complained that it broke something that worked before?

I assume Cloudflare are filtering HTTP headers. I cannot imagine a valid reason to pass in functions to bash in headers.

And functions with malicious shell script appended at that! ;)

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

#178

Post by dkarl »

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.

That was my first question as well. The behavior sounds like exactly the kind of magical weirdness you get with shells. Your question is asked and answered here: https://stackoverflow.com/questions/26022248/is-the-behavior... The answer given there is that the behavior is NOT a documented feature; it's a side-effect of how bash implements inherited functions.

I was also very confused about why a web server would need to store HTTP headers in environment variables. Why would a mature piece of software like Apache do something so hackish? The explanation turns out to be very simple: it's how CGI works. Headers are passed to the CGI script as environment variables. If you don't do it that way, you don't support CGI.

There's one thing that still confuses me, though: why would a CGI implementation use the shell to set environment variables? Why would you use a complex, idiosyncratic piece of software that comes in many different flavors instead of just using the C setenv function?

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

#179

Post by nkurz »

earlz wrote: post #172
fiedzia wrote: post #92

Earlier quoted context omitted.

wget --header='Referer: () { :;}; touch /tmp/vulnerable ' www.example.com

Is there some easy way of detecting a site you don't control is vulnerable without bringing it down?

Yes, you can ask it to ping an address you control and record where the pings come from.

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

#180

Post by IshKebab »

sequoia wrote: post #138

Read a bit about this because I didn't understand CGI. tl;dr version of what's going on here, if I'm not mistaken (assuming apache/php for this example): 1. Web server (apache) gets request to route to CGI script (PHP) 2. Per the CGI spec, apache passes the request body to PHP as stdin & sets the HTTP headers as environment variables , so PHP can access them 3. In the PHP script, `exec`/`passthru`/`shell_exec` etc. i…

I have no sympathy really for people who use `system()`-style calls, or bash in their web servers. Bash is fairly obviously designed with complete disregard for security. I seriously doubt this is its last major flaw.

But anyway, is it really that common? I would have thought most CGI scripts are Python, Perl, PHP, etc. and don't use `system()` type calls. Right?

Post reply on HN