POSIX specifies that the output of the 'locale' command is appropriately quoted and safe to execute, to restore the locale after temporarily forcing e.g. LC_ALL=C. Source: <http://www.opengroup.org/onlinepubs/000095399/utilities/locale.html>, "The <value> and <implied value> shown above shall be properly quoted for possible later reentry to the shell." Any script that relies on this is unsafe on glibc systems. 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= Have fun executing that. (Of course, any path can be used.) This can make safe and correctly written programs and/or scripts unsafe to allow through sudo and/or setuid.
I realise a few days isn't all that long, but last time I reported a security bug I waited for seven months without any action on the bug, and then something only happened when someone else reported the same thing in a different bug. I'm a bit impatient from now on when it comes to security. vapier, CCing you directly, since I don't know if you can access restricted bugs with toolchain@ on the CC list.
bugzilla doesnt know about aliases, so i'd have to login as "toolchain", and that's a pita. has this been posted upstream ? probably not hard to fix in glibc.
Nope, haven't sent it upstream yet.
Bah. @security: *you* asked *me* to report things like this to you, so that you would handle it with upstream without making it public just yet. If you're not going to do that, don't bug me again when I take it upstream myself. Reported as <http://sources.redhat.com/bugzilla/show_bug.cgi?id=11904>.
i dont know what you're referring to as i'm not part of the security team, but i was just planning on looking into the source of the bug and posting a patch. i dont believe the glibc guys have any system in place for security issues, nor do they really care about typical disclosure methodologies -- they just post everything in the clear.
I know, it wasn't directed at you; when I reported a different security vulnerability upstream directly, one of the folks from the security team (unfortunately I forgot who) later asked me to next time just report security bugs here instead, and they would handle it, because they would have preferred the issue not made public until after it was fixed.
Quickly fixed upstream with <http://sourceware.org/git/?p=glibc.git;a=patch;h=026373745eab50a683536d950cb7e17dc98c4259>
ive added the patch to the 2.11.2 & 2.12.1 patchsets, but havent pushed them out. i'd like to look through other glibc bugs first ... i dislike pushing out glibc updates if possible.
ive included this fix in glibc-2.12.1-r1
and it's now in glibc-2.11.2-r1 if people want to run that as a "safer" stable
This is GLSA 201011-01, thanks everyone, and sorry about the delay.
