[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <53C3A970.7070007@redhat.com>
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
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.
