4 ms·

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 likel

by patio11 12y ago

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.

xorcist 12y ago
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.
- moduloo 12y ago
  > but fastcgi_params does not put attacker controlled data into environment variables it does https://gist.github.com/anonymous/ea60dc2915eccf0b803e https://gist.github.com/anonymous/ea60dc2915eccf0b803e
  - xorcist 12y ago
    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?
    - moduloo 12y ago
      i'm working on it it, but it looks like it works only under rare conditions
- patio11 12y ago
  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.
  - xorcist 12y ago
    > 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.
moduloo 12y ago
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 https://gist.github.com/anonymous/ea60dc2915eccf0b803e index.php -> https://gist.github.com/anonymous/883b989caba4156e47b6 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"
kevingadd 12y ago
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?
moduloo 12y ago
suphp, but only if your are stupid enough to switch safe_mode On https://8ack.de/guides/suphp_shellshock https://8ack.de/guides/suphp_shellshock

by patio11 12y ago

xorcist 12y ago

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.

moduloo 12y ago
> but fastcgi_params does not put attacker controlled data into environment variables it does https://gist.github.com/anonymous/ea60dc2915eccf0b803e https://gist.github.com/anonymous/ea60dc2915eccf0b803e
- xorcist 12y ago
  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?
  - moduloo 12y ago
    i'm working on it it, but it looks like it works only under rare conditions
patio11 12y ago
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.
- xorcist 12y ago
  > 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.

moduloo 12y ago

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 https://gist.github.com/anonymous/ea60dc2915eccf0b803e index.php -> https://gist.github.com/anonymous/883b989caba4156e47b6 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"

kevingadd 12y ago

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?

moduloo 12y ago

suphp, but only if your are stupid enough to switch safe_mode On https://8ack.de/guides/suphp_shellshock https://8ack.de/guides/suphp_shellshock