News for hackers. Stuff that matters.

A comment on CVE-2014-6271: Remote code execution through bash. Parent comment

Re:CVE-2014-6271: Remote code execution through bash by nandhp on Wednesday September 24, 2014 @12:42PM (#8362458)
Because this allows execution of arbitrary commands from any unsantized environment variable.

Web servers pass information about the HTTP client to CGI scripts using environment variables. A CGI script written in bash would be vulnerable to arbitrary command execution if any HTTP header contained the vulnerable string.

    GET / HTTP/1.0
    User-Agent: () { :; }; rm -rf /
Restricted SSH accounts (like the ones used by GitHub) have a setting to restrict the user to a specific command (e.g. /usr/local/bin/run-git-only --github-user=octocat). The original command is passed in an environment variable SSH_ORIGINAL_COMMAND. If bash is used anywhere along the way (say, if /usr/local/bin/run-git-only --github-user=octocat is a shell script), then this is a problem:

    ssh [email protected] '() { :; }; rm -rf /'
There are surely lots of other ways to get servers to run bash shells with arbitrary environment variables. That's why this is bad.

Edit: as others have pointed out, even non-bash CGI scripts that use a shell to run external processes are vulnerable For example, system("/usr/local/bin/whatever --some-fixed-option") would normally be considered safe since there's no untrusted data in the command-line (although perhaps it would be considered poor design), but it'll run a shell to do the whitespace splitting. If that shell is bash....

[ Parent | on HN ]
Re:CVE-2014-6271: Remote code execution through bash by nisa on Wednesday September 24, 2014 @03:32PM (#8363594)
Is this also dangerous to common FastCGI-Wrappers? E.g. this is used by Virtualmin:

    #!/bin/bash
    PHPRC=$PWD/../etc/php5
    export PHPRC
    umask 022
    export PHP_FCGI_CHILDREN
    PHP_FCGI_MAX_REQUESTS=99999
    export PHP_FCGI_MAX_REQUESTS
    SCRIPT_FILENAME=$PATH_TRANSLATED
    export SCRIPT_FILENAME
    exec /usr/bin/php5-cgi
At least SCRIPT_FILENAME is user input isn't it? I'm really not sure but like to have some clarity. It should not work because it's likely impossible to have () at the beginning of the SCRIPT_FILENAME? but can someone give some hints? It's common to have bash/sh wrapper script: https://httpd.apache.org/mod_fcgid/mod/mod_fcgid.html#exampl...
[ Parent | on HN ]
Re:CVE-2014-6271: Remote code execution through bash by akavel on Wednesday September 24, 2014 @05:25PM (#8364227)
IIUC, you're already pwned after the first line of your wrapper script, i.e. #!/bin/bash, as your CGI environment was already set before, and now you're running bash in it (unless FastCGI works differently, not by setting the environment as plain old CGI; I don't know FastCGI, but from a quick glance I think it works similarly)
[ Parent | on HN ]
Re:CVE-2014-6271: Remote code execution through bash by acdha on Wednesday September 24, 2014 @07:02PM (#8364651)
FastCGI does work differently – it spawns a process which stays open and communicates with it over stdin / stdout – but that doesn't mean that his PHP script doesn't unexpectedly invoke system() somewhere.
[ Parent | on HN ]
Re:CVE-2014-6271: Remote code execution through bash by nisa on Wednesday September 24, 2014 @07:08PM (#8364667)
This script here is run when the process is spawned and spawns the PHP process that listens to stdin/stdout. Similar scripts exist in most install of mod_fcgid. E.g. PLESK, Virtualmin, other ISP-Panels... It boils down to look at what environment variables are there when bash runs this script or not? Once bash starts and grabs the environment variables the exploit starts.

So considering there are other variables in there that can be manipulated it would be possible to own a large chunk of servers on the Internet. However I'm not sure if there is caveat and I had hoped that someone can help me.

Edit: Looks safe. These variables are not even there. It's just an outdated script.

[ Parent | on HN ]
Re:CVE-2014-6271: Remote code execution through bash by navbaker on Wednesday September 24, 2014 @06:53PM (#8364616)
I'm a relative newcomer to the command line and have been Googling around for what exactly the () {:;} is doing with no luck. Does anyone have a good link or explanation?
[ Parent | on HN ]
Re:CVE-2014-6271: Remote code execution through bash by fragmede on Wednesday September 24, 2014 @07:24PM (#8364713)
() makes a function { is the function body : is an ancient 'command' that does nothing ; is says run the : command } closes the function body.
[ Parent | on HN ]
Re:CVE-2014-6271: Remote code execution through bash by navbaker on Thursday September 25, 2014 @01:10PM (#8368246)
Got it, thanks!
[ Parent | on HN ]
Re:CVE-2014-6271: Remote code execution through bash by antocv on Wednesday September 24, 2014 @05:36PM (#8364280)
Who the hell writes CGI scripts in 2014?

There is a reason PHP is to be kept away and not touched with a ten meter stick, it seems to spawn a shell for weird reasons, I dont think python or groovy apps do that. They're safe, unless you somewhere specifically invoke System.getRuntime().run("bash");

[ Parent | on HN ]
Re:CVE-2014-6271: Remote code execution through bash by smsm42 on Wednesday September 24, 2014 @08:00PM (#8364829)
PHP never "spawns shell for weird reasons" - it would spawn shell if you ask it to spawn shell. Just as any other language would, if you ask it. Still, many apps may use shell indirectly - e.g. to execute some system function, to call out to some tool, etc. - and those may be vulnerable even if original code was not CGI script. Moreover, you don't have to run specifically bash - any command execution may go through shell, which may be bash, e.g. Runtime.getRuntime().exec() in Java. Thus it may be not very easy to pinpoint all the places where this bug could sneak in.
[ Parent | on HN ]
Re:CVE-2014-6271: Remote code execution through bash by vorg on Thursday September 25, 2014 @01:47AM (#8365812)
> groovy apps do that [... if] you somewhere specifically invoke System.getRuntime().run("bash");

That's a one-liner in Groovy, written in the Java style of chained method calls, which is the direct equivalent of spawning a shell in non-JVM languages, so that's not an argument for using Groovy instead of PHP.

[ Parent | on HN ]
Re:CVE-2014-6271: Remote code execution through bash by isivaxa on Wednesday September 24, 2014 @01:52PM (#8362948)
"A CGI script written in bash"

You're killin' me here. If you expose a shell script directly to the network, you're exposing a shell and deserve to be pwned.

[ Parent | on HN ]
Re:CVE-2014-6271: Remote code execution through bash by defen on Wednesday September 24, 2014 @02:26PM (#8363186)
If bash is invoked at any point in the response cycle you are pwned; not just if you are directly exposing a shell script. How confident are you that this never happens on any computers anywhere on your network ever?
[ Parent | on HN ]
Re:CVE-2014-6271: Remote code execution through bash by mmastrac on Wednesday September 24, 2014 @02:47PM (#8363328)
That's ridiculous. You may as well say that every time you put a python script up, you're exposing the entire Python runtime and deserve to get 'pwned'.

The scope of the risk is limited to script that you write, whether bash or Python.

[ Parent | on HN ]
Re:CVE-2014-6271: Remote code execution through bash by Nitramp on Wednesday September 24, 2014 @04:23PM (#8363909)
To be fair, with all the various ways how shell scripts (not only in bash) interpolate, evaluate, substitute etc., the typical shell language is much, much harder to keep safe against code injection than say Python (or even PHP). After all, code injection/evaluation is actually what you want in a shell script, half of the time.
[ Parent | on HN ]