Everything you need to know about the Shellshock Bash bug • Hacker News Board

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

#271

Post by ams6110 » Fri, Sep 26, 2014, 2:37 AM UTC

shangxiao wrote: post #182

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.

And regardless, the cgi script could invoke bash, or invoke something that invokes bash, etc.

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

#272

Post by diltonm » Fri, Sep 26, 2014, 3:20 AM UTC

Don't forget to update any Docker instances of OS's. My brother just challenged me and I'd assumed my Docker Ubuntu instances would be updated automatically by updating the main Ubuntu OS but that was not the case. In my defense I'm still new to Docker.

I also used this to list my containers:

  docker ps -la -n=100

And removed them all, then listed images:

  docker images

And removed them and then ran this to get the latest ubuntu installed from docker:

  docker run -i -t ubuntu /bin/bash

Then when inside the container ran:

  env X="() { :;} ; echo busted" `which bash` -c "echo completed"

The new docker image of ubuntu is still vulnerable.

Edit: Updating the container then committing it (Docker terminology) should ensure that container stays updated, though any new runs creating new containers would continue to be vulnerable I suspect until Docker patches them or whomever would be responsible to do so.

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

#273

Post by wmil » Fri, Sep 26, 2014, 3:30 AM UTC

PeterisP wrote: post #240

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…

Can someone who understands CGI enlighten me why (oh why) everyone treats #4 as the main problem instead of #2 ? I mean, looking at it from an outside perspective, I can interpret #4 as working as intendeed (attacker calls my shell with arbitrary parameters and, naturally, my shell does arbitrary things controlled by the attacker), and #2 as a total WTF - why is apache passing arbitrary input data to global-scoped (a…

It's not setting arbitrary environment variables, it's setting specific ones. Bash is basically calling eval on the list of envvars without re-escaping the values.

The people who wrote the CGI spec didn't expect that to happen at startup.

csh and zsh don't do it, and I can't think of any reason why someone would want that.

CGI was always a kludge, and envvars weren't a great choice, but they were presumed to be safe for arbitrary data.

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

#274

Post by CamperBob2 » Fri, Sep 26, 2014, 3:42 AM UTC

bulatb wrote: post #253

blacksqr wrote: post #193

Earlier quoted context omitted.

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

Those statements aren't correct. A ShellShock exploit has two steps: 1. Attacker somehow gets to set an environment variable. Since CGI converts HTTP headers to env vars (Host: -> HTTP_HOST, etc), a CGI-enabled server is an easy way to make this happen. Step 1 on its own would be alarming but ultimately harmless--the variables may contain malicious values, but they can't be used to hurt you if you treat them as untru…

So every time Bash is launched, for any reason, it spins through all of the environment variables and executes anything it finds as long as it's preceded by a fairly simple pattern?

To me, what seems disturbing isn't the extent of the vulnerability, but how long it took for someone to notice it. How many other "shallow" bugs like this one have been missed by the proverbial many eyes?

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

#275

Post by wmil » Fri, Sep 26, 2014, 3:49 AM UTC

pstrateman wrote: post #259

PeterisP wrote: post #240

Earlier quoted context omitted.

Can someone who understands CGI enlighten me why (oh why) everyone treats #4 as the main problem instead of #2 ? I mean, looking at it from an outside perspective, I can interpret #4 as working as intendeed (attacker calls my shell with arbitrary parameters and, naturally, my shell does arbitrary things controlled by the attacker), and #2 as a total WTF - why is apache passing arbitrary input data to global-scoped (a…

The flaw lies in the combination of 2/3. The HTTP_ environment variables are user input. The PHP (or whatever CGI script) should be sanitizing user input before using it. If this was PHP scripts doing something like this: system("/bin/sh ".$_GET['x']); Nobody would be freaking out... because that's just stupid.

You're missing the point. Look at this code.

  export evil='() { :;}; exit';
  echo $evil

# prints '() { :;}; exit'

  bash

# new bash session immediately exits

Imagine a dev using eval() in PHP. The PHP interpreter creates a new environment, executes your (presumably sanitized) code, but also automatically calls eval on every global variable in your app.

That would be a huge bug in PHP, and it's the equivalent of what bash is doing.

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

#276

Post by mturmon » Fri, Sep 26, 2014, 5:24 AM UTC

diydsp wrote: post #187

diydsp wrote: post #80

Earlier quoted context omitted.

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?

You are correct, you asked an innocent and to-the-point question.

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

#277

Post by Zancarius » Fri, Sep 26, 2014, 6:07 AM UTC

rsync wrote: post #221

idorosen wrote: post #146

For Mac OS X, until Apple releases a software update, I've applied the original CVE-2014-6271 (shellshock) patch and am going to apply the CVE-2014-7169 patch as well once it passes review. Repository and instructions to reproduce without trusting me are located here: https://github.com/ido/macosx-bash-92-shellshock-patched

why not simply chmod 0000 `which bash` ?

The problem is that some utilities rely heavily on bashisms such that they're unlikely to work with dash or other POSIX-compliant sh-replacements. As an Arch user, just off the top of my head, I can think of yaourt (AUR helper) and apparently the shell script for invoking gradle as both reliant on such behavior. The latter may not affect everyone, and after running into just those two samples today, I can only imagine what else may be affected.

The best solution I could think of as a work around is to install dash, replace the /bin/sh symlink pointing to dash, and then chown/chmod bash so that only those specific users who need to use it can use it. This isn't perfect, because it could still be affected by web services that run as users that would then have access to bash via their member group(s), or because a web service might rely on another application that itself requires specific bashisms in order to function.

This is why abandoning correctness for convenience can be dangerous.

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

#278

Post by Zancarius » Fri, Sep 26, 2014, 6:28 AM UTC

muyuu wrote: post #200

jewel wrote: post #169

Earlier quoted context omitted.

Of course, but what's the exploit vector in that case?

That the users created for Apache, database daemons, etc, default to bash for cgi.

The passwd file contains the login shell configured for that user. Operating in the context of a daemon for most sane applications, this configuration doesn't (or shouldn't?) matter unless the user logs in. [1]

For Apache, I believe /bin/sh (or the shell it points to) is what's at issue here. [2]

[1] http://unix.stackexchange.com/questions/38175/difference-bet...

[2] http://security.stackexchange.com/questions/68146/how-do-i-s...

(This is also discussed earlier in the thread.)

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

#279

Post by sjy » Fri, Sep 26, 2014, 6:31 AM UTC

rsync wrote: post #221

idorosen wrote: post #146

For Mac OS X, until Apple releases a software update, I've applied the original CVE-2014-6271 (shellshock) patch and am going to apply the CVE-2014-7169 patch as well once it passes review. Repository and instructions to reproduce without trusting me are located here: https://github.com/ido/macosx-bash-92-shellshock-patched

why not simply chmod 0000 `which bash` ?

This isn't really enough because /bin/sh is also a copy of bash (not a symlink).

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

#280

Post by blacksqr » Fri, Sep 26, 2014, 7:21 AM UTC

bulatb wrote: post #253

blacksqr wrote: post #193

Earlier quoted context omitted.

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

Those statements aren't correct. A ShellShock exploit has two steps: 1. Attacker somehow gets to set an environment variable. Since CGI converts HTTP headers to env vars (Host: -> HTTP_HOST, etc), a CGI-enabled server is an easy way to make this happen. Step 1 on its own would be alarming but ultimately harmless--the variables may contain malicious values, but they can't be used to hurt you if you treat them as untru…

Statement #2 is the simple expression of the issue that's necessary for understanding it, notably missing or obfuscated in all the other massive verbiage on the topic today.

Thank you, gentle responder.