Re: CVE-2014-0475: glibc directory traversal in LC_* locale handling

[Rich Felker <dalias () libc org>]

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