This vulnerability is about as bad as it gets, and my heart stopped while I was reading the intro (it's so trivially simple to compromise a site).
Then I reached this sentence, which I felt needed to be bolded and underlined:
A large number of sites run PHP as either an Apache module through mod_php or using php-fpm under nginx. Neither of these setups are vulnerable to this.
<insert immense sigh of relief>. Thank God.
That said, some blackhats are going to be really sore that a backdoor that's been wide open for "at least 8 years" is finally being closed.
The vulnerability can only be exploited if the HTTP server follows a fairly obscure part of the CGI spec. Apache does this, but many other servers do not.
You're right, my title was a bit sensational. I softened it a bit by appended mod_cgi. I think it is very telling that the PHP core recognizes that the people using mod_cgi probably can't upgrade so they're offering a .htaccess adjustment - very commendable.
It basically only affects PHP as CGI (one PHP CGI process is started and stopped for each request). Anything using an alternative communication channel or API to process requests between frontend and backend is safe (for now).
Anyone using a php CGI app could easily have more serious problems than source code disclosure. Those kinds of apps have often been around over a decade with little or no modifications or auditing, because if someone cared enough about the apps to maintain or audit them it's likely they'd have moved to a more performant backend.
Exposing source code is the least of your problems. With creative use of command-line arguments, you can run arbitrary PHP code via any vulnerable URL.
It took me a bit to figure out _how_, but it's nothing obscure or difficult. In fact it relies on _other_ bozotic PHP behavior to work!
Comments
This vulnerability is about as bad as it gets, and my heart stopped while I was reading the intro (it's so trivially simple to compromise a site).
Then I reached this sentence, which I felt needed to be bolded and underlined:
A large number of sites run PHP as either an Apache module through mod_php or using php-fpm under nginx. Neither of these setups are vulnerable to this.
<insert immense sigh of relief>. Thank God.
That said, some blackhats are going to be really sore that a backdoor that's been wide open for "at least 8 years" is finally being closed.
Additionally:
The vulnerability can only be exploited if the HTTP server follows a fairly obscure part of the CGI spec. Apache does this, but many other servers do not.
From: http://eindbazen.net/2012/05/php-cgi-advisory-cve-2012-1823/
You're right, my title was a bit sensational. I softened it a bit by appended mod_cgi. I think it is very telling that the PHP core recognizes that the people using mod_cgi probably can't upgrade so they're offering a .htaccess adjustment - very commendable.
Well, after all, PHP is all about backwards compatibility.
Given how long this has been a problem, it would be interesting to look back through access logs to find attempts to use this.
It also does not appear to be a problem on servers running php via libapache2-mod-fcgid.
It basically only affects PHP as CGI (one PHP CGI process is started and stopped for each request). Anything using an alternative communication channel or API to process requests between frontend and backend is safe (for now).
Anyone using a php CGI app could easily have more serious problems than source code disclosure. Those kinds of apps have often been around over a decade with little or no modifications or auditing, because if someone cared enough about the apps to maintain or audit them it's likely they'd have moved to a more performant backend.
Exposing source code is the least of your problems. With creative use of command-line arguments, you can run arbitrary PHP code via any vulnerable URL.
It took me a bit to figure out _how_, but it's nothing obscure or difficult. In fact it relies on _other_ bozotic PHP behavior to work!