Date: Mon, 21 Jul 2014 18:15:43 +0100 From: Stephane Chazelas <stephane.chazelas@...il.com> To: oss-security@...ts.openwall.com Subject: Re: CVE-2014-0475: glibc directory traversal in LC_* locale handling 2014-07-10 16:42:39 -0700, Tavis Ormandy: > Rich Felker <dalias@...c.org> wrote: > > > On Thu, Jul 10, 2014 at 08:52:24PM +0200, Florian Weimer wrote: > > > Stephane Chazelas discovered that directory traversal issue in locale > > > handling in glibc. glibc accepts relative paths with ".." components in > > > the LC_* and LANG variables. Together with typical OpenSSH > > > configurations (with suitable AcceptEnv settings in sshd_config), this > > > could conceivably be used to bypass ForceCommand restrictions (or > > > restricted shells), assuming the attacker has sufficient level of access > > > to a file system location on the host to create crafted locale > > > definitions there. [...] > I knew about this behaviour (I imagine lots of people were), but hadn't > considered it a vulnerability - it's more restricted across setuid, so had > assumed it was intentionally permitted. Locale files are not executable > code, so even if you imagine a ForceCommand+AcceptEnv configuration *and* > have the ability to create a message catalog, don't you still need another > bug to exploit this? [...] LC_*, LANG, LANGUAGE are about setting all the aspect of localisation, not only message catalogs: - character set - character classes (see my other post about bash honouring the [:blank:] characters as token separators, and [:alpha:] as valid variable names. - transliteration (toupper/tolower) you can make "foo" match "bar" case insensitively by making them all map to XXX in uppercase. - sort orders (so that one can make [A-Z] include / or B sort before A) - decimal point (so one can have 123 be understood as 1.3 (2 being the decimal point) - month/day names (newline in a month name for the output of ls -l or date) (as in January is "Jan\n-rw----- 1...") - ... - not to mention the fact that the whole localisation code is quite complex and I wouldn't be surprised if it crashed miserabily on unexpected/incorrect locale data Note that it's not about the ability to create message catalogs but about the ability to upload files with arbitrary names. Most git hosting deployment fulfill all the criteria I'd say. > However, admittedly there was that zonefile parsing vulnerability and IIRC > TZ also permits directory traversal when not setuid. TZ is just as plausibly > part of AcceptEnv as LC_ALL, so maybe if it wasn't intentional there's at > least a weak argument there for calling it a glibc vulnerability. [...] the main problem here I'd say is that those variables are honoured *by default* by most of a Unix tool chest, and the shell to start with (see my other email in this thread about bash), so even "ForceCommand LC_ALL=C some/command" won't fix everything. -- Stephane
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.