Tuesday, May 8, 2012

PHP-CGI vulnerability - exploits in the wild and Snort coverage

You've probably heard about the PHP-CGI command-line parameter vulnerability (CVE-2012-1823) released last Thursday, especially if you're defending a PHP-based web application environment. While it makes use of a non-default configuration for exploitation, for users who choose to run PHP through a CGI wrapper, the implications are very important, including potential source code disclosure and remote code execution.

Since this bug is now being actively exploited in the wild, and has had a Metasploit module developed to exploit it, it's worth a note to Snort users explaining the nature of the vulnerability and the state of our coverage, so that IDS analysts can act appropriately on the issue.

At its core, the issue here is fairly simple. When PHP is run in CGI mode, certain arguments will not be escaped before being passed to the PHP binary, which then interprets them as command-line arguments. For example, "-s", will cause the PHP binary to return the source code of the script being run, and not the output of that script. A much more serious case comes when the "-d" flag is used in conjunction with "auto_prepend_file"; by specifying a remote file with PHP code, arbitrary command execution in the context of the PHP binary can be trivially achieved.

There are three signatures for this vulnerability:
  • SID 22063, which covers the remote command execution case used by Metasploit and being exploited in the wild. This rule is enabled in the balanced and security policies by default.
  • SID 22064, which looks for source code disclosure when files include a ".php" in their name. This rule is enabled in the balanced and security policies by default.
  • SID 22097, which looks for source code disclosure against PHP files executed as directory indexes (i.e. http://www.vuln.com/own_me/). This rule is enabled in no policies by default due to performance considerations, but should be enabled manually by those who are protecting known-vulnerable installations.
The VRT is actively monitoring for signs of other abuse cases or obfuscations, and will update rules as appropriate.
Add to Technorati Favorites Digg! This
Post a Comment