Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140924164253.GL3267@sentinelchicken.org>
Date: Wed, 24 Sep 2014 09:42:53 -0700
From: Tim <tim-security@...tinelchicken.org>
To: oss-security@...ts.openwall.com
Subject: Re: CVE-2014-6271: remote code execution through bash


>  >> 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.

tim

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.