CVE-2014-6271 bash vulnerability

We've been able to patch all of our Linux boxes, but I'm kinda just wondering when Apple will get around to patching this nasty exploit.

While we're all waiting on a security update, protection is at hand:

http://apple.stackexchange.com/a/146851

http://alblue.bandlem.com/2014/09/bash-remote-vulnerability.html

As an aside to anyone reading this message, the links above describe how to download, patch, compile and install your own software. If you're not comfortable doing this on your own computer, either wait for Apple to issue a security update (if they do) or find a friend. It's not enough to just copy and paste commands into your terminal, please take the time to understand what you're doing so you can protect yourself!

I've done this on my iMac 10.9.5 without issue.

I'm wondering if having HTTPS (443) exposed on the internet is an issue. Both the base landing page, and the profile manager login page. I know that apache/CGI can hit this bash vuln.

I had foolishly imagined that the update to "Command Line Tools (OS X 10.9)" released (I thought?) today would fix this. It does not. The referenced fixes do, although, as sjabour said, don't just run those blindly: understand what they do.

As an aside, after patching other Unix systems I care for, I also changed all users' (and, on Linux, root's) shells to something else (I like Zsh, although that may not be right for root in all cases). On Darwin, root's shell is "/bin/sh", but, as with most Linux distributions, that's actually just bash. You absolutely can execute Zsh as sh, and have it behave as an sh-alike, so if you aren't comfortable with patching and rebuilding, but are comfortable with basic SA practice (or you just don't have XCode for whatever reason), you could replace the bash /bin/sh with a hard link to /bin/zsh instead, like this:

% cd /bin

% sudo ln sh sh-real

% sudo ln -f zsh sh

% ls -li sh* zsh

334241 -rwxr-xr-x 2 root wheel 530320 Oct 31 2013 sh

11118 -r-xr-xr-x 1 root wheel 942308 Sep 24 23:53 sh-real

18050387 ---------- 1 root wheel 1228304 Sep 24 23:51 sh.CVE-2014-6271

334241 -rwxr-xr-x 2 root wheel 530320 Oct 31 2013 zsh

% sudo su -

# echo $SHELL

/bin/sh

# /bin/sh --version

zsh 5.0.2 (x86_64-apple-darwin13.0)

#

Serving web pages isn't inherently an issue, and having cgi-bin exist as a concept isn't inherently an issue, nor would this be limited to CGI. If you have any scripting that a web connection can talk to, and that scripting shells out as a user whose shell is bash at any point, that script is vulnerable. (But, um, you shouldn't be doing that anyway, so stop it.)

Right, I'm just wondering if the profile manager login page or the landing page (with wiki or xcode links, even if they are disabled) do any of this. I don't do any custom web serving on OS X.

Oh, fair enough. Beats me, I don't use those things, sorry! (You probably ought to assume they're unsafe, though, unless you've got the facility to do a code audit / pen test on them.)

That's one of the reasons that this particular bug is so dangerous; we just don't know. Not specific to Apple provided services, just anything in general.

If your server is on the internet, patch it. You're safer if it's not, but I'm particularly paranoid and I don't like to take chances and I'd still recommend that you patch it.

You might want to double check that ZSH isn't vulnerable. I ran the exploit check in ZSH on my Mac before patching and saw it was vulnerable. After patching, did the same thing and ZSH was ok.

sjabour, I think you're running this test wrong. No version of zsh has ever been vulnerable to this because it simply doesn't execute functions the same way (yes, I read this code myself, you should too).

Did you do something like this?

err% $0 --version

zsh 5.0.2 (x86_64-apple-darwin13.0)

err% env x='() { :;}; echo vulnerable' bash -c "echo this is a test"

vulnerable

this is a test

If so, you, like many others on the Internet (see https://news.ycombinator.com/item?id=8361574), actually just re-tested bash, because the point there is to pass the function definition buried in the variable x *to* bash: doesn't matter if you executed it from zsh on the CLI.

Here's a valid test (running the known-bad version of bash for my shell, but passing the POC attack to /bin/zsh):

bash.CVE-2014-6271-3.2$ $0 --version

GNU bash, version 3.2.51(1)-release (x86_64-apple-darwin13)

Copyright (C) 2007 Free Software Foundation, Inc.

bash.CVE-2014-6271-3.2$ env x='() { :;}; echo vulnerable' /bin/zsh -c "echo this is a test"

this is a test

Note the lack of "vulnerable" in that output.

PS, the bash "patch" doesn't do sufficient checking: you can still beat it with malformed (eg, no closing curly brace) functions. See https://twitter.com/taviso/status/514887394294652929

Zsh is actually affected as well:

teodor@avalon:~ » echo $SHELL

/bin/zsh

teodor@avalon:~ » export x='() { :;}; echo vulnarable'

teodor@avalon:~ » man ps

vulnarable

teodor@avalon:~ »

No, Teodorlliev91, your test does not prove that. What you've done there is demonstrate that if you set the variable x to a function, export that (so that subshells will get it), and then execute that subshell, the subshell is vulnerable. Your running zsh at the CL has nothing to do with what binary will be executed for that subshell: either your default shell is still an unpatched /bin/bash (check with `finger teodor`), or man executes something as bash internally (plausibly by way of passing off to a script). The latter case isn't great, but it isn't a remote execution vulnerability.

" If you have any scripting that a web connection can talk to, and that scripting shells out as a user whose shell is bash at any point, that script is vulnerable. (But, um, you shouldn't be doing that anyway, so stop it.)"

Actually, I believe the problem is much worse than that, as it appears that simply setting a HTTP header value may get passed through via apache using environment variables - no CGI is needed. If so that's a wide open hole.

See http://blog.erratasec.com/2014/09/bash-shellshock-scan-of-internet.html

This is not an issue for anyone who isn't running a server on the internet. That would be highly unusual for OS X. However, developers who have Apache running are at some risk. There is a patch and rebuild instructions available here: http://apple.stackexchange.com/questions/146849/how-do-i-recompile-bash-to-avoid -the-remote-exploit-cve-2014-6271-and-cve-2014-7. If you don't know how to apply these changes, then you are probably not at risk.

Of course, the rumours are that the current patch is incomplete. There may be a new one soon.

This is unfortunately inaccurate.

For exampe, there are exploits in the wild that leverage DHCP. Suddenly the coffee shop wifi just got a lot more dangerous...