I just tested the vulnerability on one of my websites and successfully managed to get the source of my index.php.
However, I then also tried to run remote code execution and couldn't. The only differences to my stack is that it's running Nginx and hops accross a few proxies (nginx -> varnish -> nginx (for SSL and SSI)) in between. I'm not sure why I can't run -d or -n, but any other options seems to always return the source.
Anyone else running nginx in fastcgi noticing similar? It seems like it's vulernable to the source download, however not remote execution. I'm about to work on a rewrite rule now just in case.
(Not sure why it's vulnerable to the source download, as comment below says, it's set up to not be vulnerable?)
Edit: Not sure what part of my comment deserved the down vote. I trust that what you say is true, in that fastcgi is explicitly set up to negate this vulnerability, but the truth remains that I am experiencing it. If anything I'd have wanted to reach out to other nginx users...
The only way I could ever show that fastcgi under nginx is vulnerable, would be by linking to my live vulnerable server running nginx.. and the wiseman inside of me knows that to be a bad idea! Ha.
Did anyone find any interesting sites with this vulnerability? I found a Chinese exchange program and an 'ask Army' *.mil site that has since been patched.
I found that army site too, though I didn't find anything interesting there. I found a Sony site. Some .edu's. Most everything I found seemed to have the exact same source code.
That's strange. I forgot about the Sony site. The best one was the Exchange program. Was cool to see a connectdb.php file with 3 credentials to 3 different servers...
I don't think a lot of well-maintained websites still use the CGI option. Even without this vulnerability, it's a bad idea to run that configuration (as every single request starts a complete PHP process, compiles all the script files, runs them and then shuts down again). It's just incredibly wasteful, comparative to starting and terminating e.g. a complete servlet container with every request. PHP-FPM is now being bundled inside the standard PHP distro, there is really no valid reason to use plain old CGI.
If you use mod_php, every customer's code runs as the apache user, which is bad for security. If you use PHP-FPM, you end up needing at least one long-running process per user, which wastes resources.
You're right, I hadn't thought of that. The only shared hosting environment I use at the moment is mediaTemple's Grid Service, and it looks to me like they are configured for FastCGI regardless.
Just about all the results there appear to be abandoned cPanel placeholders and similar — very few even have domains. I couldn't look at all of them, obviously, but this seems to bear out the idea that nothing anyone cares about is run on PHP-CGI.
My thought exactly. Anyone who keeps their stack up to date is using the Apache2 Handler or FastCGI. Even if they're still on Apache1, mod_php isn't vulnerable.
If you're serving sites for multiple different users (eg shared hosting) you can't safely use mod_php as all of the php would end up running under the same uid.
I bet there are still tens of thousands of otherwise secure php-cgi setups out there.
However, I then also tried to run remote code execution and couldn't. The only differences to my stack is that it's running Nginx and hops accross a few proxies (nginx -> varnish -> nginx (for SSL and SSI)) in between. I'm not sure why I can't run -d or -n, but any other options seems to always return the source.
Anyone else running nginx in fastcgi noticing similar? It seems like it's vulernable to the source download, however not remote execution. I'm about to work on a rewrite rule now just in case.
(Not sure why it's vulnerable to the source download, as comment below says, it's set up to not be vulnerable?)
Edit: Not sure what part of my comment deserved the down vote. I trust that what you say is true, in that fastcgi is explicitly set up to negate this vulnerability, but the truth remains that I am experiencing it. If anything I'd have wanted to reach out to other nginx users...
The only way I could ever show that fastcgi under nginx is vulnerable, would be by linking to my live vulnerable server running nginx.. and the wiseman inside of me knows that to be a bad idea! Ha.