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.