http://jaxbot.me/articles/cases-where-bash-shellshock-is-saf...
Nginx + fpm not vulnerable?
Everything you need to know about the Shellshock Bash bug
191–200 of 296 posts
Re: Everything you need to know about the Shellshock Bash bug
#192Read 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 don't quite get it yet. Let's suppose someone sends a header like this: 'User-Agent:() { :; }; touch /tmp/shellshocked'
Then in my cgi script I do a harmless system('date') call. The file /tmp/shellshocked won't be created right? The file would have been created had I done for example a system('echo $HTTP_USER_AGENT') call. (That is, one needs to explicitly reference the environment variable that gets passed to bash). Is my understanding correct?
Re: Everything you need to know about the Shellshock Bash bug
#193So 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…
> why would a CGI implementation use the shell to set environment variables?
This is exactly my question; that, and: if this is so, then isn't any script that uses mod_cgi (e.g., PHP, Perl, etc.) vulnerable? Yet there are multiple statements that only cgi scripts written in bash are vulnerable.
I haven't been able to resolve this apparent inconsistency in the description of how the bug works in the case of CGI, which may be a critical factor in understanding ones own vulnerability. What exactly is the order of execution here in the case of mod_cgi?
Re: Everything you need to know about the Shellshock Bash bug
#194Unless 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.)
It may be possible to exploit the bug for "good" reasons like patching the bug, but the patches that are out now don't seem to properly plug the exploit, and as with any update there are plenty of considerations that could end up bricking the application.
Aside from the "it's not yours to fix" angle, you have to weigh the moral benefits of possibly patching the exploit, possibly crashing the application (I bet this is much more likely than a successful fix at this point), and wait-and-seeing whether the application owner patches the exploit on their own (along with the risk of a compromise in the mean time).
Edit: Of course there are a slew of legal issues with attempting this as well.
Re: Everything you need to know about the Shellshock Bash bug
#195Folks, for what it's worth, here is a management briefing I wrote this morning. Please feel free to re-use, but please do give proper attribution. Please do comment and correct as appropriate. Summary: Briefing for management on activities to minimize impacts of the "shellshock" computer vulnerability. Status: Testing underway. Initial appraisals are that public-facing systems are likely not subject to shellshock. NO…
> Initial appraisals are that public-facing systems are likely not subject to shellshock. All the managers I know will stop reading after this, sit back and think "aaah, those silly techies. Worrying about nothing". I gave exactly the opposite advice: We should assume every public and non-public facing system is vulnerable (many were). I'd rather cause a big stinky scare and be proven wrong than downplaying the issue…
Yes, I did have a good reason: Our initial tests indicate that the organization is not vulnerable.
To be fair to you and to me, I can understand your take on what I posted but what I posted was redacted to remove organization-identifying information. A better redaction would perhaps have been Our initial scans and appraisals are that our public-facing systems are likely not subject to shellshock.
Re: Everything you need to know about the Shellshock Bash bug
#196I bet Microsoft are enjoying the fact that it is Linux that seems to have all the security vulnerabilities these days!
Heh, yeah- those two major failures certainly overshadow the hundreds of issues Win has. :)
I was under the impression that windows server is pretty stable/secure these days.
Re: Everything you need to know about the Shellshock Bash bug
#197Earlier quoted context omitted.
I must not be understanding how this works then - how would /bin/bash be executed from a PHP system() call unless it was called directly from the command? And if you don't allow user input into the system call, how is /bin/bash going to be inserted into it? Thanks!
system() calls /bin/sh for you. If /bin/sh is linked to /bin/bash (a common thing), then it's exploitable. Under the hood, system("echo foo") does a fork, and in the child process does execv(["/bin/sh", "-c", "echo", "foo"], env...)
Yeah I get that - but surely just _calling_ /bin/bash isn't enough - you have to be able to pass in the arguments to bash that enable this exploit. And if you're not allowing user input into your system call, I still think this is a non issue in this scenario.
Re: Everything you need to know about the Shellshock Bash bug
#198Read 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…
Thanks. I'm still confused though:
1: Why does Bash "interpret" the environment variables' values? What is the expected result of setting a function definition as the value of an environment variable? In my worldview (which is clearly wrong) there is no reason for Bash to look at environment variables' values until they're evaluated.
2: This is probably besides the point: but since when is the empty string a valid function name? I can't get Bash to accept "() { :; }" (as opposed to "f() { :; }" as valid bash.
Edit: see my self-reply for answers.
Re: Everything you need to know about the Shellshock Bash bug
#199Read 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 don't quite get it yet. Let's suppose someone sends a header like this: 'User-Agent:() { :; }; touch /tmp/shellshocked' Then in my cgi script I do a harmless system('date') call. The file /tmp/shellshocked won't be created right? The file would have been created had I done for example a system('echo $HTTP_USER_AGENT') call. (That is, one needs to explicitly reference the environment variable that gets passed to bas…
No, bash interprets as functions ALL environment variables that begin with '() {' on startup. If you have an unpatched bash it will also excute any trailing commands after the function definition. You don't need to manually reference any environment variables at all to be vulnerable. This is to how the bash feature of exporting functions to subshells ("export -f") works.