[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20140721171543.GA30351@chaz.gmail.com>
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.
