ID: 45132 Comment by: tstarling at wikimedia dot org Reported By: tom at collegit dot se Status: Assigned Bug Type: Strings related Operating System: Linux www2 2.6.24.7-grsec PHP Version: 5.2.6 Assigned To: iliaa New Comment:
The issue is that previously 8-bit clean locales, like "C", are now being validated for whatever character set they supposedly are, with characters above 127 being removed. The suggested fix, here and on https://bugzilla.wikimedia.org/show_bug.cgi?id=14944 , appears to reopen whatever security vulnerability it was that the patch fixed in the first place. $ LANG=C php eval.php > setlocale(LC_CTYPE, 'en_US.UTF-8') > echo escapeshellarg("\xC3\x96") 'Ö' > passthru('locale') LANG=C LC_CTYPE="C" LC_NUMERIC="C" LC_TIME="C" LC_COLLATE="C" LC_MONETARY="C" LC_MESSAGES="C" LC_PAPER="C" LC_NAME="C" LC_ADDRESS="C" LC_TELEPHONE="C" LC_MEASUREMENT="C" LC_IDENTIFICATION="C" LC_ALL= Because the environment variable LC_CTYPE is not set by setlocale(), the spawned shell sees the old character set, not the new one. So the shell can be passed an argument escaped for the wrong character set, potentially opening a vulnerability. I'm assuming that the attack scenario for this vulnerability is where an attacker can set environment variables such as LANG to a vulnerable character set, before starting PHP. Because if an attacker can set environment variables during execution of a script, the bug is not fixed. But in that case you're probably screwed anyway. Previous Comments: ------------------------------------------------------------------------ [2008-05-29 23:09:34] [EMAIL PROTECTED] Try using: setlocale(LC_CTYPE, "UTF8", "en_US.UTF-8"); ------------------------------------------------------------------------ [2008-05-29 22:55:58] [EMAIL PROTECTED] Ilia, did that fix get into actual release..? ------------------------------------------------------------------------ [2008-05-29 22:53:54] tom at collegit dot se Description: ------------ Since my web server got updated to 5.2.6 escapeshellcmd() has started removing all Swedish characters from user input. Looks a lot like bug #44564. './configure' '--with-apxs2=/usr/local/apache/bin/apxs' '--with- mysql=/usr/local/mysql' '--enable-debug=no' '--enable-track-vars' '-- with-imap=/usr/local/imap' '--with-mcrypt' '--with-mhash' '--with-dom' '--with-gd' '--with-jpeg-dir' '--enable-ftp' '--with-freetype- dir=/usr' '--with-zlib-dir=/usr' '--with-png-dir=/usr' '--enable- dbase' '--with-gettext' '--with-zlib' '--enable-inline-optimization' '--with-openssl' '--with-curl' '--with-curlwrappers' '--enable-exif' '--with-imap-ssl' '--enable-bcmath' '--enable-mbstring' '--enable- wddx' '--with-xsl' '--with-pdo-mysql=/usr/local/mysql' '--with- mysqli=/usr/local/mysql/bin/mysql_config' '--enable-soap' '--enable- sockets' '--with-mssql' '--with-ming' '--with-pspell' '--enable- calendar' '--enable-bcmath' '--with-t1lib' '--with- pgsql=/usr/local/pgsql' '--with-tidy' '--enable-zip' Reproduce code: --------------- $test = "åäö"; $test = (escapeshellcmd($test)); print $test; Expected result: ---------------- "åäö" Actual result: -------------- "" ------------------------------------------------------------------------ -- Edit this bug report at http://bugs.php.net/?id=45132&edit=1
