Hacker News Reader

Comment by kalops | Hacker News Reader

so basically turn off AcceptEnv in sshd_config?

Also don't use bash for running any scripts. You never should anyway, in a sane environment /bin/sh should not be bash - in Debian/Ubuntu it is dash which is not vulnerable. Unfortunately the Redhat derived distros do use bash as default /bin/sh. In the BSDs it is a standards compliant posix sh too. bash is for users not scripts.

> in a sane environment /bin/sh should not be bash

Why, other than it is not the shell of the day?

First it encourages people to use bash specific stuff that is non Posix. Second it is a huge bloated bit of code thats ok as user interface, but scripts should use something that is more minimal. To avoid this sort of issue.

> scripts should use something that is more minimal. To avoid this sort of issue.

Are you also against Perl and Python or does this scripts should be minimal only apply to bash?

> First it encourages people to use bash specific stuff that is non Posix

That's not a problem for most people.

These are reasons you don't like bash, not reasons to not use bash.

/bin/sh is the shell called by system(3) and used by portable scripts bundled with packages. Those things can't use anything but standard sh anyway, so having them run bash is overkill. "Don't use bash as your /bin/sh" isn't the same as "don't use bash as your interactive shell" or "don't write bash scripts"

And don't put #!/bin/bash at the top of your scripts.

And don't shell out in eg. Perl, or PHP, or Python, through bash.

Or just take a patched bash.

> In the BSDs it is a standards compliant posix sh too.

In FreeBSD, it is tcsh in sh mode. Bash does the same too when invoked as sh[0]. It's POSIX compliant with extensions. There's still all the shell's code there, it's just that some of it is switched off by default, or its behaviour modified, to be compliant.

[0] http://www.gnu.org/software/bash/manual/html_node/Bash-POSIX...

Dash sucks, bash rocks. Dash isn't even close to being as capable of a shell as Bash.

Anyone able to express how this affects the default client configuration on Mac desktops and servers?

I guess I'll answer one part- so if you run this: $ env x='() { :;}; echo vulnerable' bash -c "echo test" in your terminal, you certainly appear to be vulnerable.

But I'm not knowledgable about all the default scripts that launch things on the mac. It's unclear to me if there are any standard processes on OSX that take advantage of Bash

By the time AcceptEnv has any effect, the user is already logged in and can run whatever they want anyway. If you're allowing untrusted users to authenticate to ssh, then, yeah, sure, but you'd be in a niche (and know it).

Don't forget SSH_ORIGINAL_COMMAND. GitHub and BitBucket had an exciting morning...

I don't think so. From what I've been reading it can be exploited via http requests. I'm sure a metasploit script is right around the corner.

Edit: oh looks like only like mod_cgi related stuff is.. thats good then sort of

It can potentially be exploited via anything that shells out to bash with an environment that contains environment variables with values (that ultimately comes from) an untrusted source.

mod_cgi is just one of the most obvious attack vectors.

Any software where adversary-controlled input can set environment variables which then execs bash is affected. mod_cgi is just really easy to exploit.

Reply on news.ycombinator.com