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 11:57:04 +0200
From: Florian Weimer <>
Subject: Re: CVE-2014-0475: glibc directory traversal in LC_*
 locale handling

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

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

Powered by blists - more mailing lists

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.