php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Sec Bug #61910 VU#520827 - PHP-CGI query string parameter vulnerability
Submitted: 2012-05-02 17:56 UTC Modified: 2012-05-09 21:37 UTC
From: aaasd at asda dot com Assigned: johannes (profile)
Status: Closed Package: CGI/CLI related
PHP Version: 5.4.1 OS: Unix
Private report: No CVE-ID: 2012-1823
View Developer Edit
 [2012-05-02 17:56 UTC] aaasd at asda dot com 
Description:
------------
U#520827 - PHP-CGI query string parameter vulnerability

CVE: CVE-2012-1823

KEYWORDS:
php
php-cgi

OVERVIEW
PHP-CGI-based setups contain a vulnerability when parsing query
string parameters from php files.

DESCRIPTION
According to PHP's website, "PHP is a widely-used general-purpose
scripting language that is especially suited for Web development and
can be embedded into HTML." When PHP is used in a CGI-based setup
(such as Apache's mod_cgid), the php-cgi receives a processed query
string parameter as command line arguments which allows command-line
switches, such as -s, -d or -c to be passed to the php-cgi binary,
which can be exploited to disclose source code and obtain arbitrary
code execution.

An example of the -s command, allowing an attacker to view the source
code of index.php is below:
http://localhost/index.php?-s

IMPACT
A remote unauthenticated attacker could obtain sensitive information,
cause a denial of service condition or may be able to execute
arbitrary code with the privileges of the web server.

SOLUTION
We are currently unaware of a practical solution to this problem.

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

CREDIT
Thanks to De Eindbazen for reporting this vulnerability.

This document was written by Michael Orlando.

Patches

php-cgi-disable-argv (last revision 2012-05-06 00:14 UTC by neweracracker at gmail dot com)
CVE-2012-1823.patch (last revision 2012-05-05 20:59 UTC by tyukish at parallels dot com)
cgi.diff-fix-check.patch (last revision 2012-05-04 01:08 UTC by erik at pizzadoos dot com)
cgi.diff (last revision 2012-05-02 18:45 UTC by rasmus@php.net)

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2012-05-02 17:57 UTC] stas@php.net
-CVE-ID: +CVE-ID: 2012-1823
 [2012-05-02 18:40 UTC] felipe@php.net
-Private report: No +Private report: Yes
 [2012-05-02 18:45 UTC] rasmus@php.net 
The following patch has been added/updated:

Patch Name: cgi.diff
Revision:   1335984315
URL:        https://bugs.php.net/patch-display.php?bug=61910&patch=cgi.diff&revision=1335984315
 [2012-05-03 13:00 UTC] rasmus@php.net 
And for people not able to update/apply a patch, this mod_rewrite condition and 
rule should take care of it for Apache users:

    RewriteCond %{QUERY_STRING} ^(%2d|-)[^=]+$ [NC]
    RewriteRule ^(.*) $1? [L]
 [2012-05-03 18:25 UTC] johannes@php.net
-Status: Open +Status: Closed -Assigned To: +Assigned To: johannes
 [2012-05-04 08:18 UTC] gcbirzan at gmail dot com 
This should be open, and a new PHP released with the new patch. What the Hell...
 [2012-05-04 18:41 UTC] neweracracker at gmail dot com 
I wonder why PHP-5.3.12 head wasn't merged with PHP-5.3 yet. Also PHP-5.4.2 head wasn't merged with PHP-5.4.
 [2012-05-04 18:54 UTC] neweracracker at gmail dot com 
I wonder what is the consequence of doing something like ?-s+%3d ('%3d' is the encoded form of '='.
 [2012-05-05 12:26 UTC] adedov at parallels dot com 
When ?-T+10000 problem will be fixed?
 [2012-05-05 21:07 UTC] tyukish at parallels dot com 
you forgot to check in second block for 'T'.
it is corrected in attached patch: CVE-2012-1823.patch
 [2012-05-05 21:18 UTC] tyukish at parallels dot com 
just for clear: I told about following case: 

http://www.php-security.net/archives/9-New-PHP-CGI-exploit-CVE-2012-1823.html

DoS with “?-T+100000” (careful, this will DoS your browser rendering engine too, 
so you should do this via cURL)
 [2012-05-05 21:21 UTC] rasmus@php.net 
?-T+10000 is fixed by the original patch because it blocks anything starting with 
- and not containing a =
 [2012-05-05 21:23 UTC] stas@php.net 
Attached patch fixes only part of the problem, since many setups use shell 
wrappers where various other shenanigans are possible. We're working on a better 
fix which will be released early next week.
 [2012-05-05 22:05 UTC] tyukish at parallels dot com 
rasmus@:
cgi.diff-fix-check.patch(and prev) - didn't fix "?-T+10000" because parse OPTs 
were separated into several places. And in second critical place not checked 
result of the condition.

stas@: 
Do you known already some details what are not fixed ? 
I see only 3 blocks where parsed OPTs, first and second are safe through new 
condition, 3rd block is safe through "if (!cgi && !fastcgi)" condition.

Thanks.
 [2012-05-05 22:27 UTC] rasmus@php.net 
Ah, you mean for the fastcgi case. In what sort of configuration can those args 
even get to fastcgi? I haven't been able to reproduce that.
 [2012-05-06 00:19 UTC] neweracracker at gmail dot com 
Some more details:
http://eindbazen.net/2012/05/php-cgi-advisory-cve-2012-1823/
 [2012-05-06 11:15 UTC] neweracracker at gmail dot com 
About CVE-2012-1823.patch

if(*decoded_query_string == '-' && strchr(query_string, '=') == NULL)

Should be:
if(strchr(decoded_query_string, '-') != NULL && strchr(query_string, '=') == NULL)

This would fix ?+-s attacks.
(Needs testing)
 [2012-05-06 13:31 UTC] rasmus@php.net 
That would break simple safe URLs like ?top-40 

We have a better fix for this one already.
 [2012-05-09 21:33 UTC] aaa at aa dot com
-: stas@php.net +: aaa at aa dot com
 [2012-05-09 21:33 UTC] aaa at aa dot com 
aaa
 [2012-05-09 21:33 UTC] xadasd at dsad dot com
-: aaa@aa.com +: xadasd at dsad dot com
 [2012-05-09 21:33 UTC] xadasd at dsad dot com 
sdasd
 [2012-05-09 21:35 UTC] aaasd at asda dot com
-: xadasd@dsad.com +: aaasd at asda dot com
 [2012-05-09 21:35 UTC] aaasd at asda dot com 
<script>alert(1)</script>
 [2012-05-09 21:37 UTC] stas@php.net
-Block user comment: No +Block user comment: Yes
 [2012-05-09 21:37 UTC] stas@php.net 
Looks like this becomes target for spamming, so I'm closing comments as this 
appears to be fixed by 5.4.3. If you have anything more on this, please write to 
security@php.net.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved. 		Last updated: Mon Dec 30 14:01:28 2024 UTC