Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 14 Jul 2014 11:57:04 +0200
From: Florian Weimer <fweimer@...hat.com>
To: oss-security@...ts.openwall.com
Subject: Re: CVE-2014-0475: glibc directory traversal in LC_*
 locale handling

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

Powered by blists - more mailing lists

Your e-mail address:

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

Powered by Openwall GNU/*/Linux - Powered by OpenVZ