Harald van Dijk discovered [1],[2] that glibc's locale command does not sufficiently sanitize the user environment. According to POSIX specifications [3], the output of the 'locale' command must be appropriately quoted and safe to execute, in order to restore the locale after temporarily forcing a change (such as LC_ALL=C). However, this is not the case with glibc versions up to and including 2.12.1: LANG=' rm -rf /' locale locale: Cannot set LC_CTYPE to default locale: No such file or directory locale: Cannot set LC_MESSAGES to default locale: No such file or directory locale: Cannot set LC_ALL to default locale: No such file or directory LANG= rm -rf / LC_CTYPE=" rm -rf /" LC_NUMERIC=" rm -rf /" LC_TIME=" rm -rf /" LC_COLLATE=" rm -rf /" LC_MONETARY=" rm -rf /" LC_MESSAGES=" rm -rf /" LC_PAPER=" rm -rf /" LC_NAME=" rm -rf /" LC_ADDRESS=" rm -rf /" LC_TELEPHONE=" rm -rf /" LC_MEASUREMENT=" rm -rf /" LC_IDENTIFICATION=" rm -rf /" LC_ALL= Any script that does "eval $(locale)" or something similar will execute the unquoted commands. The POSIX specification states: "The <value> and <implied value> shown above shall be properly quoted for possible later reentry to the shell. The <value> shall not be quoted using double-quotes (so that it can be distinguished by the user from the <implied value> case, which always requires double-quotes)." This has been corrected upstream [4]. [1] http://bugs.gentoo.org/show_bug.cgi?id=330923 [2] http://sources.redhat.com/bugzilla/show_bug.cgi?id=11904 [3] http://www.opengroup.org/onlinepubs/000095399/utilities/locale.html [4] http://sourceware.org/git/?p=glibc.git;a=patch;h=026373745eab50a683536d950cb7e17dc98c4259
Is there any real world example where this bug actually allows crossing trust boundary? I was not able to find any use where this "eval $(locale)" pattern is used even with trusted environment. Additionally, glibc locale man page does not document POSIX requirement to have the output safe for re-entry to the shell. I don't think this got any CVE assigned either. Gentoo GLSA 201011-01 does link their bug listed in comment #1 as [1], but the issue is not described in the text. http://www.gentoo.org/security/en/glsa/glsa-201011-01.xml
This issue has been addressed in following products: Red Hat Enterprise Linux 5 Via RHSA-2011:0412 https://rhn.redhat.com/errata/RHSA-2011-0412.html
This issue has been addressed in following products: Red Hat Enterprise Linux 6 Via RHSA-2011:0413 https://rhn.redhat.com/errata/RHSA-2011-0413.html
This issue has been addressed in following products: Red Hat Enterprise Linux 4 Via RHSA-2012:0125 https://rhn.redhat.com/errata/RHSA-2012-0125.html
Statement: (none)