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

[Florian Weimer <fweimer () redhat com>]

On 07/12/2014 05:54 PM, Rich Felker wrote:
> > 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_*.

This is not correct, glibc never accepted absolute pathnames in the 
sense that they were resolved as absolute path names.  They were always 
resolved relative to LOCPATH, with or without a leading slash.

When the lack of conformance was reported as a glibc bug a couple of 
years ago, the bug report was labeled as invalid:

  https://sourceware.org/bugzilla/show_bug.cgi?id=11635

We didn't want to break backwards compatibility here, so we documented 
the existing behavior and just prohibited ".." pathname components. 
This allowed us to treat this as a glibc vulnerability, with a fairly 
simple and isolated fix (although the gettext part is still pending).

> 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.

Your analysis is correct for POSIX-compliant systems, but not for glibc. 
 Unfortunately, POSIX compliance makes it quite difficult to fix this.

--
Florian Weimer / Red Hat Product Security