If you're on Ubuntu or Debian your CGI scripts will probably use dash, not bash.

I've just our few Apache 2 systems that are Internet facing. Some of the site configs did have the standard Ubuntu CGI stanzas in them. However, the `/usr/lib/cgi-bin` directories were empty.

All this has made me a bit nervous though. I certainly didn't change the system to use bash instead of dash.

Debian yes, Ubuntu's default is bash. So is Mint's.

On Ubuntu, /bin/sh is a symlink to dash. /bin/sh is what system() will invoke.

It is, however when you create a user its default shell is bash unless otherwise specified.

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.)

Apache uses APR, which is a separate package/set of packages to the webserver proper. Depends on the distro how this works exactly. See for instance https://launchpad.net/ubuntu/precise/+source/apr-util

Unless the distro changes it, APR defines SHELL_PATH as a macro pointing to /bin/sh (note this isn't the homonym env variable, that would be a serious problem if it was since shellshock allows setting env variables by other means that are very public by now).

In a system I have access to, the installation procedure for some servers (not webserver necessarily) includes creating users with a full environment to be able to issue commands for these servers at a higher privilege. At the creation of these users, Ubuntu Server assigned them bash as their shell. I wonder if they're attackable at their public ports, but I haven't bothered trying to find attacking vectors since they were in production and the sysadmin got rid of bash as soon as he could. Not giving much detail here since I assume there will be plenty of compromised servers in the wild right now, including DB servers, proxies, etc.

init scripts will probably run from dash[1]

[1] https://wiki.ubuntu.com/DashAsBinSh

Erm what about mod_php etc?

from my understanding mod_php is not affected. However, if you have any system() calls in your PHP code AND you allow user input to be used in those system calls, then /bin/bash could be executed via the system call. If you control what is running in your system call - i.e.

    system("echo 'hello world'");

then I believe you are OK. But that's "security 101" and you should never be opening a system call to user input.

> AND you allow user input to be used in those system calls

This is not required for exploiting the vulnerability at hand.

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.

If php is being run from mod_cgi, then it is exploitable.

The full chain of the attack:

Request sent to the url, containing headers with '() { :;}; codehere'

Per CGI standard: environment variables are set with the attack code.

PHP is executed directly, with the environment containing the attack.

PHP calls system - the same environment is there, meaning the code is executed if /bin/sh points to bash.

N.B. - If /bin/sh is not bash, but the program executed by system() itself executes a call to system() which points to something explicitly calling a bash ( apply this if recursively), the exploit is triggered.

It's not about passing "arguments" on the command line, its about what the environment variables are. It's not always immediately obvious how the env vars are constructed - everyone points to CGI because it's a well known scenario, but there are plenty of other cases where environment variables are set from user data.

tl; dr - in any situation user input is used in environment variables, simply calling /bin/bash is enough.

Correct - if you are using PHP as a CGI. This does not affect mod_php.

And this of course is a non-issue:

https://news.ycombinator.com/item?id=8369443

right?

Yeah - that would not be an issue for mod_php since it is about DHCP - if you're server gets it's IP from DHCP, then there's a potential issue, but since we're talking about mod_php here (not running PHP as a CGI, just mod_php) then the linked post is not related.

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 issue, it has to mean that processing the header files in Nginx/Apache results in some buffer overflow or for those values to be directly fed to bash.

otherwise the risk is super minimal, so I don't think it's a matter of making system/exec calls on user-supplied data.

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.

I'm sorry, my lack of understanding it was supposed to be apparent in that post, and indeed you clarified that it's actually more the second scenario I hinted at. I was responding to people talking specifically about an underlying language making system calls and that not making said system calls from the language itself would keep you safe.

You're confirming the suspicion that I had. To wit:

"for this to be a 10/10 issue, it has to mean that processing the header files in Nginx/Apache results in some buffer overflow or for those values to be directly fed to bash."

Not a buffer overflow, but if those headers are being fed upwards into bash, that's what we're both talking about.

in what way?

It's really not.