Another thing that interested HNers can feel free to bird dog: PHP + Nginx is often deployed using fastcgi. (And, in my limited experience, far, far more likely to be deployed in greenfield development in the 2010s versus an actual CGI script. I think probably in excess of 20% of "technically savvy young software companies" I run this, the vast majority motivated by one ridiculously common piece of software that I'll refrain from naming because it suggests a trivial spray-and-pray for loop.)

fascgi_params puts a lot of attacker controlled data into "environment variables", but depending on php.ini's variables_order setting those might not actually go into what the rest of the word thinks is an environment variable (and hence not get passed to subprocesses, which is the point of the exercise). If php.ini's variables_order includes an "E", then the environment variable QUERY_STRING (among other things) will include attacker-chosen data. variables_order does include E by default, but does not in the php.ini which ships with the obvious apt-get commands for e.g. Ubuntu.

i wasnt able (yet) to exploit php-fpm, although i was able to sneak the user-agent into it and had an exploitable bash and a system() - call within this file

output -> https://gist.github.com/anonymous/ea60dc2915eccf0b803e

index.php -> https://gist.github.com/anonymous/883b989caba4156e47b6

but maybe suphp seems a little more suspicious?

/etc/suphp/suphp.conf ...

[handlers] ;Handler for php-scripts application/x-httpd-suphp="php:/usr/bin/php-cgi"

;Handler for CGI-scripts x-suphp-cgi="execute:!self"

I would like to reply to this but it is very hard to understand what you are alluding to. What is this software that one fifth of companies run and why is technically savvy in scare quotes, along with some veiled reference to something called spray-and-pray?

It's really impossible to understand you, but fastcgi_params does not put attacker controlled data into environment variables (without the quotes). That much is clear so normal usage of fastcgi is not in danger.

I will try being maximally explicit.

What is this software that one fifth of companies run

A ridiculously popular application, written in PHP, which is widely useful to software companies (among others).

why is technically savvy in scare quotes

I originally wrote "startup" then thought "Actually, this is deployed by a lot of people who aren't startups or who are only arguably startups, hmm, that is an unproductive debate, let's just say what I mean then move on."

some veiled reference to something called spray-and-pray?

Many applications have a well-known set of URLs associated with them. A spray-and-pray exploit is one which you can just fire at a well-known URL at every machine which responds to port 80 in IP4 space. The reason I am not identifying the vulnerable software written in PHP is that it would allow any script kiddie smart enough to text edit the existing exploit scripts to exploit that software as an additional vector.

fastcgi_params does not put attacker controlled data into environment variables (without the quotes)

I'm absolutely positive that fastcgi_params does indeed clobber $_ENV with attacker supplied data if PHP is configured as described above. I am less strongly confident that some configurations of PHP will allow $_ENV to get to at least some subprocesses. I am absolutely confident that some configurations of PHP will not allow you to set $_ENV nor set environmental variables. I have figured out ways to configure it which put the fastcgi_params in $_SERVER but not $_ENV and, separately, in $_ENV but not in environment variables passed to subprocesses. I'm aware of a PHP command which the documentation suggests defaults to passing $_ENV as actual environment variables to subprocesses but which I have not been able to verify actually works as the documentation says, due to it being 6 AM in the morning local time and me having insufficient motivation to continue finding more reasons to justify the conclusion that this bug is very, very bad news and bash needs to get patched immediately everywhere.

> I'm absolutely positive that fastcgi_params does indeed clobber $_ENV with attacker supplied data if PHP is configured as described above.

This is irrelevant. There is no known hole with global variables containing untrusted data.

> I am less strongly confident that some configurations of PHP will allow $_ENV to get to at least some subprocesses.

This could be relevant, if it is indeed passed in the environment.

However I can find no reference in the PHP documentation to this. That does not count for much, admittedly, and I am not very fluent in PHP. If this is real then it is a problem for many people so please share.

> I'm aware of a PHP command which the documentation suggests defaults to passing $_ENV as actual environment variables to subprocesses

Please spell it out already. I've been testing for the better part of two hours to find what you are alluding to, but I have no idea if I'm wasting my time or not.

> but fastcgi_params does not put attacker controlled data into environment variables

it does

https://gist.github.com/anonymous/ea60dc2915eccf0b803e

It looks like you have dumped the a PHP global variable, possibly $_ENV. Do you know of any circumstances where _ENV, or any other PHP variable with potentially untrusted data, is passed in environment variables?

i'm working on it it, but it looks like it works only under rare conditions

Sorry, are you saying Nginx+Fastcgi is vulnerable in general? I tested one of my boxes using nginx+fastcgi+mono and wasn't able to trigger the exploit. Or is it specifically nginx+fastcgi+php?

suphp, but only if your are stupid enough to switch safe_mode On

https://8ack.de/guides/suphp_shellshock

Re: /bin/sh versus /bin/bash (or similar) - note that many Linux systems link /bin/sh -> /bin/bash, so seeing /bin/sh, or knowing that's what system() calls, is not sufficient information on its own to determine your risk.

Yep. More broadly, I think the most sensible strategy for determining whether a system is at risk is "If it has bash and isn't airgapped assume that it's vulnerable because it is highly likely someone will find the vector you overlook."

Slightly more precisely: /bin/sh on ubuntu points to Dash, which is substantially more minimal than bash. Probably not chosen for security (I imagine speed was on their mind), but good either way.

In Debian /bin/sh points to dash too.