5 ms·
Because this allows execution of arbitrary commands from any unsantized environment variable. Web servers pass information about the HTTP client to CGI scripts
by nandhp 12y ago
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 git@example.com '() { :; }; 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....
- isivaxa 12y ago"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.
- defen 12y agoIf 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?
- mmastrac 12y agoThat'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.
- Nitramp 12y agoTo 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.
- nisa 12y agoIs 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#examples https://httpd.apache.org/mod_fcgid/mod/mod_fcgid.html#exampl...
- akavel 12y agoIIUC, 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)
- acdha 12y agoFastCGI 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.
- nisa 12y agoThis 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.
- antocv 12y agoWho 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");
- smsm42 12y agoPHP 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.
- vorg 12y ago> 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.
- navbaker 12y agoI'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?