Update: Apple has issued a statement to iMore regarding this issue, stating that most Mac users are already protected unless they have configured “advanced UNIX services.” An update is in the works to protect those users.
A vulnerability in Bash, the software used to control the command shell in many flavors of Unix, has been shown to be present in OS X – with some security researchers saying that the flaw could pose a bigger threat than the Heartbleed vulnerabilty discovered last year (which affected many Unix systems but not OS X).
The Bash vulnerability being referred to by some as ‘Shell Shock’ allows an attacker to run a wide range of malicious code remotely. It was discovered by security researchers at RedHat, and is described in detail in a blog post.
There are conflicting reports as to the extent to which Mac users are at risk …
In a Stack Exchange thread, one user argues that while Macs are technically vulnerable, most are unlikely to be at risk in practice.
Yes you are technically vulnerable. But the reality is unless you allow SSH access from remote connections or a web server that runs server side scripting, you are not at risk. You are only truly vulnerable if someone you do not know can remotely access your machine & do so in a way where a Bash command can be executed.
So this issue is mainly of concern to system administrators on Mac OS X & Unix/Linux servers exposed to the world, not desktop users who do not enable SSH sharing.
Another, however, describes this view as ‘naive.’
… or have an application running, listening on an open port that allows RPC calls to be made that end up running shell commands. This could be any number of things as there are plenty of standard applications that do their RPC. I think this answer is very naïve. It’s very easy to be “running a web server” inadvertently in the course of running an application that does some client-server type thing.
The presence of the vulnerability can be confirmed by opening a Terminal window and pasting in the following command:
env x='() { :;}; echo vulnerable' bash -c 'echo hello'
A ‘vulnerable’ response demonstrates that the exploit works, while a Bash warning would indicate that the code failed.
Several variants of Linux already have patches available.
FTC: We use income earning auto affiliate links. More.
Running a Dev Preview (8) of Yosemite, I seem not to be vulnerable.
That’s very interesting to note, thanks – would be great if others running the preview could also check.
My 10.10 is vulnerable.
I just ran the line and it came back as vulnerable and I’m running Beta 3 of Yosemite.
Thanks, Steven. Now Apple has issued a statement, it’s clear this isn’t a risk for the vast majority of OS X users (see update at bottom).
It is vulnerable. (run “env x='() { :;}; echo vulnerable’ bash -c ‘echo hello'” in terminal)
If it says ‘vulnerable’ then it is.
I ran the command in terminal in Yosemite (developer) not preview version of OSX and I am NOT getting the vulnerable text to display, only the ‘this is a test’
Thanks. It’s looking like Apple has this covered in Yosemite, then. Will be interesting to see if it issues an update for Mavericks and earlier.
I’m running 3rd BETA and it says :
“echo vulnerable’ bash -c ‘echo hello”
also try
env X='() { (a)=>\’ sh -c “echo date”; cat echo
and make sure no date appears
Yosemite latest Beta is vulnerable. Maybe dev preview and general betas are using different versions of the bash binary.
I’m running same dev preview 8 of Yosemite – vulnerable. Default bash.
I’m running 10.10 (14A361p) and I’m vulnerable.
As far as I’ve understood, if your OS is vulnerable (my rMBP running 10.9.5 is) means that any shell script (might be ran remotely if your SSH sharing is enabled or by any program installed that might do such things) so, any command line program, might try to maliciously create environment variables that run commands without your knowledge
Kind of. Basically as I see it this vulnerability allows local regular users to escalate their privileges to root. so the biggest problem to most users is Trojan malware that can invoke bash.
For those who give random but authorized users shell access, either locally or over ssh, you should be hesitant as they might be able to inject bad code. This is likely most problematic at a school with a lot of random users using public access hosts.
I haven’t seen any indications that this is a privilege escalation exploit, unless the process hosting the scripting server is running as root. It is however remotely exploitable by more than just SSH. Most commonly web servers with server-side scripting enabled, or any other service that handles scripting.
Oh, just saw a report from Redhat that the DHCP client in Linux is vulnerable. The DHCP client process (configd) that runs as root on OS X and iOS is presumably also vulnerable. So all you would have to do is attach to a rogue AP. Or, otherwise accept a DHCPOFFER packet with malicious option variables on the network you’re attached to, not good.
No, the OS X DHCP client is not vulnerable.
As it turns out, Mac OS X’s DHCP client doesn’t make calls to Bash in later versions and in ancient, unsupported versions Bash wasn’t included as the default shell, so all is well for DHCP in Apple land.
dhcp clients, for example
think: connect to public AP at starbucks
Enabling ssh isn’t enough. The renegade user needs to be authenticated as well. Otherwise they cannot have ssh invoke a bash shell.
Or, they could have a web server or other application running that executes server-side scripts, there are many out there. That allows a remote exploit with no authentication and it executes in the account that the process runs as.
If you let someone remotely run any arbitrary commands remotely through cgi or any other mechanism you have a huge problem. And that’s without this bug.
If you do web visible stuff, then you are vulnerable.
The majority of OS X users will not be.
Apple will provide an update, though. Just be patient. Mostly those running OS X Server will want to keep an eye out.
The current patch by Red Hat isn’t complete, it still leaves a system vulnerable. So we need to wait for that to be fixed, too …
Worth noting: Ensure SSH isn’t enabled and sharing isn’t enabled if you don’t need it. Most home routers will be blocking the ports for incoming anyway by default.
Yikes. Let’s hope this is fixed ASAP.
There is a fix here… instructions for testing and how to obtain a new version of bash:
http://apple.stackexchange.com/questions/146849/how-do-i-recompile-bash-to-avoid-the-remote-exploit-cve-2014-6271-and-cve-2014-7/146851#146851
You have to have Xcode installed on your Mac in order to recompile the new version of bash
As of this moment, the suggested patch doesn’t fix the secondary vulnerability:
$ env X='() { (a)=>\’ sh -c “echo date”; cat echo
Running Yosemite (Developer Preview, Beta 8) and it is vulnerable.
rMBP running 10.9.5 and getting ‘vulnerable hello’ message. what can I be possibly running that can cause this? I am not a super hacker person, don’t usually use terminal, the only time I used it was to be able do downgrade from Yosemite beta back…
My mothers MBA running 10.9.43 is also vulnerable and she doesn’t even know how to copy paste on OS X because she is still used to Windows..
Your not vulnerable because you did something wrong. Every OS X is vulnerable by default until this is fixed. You just have to wait for an update.
thanks for clearing that up! :)
This is your security problem if you allow users to run commands on your host. However, most people do not. Even people who own and operate web servers do not. But there are exceptions, particularly some classes of hosting providers, who do allow such things.
Of course if one of the services you often visit has this vulnerability and if you have an account there, well, let’s just say you have yet another reason to use multi factor authentication.
I love Apple, they are have been great for years, but what is going on with them? iPhones bending in pockets, DISASTROUS iOS 8.0.1 update, and now this?
That has nothing to do with Apple. It’s bash, which is not from Apple and installed on almost every Linux and Unix (OS X is Unix).
? Do people commonly give shell access to others? Pssst. Anyone with malicious intent with any kind of shel access is always bad news.
Talk about hype and blowing this vulnerability out of proportion.
patch for certain OS’s is out already (not OS X though) https://www.us-cert.gov/ncas/current-activity/2014/09/24/Bourne-Again-Shell-Bash-Remote-Code-Execution-Vulnerability
I am running the latest DP of Yosemite and running that shows I am vulnerable
The first response is obviously more reasonable, the second is pure paranoia and pedantry.
Not really, people install client/server stuff all the time not realizing how it works, just like he said. Then, they turn off their software firewall because someone told them once that it was breaking some app. There are also routers and other embedded devices that use Unix/Bash/CGI all over the place that won’t even get a second thought by regular users.
There is a fix here… instructions for testing and how to obtain a new version of bash:
http://apple.stackexchange.com/questions/146849/how-do-i-recompile-bash-to-avoid-the-remote-exploit-cve-2014-6271-and-cve-2014-7/146851#146851
As noted below, the issue is that any Mac can currently be owned by a malicious DHCP server (which can send malicious data which are turned into environment variables and then executed as root by bash when the Mac’s DHCP client, running as root, invokes a bash script) which someone could run on a public wireless LAN, for example Starbucks or an in airport.
As also noted, this is a problem which probably affects most Unix distributions, for example a Linux or FreeBSD machine running dhclient as root and invoking ifup/ifdown or other bash scripts.
Apologies for typos – unfortunately comments aren’t editable, but you know what I was trying to say. ;-)
Only OS X 10.0.x appear potential vulnerable to shellshock attacks via DHCP. http://complexitydaemon.wordpress.com/2014/09/26/bash-os-x-dhcp-and-you/
Erich correctly pointed out that 10.0.x used tcsh not bash as the system shell, so that’s not affected either. I have updated my blog with the latest findings incorporating that and his other feedback on bootp being replaced by configd.