Re: CVE-2014-6271: remote code execution through bash

[Rich Felker <dalias () libc org>]

On Wed, Sep 24, 2014 at 09:42:53AM -0700, Tim wrote:
> >  >> I see no good workaround. Starting the forced command with
> >  >> "unset >SSH_ORIGINAL_COMMAND &&" does not help - we'd need
> >  >> to unset the variable before starting bash, not from bash.
> >
> >  > Won't installing dash and setting the shell of users who have
> >  > forced commands to dash mitigate this somehow?
> >
> > Possibly, that will require making /bin/sh symlink to point at
> > dash (or zsh, or whatever) as well...
>
> Right, and it makes sense to do this.  Bash doesn't belong as /bin/sh
> to begin with.  It's slow to load, uses 5 times as much memory as dash
> and doesn't exactly encourage you to write posix-compliant shell
> scripts.  Bash's redeeming qualities lie in it's UI, not in it's
> non-interactive scripting.

Indeed, this really should be part of the recommended mitigation for
preventing similar issues in the future. Bash is much larger and more
complex (and obviously, doing idiotic things like parsing and
executing code out of environment variables during startup) than what
I would consider the level of reasonable/acceptable risk for code
that's going to be involved in processing untrusted input.

There are several alternatives available to provide /bin/sh such as
Debian's dash, Busybox ash, mksh, and perhaps others. These should
also work well as login shells for users with forced commands (e.g.
gitolite type use).

Certainly applying the Bash patches (if they fully fix the issue by
removing the parsing and execution of code from env vars, rather than
just "fixing" the parser) is the mechanical "fix" for this issue.
However I think eliminating the use of Bash where it's not needed and
using alternatives (and at some point, auditing those) is the better
direction to take from a hardening perspective.

Rich