oss-security - Re: CVE-2014-0475: glibc directory traversal in LC

Follow @Openwall on Twitter for new release announcements and other news

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Mon, 14 Jul 2014 14:07:42 -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 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

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.