As has been mentioned, using CGI for php is quite outdated so it probably doesn't impact that many sites, that said this sort of vulnerability is exactly why you should put all but the minimum front controller PHP in a folder that's outside of the public folder your site is being served from.
New PHP Vulnerability:?-s may expose source code for mod_cgi
21–30 of 65 posts
Re: New PHP Vulnerability:?-s may expose source code for mod_cgi
#22Does anyone have an example site to see this in action?
Here's my old schools site, theirs no sensitive information.
www.ptecwebdev.com?-s
Re: New PHP Vulnerability:?-s may expose source code for mod_cgi
#23This 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. . Thank God. That said, some blackhats ar…
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.
Re: New PHP Vulnerability:?-s may expose source code for mod_cgi
#24Their is a fix here.
Re: New PHP Vulnerability:?-s may expose source code for mod_cgi
#25Does anyone have an example site to see this in action?
I'd thought you could find some with this Google search, but I haven't gotten any to work.
https://www.google.com/search?q=inurl:%22cgi-bin%22+inurl:ph...
Re: New PHP Vulnerability:?-s may expose source code for mod_cgi
#26Earlier quoted context omitted.
I wouldn't be so sure: http://wiki.dreamhost.com/Php#PHP_on_DreamHost
That's horrible! I would never use a host that relied on CGI for anything. There's a reason they came out with FastCGI.
FastCGI makes little to no sense on shared web hosting machines. With FastCGI, each user on the machine needs at least one long-running process to handle requests. This is a waste when you consider that large numbers of the sites may be idle 99% of the time. With CGI, you only have PHP processes running when they are actually handling requests, it's really a much better solution for shared hosting.
Re: New PHP Vulnerability:?-s may expose source code for mod_cgi
#27From Twitter:
Stefan Esser @i0n1c
The security emergency release to fix the PHP CGI RCE (that was tested for days...) does not fix anything at all.
Re: New PHP Vulnerability:?-s may expose source code for mod_cgi
#28Re: New PHP Vulnerability:?-s may expose source code for mod_cgi
#29Earlier quoted context omitted.
That's horrible! I would never use a host that relied on CGI for anything. There's a reason they came out with FastCGI.
FastCGI makes little to no sense on shared web hosting machines. With FastCGI, each user on the machine needs at least one long-running process to handle requests. This is a waste when you consider that large numbers of the sites may be idle 99% of the time. With CGI, you only have PHP processes running when they are actually handling requests, it's really a much better solution for shared hosting.
What is it wasting? If the process is idle, then it is only taking up space in memory.
If that space isn't needed, then the cost is nil (it takes the same amount of power to store a 1 as a 0; the real power cost is in moving data in and out of memory, not in storing it).
If the space is needed, then the idle process can be swapped out to disk. So again, no practical cost.
FastCGI may not be the best solution, but CGI is not an improvement (the overhead of starting a new runtime to handle every request will introduce a lot of latency, which will be especially noticeable on pages that make a lot of asynchronous requests).
Re: New PHP Vulnerability:?-s may expose source code for mod_cgi
#30I don't think any major site uses mod_cgi.