Re: CVE-2014-0475: glibc directory traversal in LC_* locale handling

[Stephane Chazelas <stephane.chazelas () gmail com>]

2014-07-10 15:09:30 -0400, Rich Felker:
> 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.
>
> Am I correct in assuming this affects most typical git setups (e.g.
> gitolite) using ssh authorized_keys files with forced commands, where
> the malicious file could simply be created as part of the git
> repository? Or are these usually setup to filter the environment?
[...]

It does affect git setups. You may run into the issue even
*before* the git command is run on the server.

As I mentionned in my initial report, the issue is agravated by
several misfeatures in openssh and bash.

openssh runs the supplied forcecommand with the login shell of
the server user instead of just "sh". So, crafted locales can be used
to affect the processing of those shells.

That is especially a problem with bash (the shell of the GNU
project which is even still used as /bin/sh on some systems and
the default shell for adduser on most GNU/Linux systems and
others).

With bash (even when not interactive and even when called as
"sh"), LC_CTYPE is used for the parsing of the command line.
For instance the "blank" character class is used as token
delimiters, alnum to validate variable names...

For instance, with a forcecommand=/bin/false, one can turn that
into an "ls" by making all the "/bin/fae" characters "blank"
characters (yash also has the problem).

bash (though not when called as sh) explicitely reads ~/.bashrc
(and /etc/bash.bashrc or equivalent) when called over ssh. With
the typical /etc/bash.bashrc found on Debian, I could craft a
locale that made that executes "sh" when interpreting it.

gitlab allows you to upload files (attachments to comments), the
files are stored on the server with the name provided by the
client, and the path to those files on the server are easy to
guess.

With a gitlab user on the gitlab server with "bash" as the login
shell, I could get a sh prompt on the server, with none of the
gitlab code being involved.

I suspect other git server implementations are affected.

regards,
Stephane