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.
Powered by Openwall GNU/*/Linux - Powered by OpenVZ