Looks like no one’s replied in a while. To start the conversation again, simply ask a new question.

CVE-2014-6271 bash vulnerability

more info on this here:

http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-6271

http://www.reddit.com/r/sysadmin/comments/2hc5rk/cve20146271_remote_code_executi on_through_bash/


I'm assuming Apple will release a security update for this on supported versions of the Mac OS but in the meantime, is there a fix that we can apply? What is an easy way to patch this on older OS versions that Apple is no longer supporting? (perhaps something short of recompiling bash)

Posted on Sep 24, 2014 2:44 PM

Reply
43 replies

Sep 24, 2014 5:00 PM in response to alternapop

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.

Sep 24, 2014 9:13 PM in response to sjabour

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)

#

Sep 24, 2014 9:12 PM in response to zxLFx2

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

Sep 24, 2014 9:20 PM in response to zxLFx2

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.

Sep 24, 2014 9:37 PM in response to sjabour

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.

Sep 25, 2014 7:03 AM in response to TeodorIliev91

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.

Sep 25, 2014 8:51 AM in response to grammar

" 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

Sep 25, 2014 10:25 AM in response to alternapop

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.

CVE-2014-6271 bash vulnerability

Welcome to Apple Support Community
A forum where Apple customers help each other with their products. Get started with your Apple ID.