From the commit that introduced this bug: The point of the question here is if anybody remembers why we decided not to parse command line args for the cgi version? I could easily see it being useful to be able to write a cgi script like: #!/usr/local/bin/php-cgi -d include_path=/path and have it work both from the command line and from a web context. As far as I can tell this wouldn't conflict with anything, but some…
New PHP Vulnerability:?-s may expose source code for mod_cgi
41–50 of 65 posts
Re: New PHP Vulnerability:?-s may expose source code for mod_cgi
#42This 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…
Re: New PHP Vulnerability:?-s may expose source code for mod_cgi
#43Earlier quoted context omitted.
Yeah, but nobody's run PHP in this silly CGI configuration for 10 years.
Dutch ISP KPN actually has a hosting service that runs PHP primarily in CGI mode: https://www.google.com/#hl=en&output=search&sclient=... yields a massive amount of vulnerable sites.
Re: New PHP Vulnerability:?-s may expose source code for mod_cgi
#44what? a new php vulnerability? havent heard of one of these for a few hours!!
Re: New PHP Vulnerability:?-s may expose source code for mod_cgi
#45From 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.
Here is the fix that was applied: https://github.com/php/php-src/commit/55869a95ab75c0eb99c572... If the first char in the query string is "-" and the query string also contains "=", it skips cmdline argument option parsing. Maybe it is possible to construct a string not starting with "-", not containing "=", but containing a "+" followed by "-options" further out?
Re: New PHP Vulnerability:?-s may expose source code for mod_cgi
#46From the commit that introduced this bug: The point of the question here is if anybody remembers why we decided not to parse command line args for the cgi version? I could easily see it being useful to be able to write a cgi script like: #!/usr/local/bin/php-cgi -d include_path=/path and have it work both from the command line and from a web context. As far as I can tell this wouldn't conflict with anything, but some…
Re: New PHP Vulnerability:?-s may expose source code for mod_cgi
#47Earlier quoted context omitted.
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.
With PHP 5.3.9 or 5.3.10 and php-fpm a new method of process management called ondemand was introduced that handles this use care very well. With a super short idle timeout (a few seconds) this could work very well for shared hosting, but I doubt there are many folks using it since it does still require the process manager to stay running in order to start the workers (this makes it hard to have user configurable php…
Re: New PHP Vulnerability:?-s may expose source code for mod_cgi
#48Earlier quoted context omitted.
Yeah, but nobody's run PHP in this silly CGI configuration for 10 years.
Dutch ISP KPN actually has a hosting service that runs PHP primarily in CGI mode: https://www.google.com/#hl=en&output=search&sclient=... yields a massive amount of vulnerable sites.
Re: New PHP Vulnerability:?-s may expose source code for mod_cgi
#49Huh. I'd used that method of passing in parameters, mistakenly thinking it was the correct way to get a query string. Then I asked on SO and found out I was doing things horribly, horribly wrong.