Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

New PHP Vulnerability:?-s may expose source code for mod_cgi

php.net

Post reply on HN
Print view View original

31–40 of 65 posts

Re: New PHP Vulnerability:?-s may expose source code for mod_cgi

#31

Post by wvenable »

The problem is that the php-cgi script/binary accepts the same command line parameters as the regular php interpreter. This is clearly the wrong behavior and it's even explicitly documented as not doing that:

http://www.php.net/manual/en/security.cgi-bin.attacks.php

"Accessing system files: http://my.host/cgi-bin/php?/etc/passwd The query information in a URL after the question mark (?) is passed as command line arguments to the interpreter by the CGI interface. Usually interpreters open and execute the file specified as the first argument on the command line. When invoked as a CGI binary, PHP refuses to interpret the command line arguments."

Although this was actually in the documentation, Rasmus forgot why it was in there in the first place:

http://thread.gmane.org/gmane.comp.php.devel/20745

Here is a legacy feature of CGI that hardly anybody knows about, using a setup of PHP that is already rare, targeting an issue already claimed to be solved! The perfect storm.

Re: New PHP Vulnerability:?-s may expose source code for mod_cgi

#32

Post by jgeralnik »

yahelc wrote: post #25
jsnrkd wrote: post #17

Does 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...

Using that search and clicking through a few pages I found this: http://support.webroot.com/app/answers/detail/a_id/1761 which is susceptible to this vulnerability.

Re: New PHP Vulnerability:?-s may expose source code for mod_cgi

#33

Post by DougBTX »

kbolino wrote: post #29
devicenull wrote: post #26

Earlier 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.

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…

> then the idle process can be swapped out to disk.

If the FastCGI process is swapped out, does it still have a performance benefit?

Re: New PHP Vulnerability:?-s may expose source code for mod_cgi

#34

Post by 0x0 »

endijs wrote: post #27

From 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

#35

Post by mikey_p »

devicenull wrote: post #26
maratd wrote: post #19

Earlier 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.

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.ini settings since it would require restarting the master).

See http://www.php.net/manual/en/install.fpm.configuration.php under 'pool' group and the 'pm' setting.

Re: New PHP Vulnerability:?-s may expose source code for mod_cgi

#37

Post by driverdan »

micahshell wrote: post #22
jsnrkd wrote: post #17

Does anyone have an example site to see this in action?

Here's my old schools site, theirs no sensitive information. www.ptecwebdev.com?-s

No sensitive information?

http://www.ptecwebdev.com/configuration.php?-s

Re: New PHP Vulnerability:?-s may expose source code for mod_cgi

#38

Post by cheald »

vog wrote: post #9

From the article: > [...] we had a bug in our bug system [...] causing this issue to go public before we had time to test solutions to the level we would like. Ouch.

So we know about this issue because the bug for the disclosure vulnerability was vulnerable to disclosure because of a bug.

Re: New PHP Vulnerability:?-s may expose source code for mod_cgi

#39

Post by jasonlotito »

bleusink wrote: post #13
fusiongyro wrote: post #8

Earlier quoted context omitted.

Yeah, but nobody's run PHP in this silly CGI configuration for 10 years.

I wouldn't be so sure: http://wiki.dreamhost.com/Php#PHP_on_DreamHost

And, just to be clear, FastCGI is default.

Re: New PHP Vulnerability:?-s may expose source code for mod_cgi

#40

Post by caf »

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 somebody at
  some point must have had a reason for disallowing this.
Perfectly illustrating the utility of well-chosen comments in code.
Post reply on HN