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

[Rich Felker <dalias () libc org>]

On Mon, Jul 14, 2014 at 11:57:04AM +0200, Florian Weimer wrote:
> 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).

Thanks for the explanation. This makes sense, and contrary to the
claims in the bug report, I believe it's possible to claim this
behavior is conforming, but only if you don't advertise localedef
support.

I tend to agree that it's the most reasonable choice from a security
standpoint, and necessary if you want to support configurations where
the choice of locale is coming from a different privilege domain.

Rich