Date: Sat, 12 Jul 2014 11:54:51 -0400 From: Rich Felker <dalias@...c.org> To: oss-security@...ts.openwall.com Subject: Re: CVE-2014-0475: glibc directory traversal in LC_* locale handling On Thu, Jul 10, 2014 at 08:52:24PM +0200, Florian Weimer wrote: > Stephane Chazelas discovered that directory traversal issue in locale > handling in glibc. glibc accepts relative paths with ".." components > in the LC_* and LANG variables. Together with typical OpenSSH > configurations (with suitable AcceptEnv settings in sshd_config), this > could conceivably be used to bypass ForceCommand restrictions (or > restricted shells), assuming the attacker has sufficient level of > access to a file system location on the host to create crafted locale > definitions there. > > Bug report: https://sourceware.org/bugzilla/show_bug.cgi?id=17137 On further review, I question whether this is actually a valid vulnerability. The ability to use absolute pathnames as locale strings is a documented feature in both POSIX and glibc, and even after the patch, absolute pathnames are still accepted for locales in non-suid[-like] programs, meaning that bypass of ForceCommand is still possible as long as AcceptEnv is accepting LC_*. The scope of the actual issue seems to be limited to situations where an application was assuming LC_* was safe due to being non-absolute (e.g. checking that the initial character is not '/') then getting hit by directory traversal due to embedded ".." in the string. This seems like a bug, but unless there are applications which were performing such naive checks then accepting untrusted LC_* vars, I question whether this was really CVE-worthy. Does this analysis seem correct, or am I missing something? Aside from general interest, I'm asking largely because we're in the process of discussing how locale path searching should work in musl libc, and I'm trying to understand the reasonable expectations for security aspects of the locale system from an application and user standpoint. Rich
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Powered by Openwall GNU/*/Linux - Powered by OpenVZ