Hi,
I've noticed the following CVE:
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-0831
PHP before 5.3.10 does not properly perform a temporary change to the magic_quotes_gpc directive during the importing of environment variables, which makes it easier for remote attackers to conduct SQL injection attacks via a crafted request, related to main/php_variables.c, sapi/cgi/cgi_main.c, and sapi/fpm/fpm/fpm_main.c.
and changelog of Ubuntu php5 pacakge:
https://launchpad.net/ubuntu/+source/php5/5.3.2-1ubuntu4.13
- SECURITY UPDATE: magic_quotes_gpc remote disable vulnerability
- debian/patches/php5-CVE-2012-0831.patch: always restore
magic_quote_gpc on request shutdown- CVE-2012-0831
and read https://bugs.php.net/bug.php?id=61043.
But I can't understand this.
PHP before 5.3.10? But I can't see any changes related this CVE from http://svn.php.net/viewvc/php/php-src/tags/php_5_3_10/?view=log
And I've tried the test of https://bugs.launchpad.net/ubuntu/+source/php5/+bug/930115, but I can't reproduced (report string(1) "1" if "magic_quotes_gpc" is "On"). Something was wrong?
Even if the https://bugs.launchpad.net/ubuntu/+source/php5/+bug/930115 problem is exists, but "magic_quotes_gpc remote disable vulnerability" is strange. Can attacker change "magic_quotes_gpc" value deliberately?
And according to CVE, "which makes it easier for remote attackers to conduct SQL injection attacks via a crafted request". But some PHP applications which suppose "magic_quotes_gpc=Off" are not affected, aren't them?
FYI, The following is my test result:
$ echo 'magic_quotes_gpc=On' > /tmp/php.ini && php-5.3.10 -c /tmp/php.ini -r 'var_dump(phpversion(), ini_get("magic_quotes_gpc"));'
string(6) "5.3.10"
string(1) "1"
$ echo 'magic_quotes_gpc=On' > /tmp/php.ini && php-5.3.9 -c /tmp/php.ini -r 'var_dump(phpversion(), ini_get("magic_quotes_gpc"));'
string(5) "5.3.9"
string(1) "1"
$ echo 'magic_quotes_gpc=On' > /tmp/php.ini && php-5.3.8 -c /tmp/php.ini -r 'var_dump(phpversion(), ini_get("magic_quotes_gpc"));'
string(5) "5.3.8"
string(1) "1"
$ echo 'magic_quotes_gpc=On' > /tmp/php.ini && php-5.3.6 -c /tmp/php.ini -r 'var_dump(phpversion(), ini_get("magic_quotes_gpc"));'
string(5) "5.3.6"
string(1) "1"
$ echo 'magic_quotes_gpc=On' > /tmp/php.ini && php-5.3.5 -c /tmp/php.ini -r 'var_dump(phpversion(), ini_get("magic_quotes_gpc"));'
string(5) "5.3.5"
string(1) "1"
$ echo 'magic_quotes_gpc=On' > /tmp/php.ini && php-5.3.4 -c /tmp/php.ini -r 'var_dump(phpversion(), ini_get("magic_quotes_gpc"));'
string(5) "5.3.4"
string(1) "1"
$ echo 'magic_quotes_gpc=On' > /tmp/php.ini && php-5.3.3 -c /tmp/php.ini -r 'var_dump(phpversion(), ini_get("magic_quotes_gpc"));'
string(5) "5.3.3"
string(1) "1"
$ echo 'magic_quotes_gpc=On' > /tmp/php.ini && php-5.3.2 -c /tmp/php.ini -r 'var_dump(phpversion(), ini_get("magic_quotes_gpc"));'
string(5) "5.3.2"
string(1) "1"
$ echo 'magic_quotes_gpc=On' > /tmp/php.ini && php-5.3.1 -c /tmp/php.ini -r 'var_dump(phpversion(), ini_get("magic_quotes_gpc"));'
string(5) "5.3.1"
string(1) "1"
$ echo 'magic_quotes_gpc=On' > /tmp/php.ini && php-5.3.0 -c /tmp/php.ini -r 'var_dump(phpversion(), ini_get("magic_quotes_gpc"));'
string(5) "5.3.0"
string(1) "1"
--
Kousuke Ebihara kousuke@co3k.org
http://co3k.org/
Am 14.02.2012 14:02, schrieb Kousuke Ebihara:
Hi,
I've noticed the following CVE:
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-0831
PHP before 5.3.10 does not properly perform a temporary change to the magic_quotes_gpc directive during the importing of environment variables, which makes it easier for remote attackers to conduct SQL injection attacks via a crafted request, related to main/php_variables.c, sapi/cgi/cgi_main.c, and sapi/fpm/fpm/fpm_main.c.
who in the world has magic_quotes on and does rely on any
addslashes() or magic_quotes thinking this makes any query
safe against sql-injection?
without mysql_real_escape() you are completly unprotected
in every case and magic_quotes was one of the badest
things ever implemented
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
(12/02/14 22:07), Reindl Harald wrote:
who in the world has magic_quotes on and does rely on any
addslashes()or magic_quotes thinking this makes any query
safe against sql-injection?without mysql_real_escape() you are completly unprotected
in every case and magic_quotes was one of the badest
things ever implemented
Of course I agree with you. (And, basically, we should use prepared statement but it is not main topic...)
Kousuke Ebihara kousuke@co3k.org
http://co3k.org/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQEcBAEBAgAGBQJPOmB/AAoJECNvap7T8JfFBNkH/0DWPJMZoCkCSZVTs8NH4cYZ
PGedQlyXX8eEEdbZwgdVYcrOXEXq9Gh6S875oWwjacC2FGNtdDs+1y1tBU7wlvkF
SOnecZFdzis0Fp5vauAF/9lGJ4MmFa3CmLOrI0OeSJoGLSD3pcYtAZQff1HjyEej
BAYwxgMvhmsifnMMSJ6bVbQH7VLjgfm8uxXxdNJfMze5zYExnr5Otn3ku08Crv/e
vAi94krJU5WgtKwdshAV+JXPvWxKoK4+/ooIDXT9Uvv4p/6q79H3++5lh7nHcGAw
GijWuTIPOlSVTvAOenlcitj/CfQjcNp+9GS9a1XsDkXZL0+cyzRZYQpvwKpwF5A=
=0laO
-----END PGP SIGNATURE
2012/2/14 Kousuke Ebihara kousuke@co3k.org
Hi,
I've noticed the following CVE:
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-0831
PHP before 5.3.10 does not properly perform a temporary change to the
magic_quotes_gpc directive during the importing of environment variables,
which makes it easier for remote attackers to conduct SQL injection attacks
via a crafted request, related to main/php_variables.c,
sapi/cgi/cgi_main.c, and sapi/fpm/fpm/fpm_main.c.and changelog of Ubuntu php5 pacakge:
https://launchpad.net/ubuntu/+source/php5/5.3.2-1ubuntu4.13
- SECURITY UPDATE: magic_quotes_gpc remote disable vulnerability
- debian/patches/php5-CVE-2012-0831.patch: always restore
magic_quote_gpc on request shutdown- CVE-2012-0831
and read https://bugs.php.net/bug.php?id=61043.
But I can't understand this.
PHP before 5.3.10? But I can't see any changes related this CVE from
http://svn.php.net/viewvc/php/php-src/tags/php_5_3_10/?view=logAnd I've tried the test of
https://bugs.launchpad.net/ubuntu/+source/php5/+bug/930115, but I can't
reproduced (report string(1) "1" if "magic_quotes_gpc" is "On"). Something
was wrong?Even if the https://bugs.launchpad.net/ubuntu/+source/php5/+bug/930115problem is exists, but "magic_quotes_gpc remote disable vulnerability" is
strange. Can attacker change "magic_quotes_gpc" value deliberately?And according to CVE, "which makes it easier for remote attackers to
conduct SQL injection attacks via a crafted request". But some PHP
applications which suppose "magic_quotes_gpc=Off" are not affected, aren't
them?FYI, The following is my test result:
$ echo 'magic_quotes_gpc=On' > /tmp/php.ini && php-5.3.10 -c /tmp/php.ini
-r 'var_dump(phpversion(), ini_get("magic_quotes_gpc"));'
string(6) "5.3.10"
string(1) "1"
$ echo 'magic_quotes_gpc=On' > /tmp/php.ini && php-5.3.9 -c /tmp/php.ini
-r 'var_dump(phpversion(), ini_get("magic_quotes_gpc"));'
string(5) "5.3.9"
string(1) "1"
$ echo 'magic_quotes_gpc=On' > /tmp/php.ini && php-5.3.8 -c /tmp/php.ini
-r 'var_dump(phpversion(), ini_get("magic_quotes_gpc"));'
string(5) "5.3.8"
string(1) "1"
$ echo 'magic_quotes_gpc=On' > /tmp/php.ini && php-5.3.6 -c /tmp/php.ini
-r 'var_dump(phpversion(), ini_get("magic_quotes_gpc"));'
string(5) "5.3.6"
string(1) "1"
$ echo 'magic_quotes_gpc=On' > /tmp/php.ini && php-5.3.5 -c /tmp/php.ini
-r 'var_dump(phpversion(), ini_get("magic_quotes_gpc"));'
string(5) "5.3.5"
string(1) "1"
$ echo 'magic_quotes_gpc=On' > /tmp/php.ini && php-5.3.4 -c /tmp/php.ini
-r 'var_dump(phpversion(), ini_get("magic_quotes_gpc"));'
string(5) "5.3.4"
string(1) "1"
$ echo 'magic_quotes_gpc=On' > /tmp/php.ini && php-5.3.3 -c /tmp/php.ini
-r 'var_dump(phpversion(), ini_get("magic_quotes_gpc"));'
string(5) "5.3.3"
string(1) "1"
$ echo 'magic_quotes_gpc=On' > /tmp/php.ini && php-5.3.2 -c /tmp/php.ini
-r 'var_dump(phpversion(), ini_get("magic_quotes_gpc"));'
string(5) "5.3.2"
string(1) "1"
$ echo 'magic_quotes_gpc=On' > /tmp/php.ini && php-5.3.1 -c /tmp/php.ini
-r 'var_dump(phpversion(), ini_get("magic_quotes_gpc"));'
string(5) "5.3.1"
string(1) "1"
$ echo 'magic_quotes_gpc=On' > /tmp/php.ini && php-5.3.0 -c /tmp/php.ini
-r 'var_dump(phpversion(), ini_get("magic_quotes_gpc"));'
string(5) "5.3.0"
string(1) "1"--
Kousuke Ebihara kousuke@co3k.org
http://co3k.org/
hi.
as far as I can see the referenced fix (
http://svn.php.net/viewvc?view=revision&revision=323016) never made to the
5.3.10 release (
http://svn.php.net/viewvc/php/php-src/branches/PHP_5_3_10/?pathrev=323032&view=log
)
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
as far as I can see the referenced fix (
http://svn.php.net/viewvc?view=revision&revision=323016) never made to the
5.3.10 release (
http://svn.php.net/viewvc/php/php-src/branches/PHP_5_3_10/?pathrev=323032&view=log
)
Preface: I am not expert in these matters by any means.
I happened to do some work with a build of the PHP_5_3 branch that did
include SVN revision 323016. With that revision, I observed some
weird behavior with magic_quotes_gpc coming on even if it was
configured off.
The specific circumstance was that magic_quotes_gpc was being set to
off in Apache via php_flag, rather than in the .ini file. phpinfo()
reported magic_quotes_gpc as Off/On, but magic quotes behavior started
happening anyway. Of course I just moved the configuration to the
.ini file where it belongs, but this was a change from previous
behavior prior to that rebuild. Maybe it was a coincidence, but when
I saw this discussion, I felt mentioning it was "better safe than
sorry."
as far as I can see the referenced fix (
http://svn.php.net/viewvc?view=revision&revision=323016) never made to the
5.3.10 release (
http://svn.php.net/viewvc/php/php-src/branches/PHP_5_3_10/?pathrev=323032&view=log
)Preface: I am not expert in these matters by any means.
I happened to do some work with a build of the PHP_5_3 branch that did
include SVN revision 323016. With that revision, I observed some
weird behavior with magic_quotes_gpc coming on even if it was
configured off.The specific circumstance was that magic_quotes_gpc was being set to
off in Apache via php_flag, rather than in the .ini file.phpinfo()
reported magic_quotes_gpc as Off/On, but magic quotes behavior started
happening anyway. Of course I just moved the configuration to the
.ini file where it belongs, but this was a change from previous
behavior prior to that rebuild. Maybe it was a coincidence, but when
I saw this discussion, I felt mentioning it was "better safe than
sorry."
There is lots of weirdness around Apache startup and double module loads
and such that makes the initialization code overly complicated, so it
doesn't surprise me that this change could have some issues. Was this
with Apache1 or 2 you saw this?
-Rasmus
The specific circumstance was that magic_quotes_gpc was being set to
off in Apache via php_flag, rather than in the .ini file. phpinfo()
reported magic_quotes_gpc as Off/On, but magic quotes behavior started
happening anyway.Was this
with Apache1 or 2 you saw this?
Apache 2.2 (--with-apxs2)
Hope that helps.
(12/02/16 16:24), J David wrote:
reported magic_quotes_gpc as Off/On, but magic quotes behavior started
happening anyway. Of course I just moved the configuration to the
I've also confirmed this behavior in snapshot version of PHP 5.3 (Build on Feb 16, 2012 00:30 UTC).
I tested my https://gist.github.com/1840714 script.
And I've got the following result::
$ wget -q "http://localhost:8080/phpinfo.php" -O - | grep "Loaded Configuration File"
<tr><td class="e">Loaded Configuration File </td><td class="v">/private/tmp/php.ini </td></tr>
$ cat /private/tmp/php.ini
magic_quotes_gpc=On
$ wget -q "http://localhost:8080/cve-2012-0831.php?a='" -O -
PHP Version: 5.3.11-dev
magic_quotes_gpc: 0
$_GET['a']: \'
I think magic_quotes_gpc is not disabled. All of the PHP C sources might use "PG(magic_quotes_gpc)" to access to that setting value, so that result might not be affected zend_alter_ini_entry_ex().
But a result of "ini_get()" uses a setting value after the zend_alter_ini_entry_ex() calling, so it reports 0.
The above is just my guessing because I'm not an expert of PHP C source code but probably it is not bad guessing, I think.
--
Kousuke Ebihara
ebihara@tejimaya.com
Hi Kousuke,
(12/02/16 16:24), J David wrote:
reported magic_quotes_gpc as Off/On, but magic quotes behavior started
happening anyway. Of course I just moved the configuration to theI've also confirmed this behavior in snapshot version of PHP 5.3 (Build on Feb 16, 2012 00:30 UTC).
I tested my https://gist.github.com/1840714 script.
And I've got the following result::
$ wget -q "http://localhost:8080/phpinfo.php" -O - | grep "Loaded Configuration File" <tr><td class="e">Loaded Configuration File </td><td class="v">/private/tmp/php.ini </td></tr> $ cat /private/tmp/php.ini magic_quotes_gpc=On $ wget -q "http://localhost:8080/cve-2012-0831.php?a='" -O - PHP Version: 5.3.11-dev magic_quotes_gpc: 0 $_GET['a']: \'I think magic_quotes_gpc is not disabled. All of the PHP C sources might use "PG(magic_quotes_gpc)" to access to that setting value, so that result might not be affected zend_alter_ini_entry_ex().
But a result of "ini_get()" uses a setting value after the zend_alter_ini_entry_ex() calling, so it reports 0.
The above is just my guessing because I'm not an expert of PHP C source code but probably it is not bad guessing, I think.
You're seeing the behavior reported by Ondřej Surý in
https://bugs.php.net/bug.php?id=61043, where magic_quotes_gpc is
configured on, but ini_get('magic_quotes_gpc') returns that it's
disabled, even though magic quoting is still happening.
That's different from the behavior that J David reported, where he
configured it off, but saw magic quoting still happening.
It would be great to get comments on the patch provided by Ondřej
in the bug report to know if it's the correct fix, and if so, get it
committed to the 5.3 branch.
Thanks.
--
Steve Beattie
sbeattie@ubuntu.com
http://NxNW.org/~steve/
Ping, the patch (https://bugs.php.net/bug.php?id=61043) is simple and
PHP 5.3-SVN is broken when using magic_quotes_gpc. Please review and
merge.
Thanks,
Ondrej
Hi Kousuke,
I've also confirmed this behavior in snapshot version of PHP 5.3 (Build on Feb 16, 2012 00:30 UTC).
I tested my https://gist.github.com/1840714 script.
And I've got the following result::
$ wget -q "http://localhost:8080/phpinfo.php"; -O - | grep "Loaded Configuration File"
<tr><td class="e">Loaded Configuration File </td><td class="v">/private/tmp/php.ini </td></tr>$ cat /private/tmp/php.ini
magic_quotes_gpc=On$ wget -q "http://localhost:8080/cve-2012-0831.php?a='"; -O -
PHP Version: 5.3.11-dev
magic_quotes_gpc: 0
$_GET['a']: 'I think magic_quotes_gpc is not disabled. All of the PHP C sources might use "PG(magic_quotes_gpc)" to access to that setting value, so that result might not be affected zend_alter_ini_entry_ex().
But a result of "ini_get()" uses a setting value after the zend_alter_ini_entry_ex() calling, so it reports 0.
The above is just my guessing because I'm not an expert of PHP C source code but probably it is not bad guessing, I think.
You're seeing the behavior reported by Ondřej Surý in
https://bugs.php.net/bug.php?id=61043, where magic_quotes_gpc is
configured on, but ini_get('magic_quotes_gpc') returns that it's
disabled, even though magic quoting is still happening.It would be great to get comments on the patch provided by Ondřej
in the bug report to know if it's the correct fix, and if so, get it
committed to the 5.3 branch.Thanks.
--
Steve Beattie
sbeattie@ubuntu.com
http://NxNW.org/~steve/
--
Ondřej Surý <ondrej@sury.org
2012/2/14 Kousuke Ebihara kousuke@co3k.org:
Hi,
I've noticed the following CVE:
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-0831
PHP before 5.3.10 does not properly perform a temporary change to the magic_quotes_gpc directive during the importing of environment variables, which makes it easier for remote attackers to conduct SQL injection attacks via a crafted request, related to main/php_variables.c, sapi/cgi/cgi_main.c, and sapi/fpm/fpm/fpm_main.c.
That's some noise on the wire... This fix was never part of PHP
5.3.10 and I think all security team just copied this information from
CVE. (Now I at least know where they got it.)
And you really need to pull the patch from
https://bugs.php.net/bug.php?id=61043 before you push out 5.3.11.
O.
Ondřej Surý <ondrej@sury.org
(12/02/14 23:03), Ondřej Surý wrote:
That's some noise on the wire... This fix was never part of PHP
5.3.10 and I think all security team just copied this information from
CVE. (Now I at least know where they got it.)And you really need to pull the patch from
https://bugs.php.net/bug.php?id=61043 before you push out 5.3.11.
Thanks, it becomes clear.
I understand that ...
- In PHP 5.3.10 and before, magic_quotes_gpc is disabled even if it is enabled in php.ini.
- If my PHP scripts don't depend on magic quote feature, in this case, I don't need to apply the patch.
Are these correct?
BTW, According to NVD (http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2012-0831),
CVSS v2 Base Score:7.5 (HIGH)
Access Vector: Network exploitable
Access Complexity: Low
Authentication: Not required to exploit
Impact Type:Allows unauthorized disclosure of information; Allows unauthorized modification; Allows disruption of service
SQL Injection (CWE-89)
But I think it is totally mistakes. I think it is evaluated as "SQL Injection attack vulnerability in PHP", but it is not correct. magic_quotes_gpc is just a fail-safe (but of course it is tattered) and a script which depends on magic_quotes_gpc is intrinsically vulnerable.
--
Kousuke Ebihara kousuke@co3k.org
http://co3k.org/
Hi,
- In PHP 5.3.10 and before, magic_quotes_gpc is disabled even if it is enabled in php.ini.
No the vulnerability allows attackers to disable activated magic_quotes_gpc with a remote exploit.
- If my PHP scripts don't depend on magic quote feature, in this case, I don't need to apply the patch.
Applications like SugarCRM also do not depend on magic_quotes_gpc. However SugarCRM before 6.4.0 contains an SQL injection vulnerability that is not exploitable in case magic_quotes_gpc is activated.
But I think it is totally mistakes. I think it is evaluated as "SQL Injection attack vulnerability in PHP", but it is not correct. magic_quotes_gpc is just a fail-safe (but of course it is tattered) and a script which depends on magic_quotes_gpc is intrinsically vulnerable.
While magic_quotes_gpc is for sure not the best solution possible, it is simply not true that scripts relying on magic_quotes_gpc for SQL escaping are insecure.
These scripts are simply not portable (when it comes to moving the SQL to a different database software or moving to some multi-byte character sets).
There is a lot of old code on the internet that relies on magic_quotes_gpc and it uses utf8 or iso character set and is NOT vulnerable.
Of course using mysql_real_escape_string() and prepared statements are more secure, but they are not always required to be secure.
Regards,
Stefan Esser
PS: and all that old code will be vulnerable once the server admin updates to PHP 5.4