Hacker News new | past | comments | ask | show | jobs | submit login

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:



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.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact