Malware + Recommended + Security News

Shellshock Vulnerability: What Mac OS X Users Need to Know

Posted on September 26th, 2014 by

Shellshock vulnerability Mac OS XThe vulnerability is called Shellshock, and it has rocked the security industry to its core. A flaw in the “Bash” shell—the command line interpreter for Unix-based systems including Linux and Mac OS X—has sent server administrators scrambling to patch their systems.

Security experts are saying this vulnerability is as dangerous, if not more so, than the Heartbleed flaw found in OpenSSL software—an encryption service used by around two-thirds of websites to protect information sent to and from web pages—back in April. The Shellshock flaw affects the Bash shell used across many Unix-based systems including Mac OS X and variants of Linux.

The Shellshock vulnerability (CVE-2014-6271CVE-2014-7169) has been compared to Heartbleed, partly because the software at the heart of the “Shellshock” bug, known as Bash, is also widely used in web servers and other types of computer equipment.

With Heartbleed, somebody could grab credentials of a user and do what they wanted with it; however, the bug only allowed an attacker to steal data. But with Shellshock, if someone is vulnerable, an attacker could insert malicious pieces of code from a remote location and get full system control of a victim’s machine.

Fortunately, the Shellshock vulnerability is unlikely to affect as many systems as Heartbleed, because not all computers running Bash can be exploited.

How to tell if your Mac is vulnerable

If you have a Mac OS X or Linux system, open the Terminal and run this line of code:

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

If it returns the word “vulnerable” as an answer, then your machine is in theory vulnerable.

Mac OS X vulnerable to Shellshock

Here’s what that means, as mentioned over at Engadget:

Your Bash shell is simply running more code after a function (the “() { :;};”part), and that shouldn’t be happening. The function is the “allowed” code, while everything after it is where the potentially “malicious”code could be installed.

But—this is important—if your Mac is “vulnerable,” all this means is that your default shell is Bash. The only way for infections to occur is by exposing this vulnerability on a Mac.

If someone were to write an app that contained the exploit, a user downloaded the app, bypassed Gatekeeper (it would have to be an unsigned, unsandboxed app) and ran the app anyway, then yes—a Mac user could potentially get malware this way.

What exposes your Mac to Shellshock

There are two routes to exposing this vulnerability to a remote attack on a Mac:

Route 1

  1. Go into System Preferences > Sharing and turn on Remote Login
  2. In the same location, turn on All Users
  3. Go into System Preferences > Users & Groups and make sure Guest Access is enabled

Your system is now vulnerable. If you don’t enable guest access your system is still vulnerable if the attacker knows or is able to guess your username and password. But as this connection is secured, they can’t get that from packet sniffing. And enabling a guest shell on a box is probably not the most secure thing to do anyway.

Route 2

This route requires OS X Server, an old (Lion or earlier) version of OS X, or for the user to install Apache/PHP/some other scripting environment.

  1. Enable Apache and have it running
  2. Enable Apache to run scripts or execute extensions
  3. Have one of those scripts or extensions vulnerable to malicious attacking (being able to inject something into the script that gets executed)

The attacker can then insert the variables into the script or extension that gets run under the Bash shell, then the injection gets into the Shellshock vulnerability, and voila—machine compromised. This one, however, requires exploiting two holes. First, in the script running on Apache, and then in turn using that compromised script to send something to the Bash shell.

What this means 

As you can see, these are both edge cases. And both routes probably require a level of technical expertise that the person configuring their account as such can patch the exploit fairly simply.

Also note that for route 1, enabling a Bash shell with Guest access for remote login most likely opens up your system to many other possible attacks. The difference Shellshock provides is access to root privileges, in other words full machine access to said Guest user.

The bigger issue is all the devices with embedded Unix, where telnet (unsecured) access is enabled, and no login is required. These typically are “The Internet of Things” (IoT) devices. Even if they require an administrator password other then “Admin” to get change settings, Shellshock may now give the attacker root to do whatever they want on the device.

What can an attacker do to your Mac?

Basically, an attacker can run code by simply asking for basic information from your computer, a server or an IoT device. "The remote execution (over the Internet or a network) of extra code could let an attacker load malware on a system and steal private information, delete files, activate your camera, open a lock and, well, do pretty much anything with a little know-how," mentioned Jose Andrade at Engadget.

However, the Engadget article also mentions “your computer is most likely unaffected” if you are running a firewall that blocks external requests not initiated locally by the software already authorized to run. This suggests that if a Mac is running firewall software, such as Intego NetBarrier, it has not been proven possible to take advantage of the bug under that scenario.

Unfortunately, the Bash Shellshock bug is wormable, and can easily worm past firewalls and infect lots of systems, according to Robert Graham at Errata Security. Robert explained:

“One key question is whether Mac OS X and iPhone DHCP service is vulnerable –once the worm gets behind a firewall and runs a hostile DHCP server, that would be ‘game over’ for large networks.”

And, worse, protecting a server is another issue but different, because a server must listen to requests in order to do its job. Engadget's Jose Andrade provided a good overview of this problem:

This means that by requesting almost any data and running malicious code, an attacker can infect any affected server, which is about 60 percent of web servers out on the internet, most routers (even your home router) and many consumer devices (including security cameras and "smart" appliances -- which don't seem so smart right about now). This is because smart appliances are a form of servers.

Have hackers figured out how to exploit the Shellshock vulnerability?

With the media spotlight on the Shellshock vulnerability, in just one day after discovery, hackers have most likely figured out how to exploit it. Intego has seen proof-of-concept exploits so far on Mac OS X, and we are continuing to research this threat and will continue to provide updates as new information becomes available.

How can the Shellshock vulnerability be resolved?

In a statement to iMore, an Apple representative disclosed the following:

The vast majority of OS X users are not at risk to recently reported Bash vulnerabilities. Bash, a UNIX command shell and language included in OS X, has a weakness that could allow unauthorized users to remotely gain control of vulnerable systems. With OS X, systems are safe by default and not exposed to remote exploits of bash unless users configure advanced UNIX services. We are working to quickly provide a software update for our advanced UNIX users.

According to Apple, there is a patch coming soon for Mac users who could be exposed.

What can you do to stay protected?

Until Apple patches this hole, which they no doubt will, you can take a few simple steps to make sure you’re not exposed:

  1. Don’t enable Guest Access AND at the same time enable All Users for Remote Login.
  2. Don’t run a Web server on your personal machine.
  3. Have a strong password on your Account.
  4. Keep Gatekeeper turned "On."
  5. Only install or run signed Apps from trusted sources.
  6. For extra protection install a Firewall, such as Intego NetBarrier.

UPDATE: Apple’s OS X Bash Update 1.0 Patches Shellshock Vulnerability

Also remember, these are probably good security rules to adhere to even after Apple patches this hole, just to insure you don’t fall victim to the next one yet be discovered.

Where to get more information

US-CERT recommends Mac OS X users (and pretty much anyone concerned about the flaw) seek help from the Redhat Security Blog, or consult their respective Linux or Unix operating system vendor for advice.

  • Henry

    Wish I knew how to open Terminal.

    • Antony

      You don’t need to open a Terminal to get hacked in that way. It can run in the background for all we know. That’s why Shellshock is more serious than Heartbleed

      • Coyote

        He means he isn’t sure how to test it. And of course it can run in the background. You DO know it (and if you mean that in a way of “you might not know it is there but it still is” then I would argue that that is the only way it would happen anyway unless you are in a test environment).

        • Antony

          Because of the way how UNIX system works.. one app can call another app to parse data…you may be using an app without knowing that it is doing something in the background.

          • Coyote

            I know. I’ve used Unix for ~20 years. And frankly, it isn’t just Unix systems that have this. Indeed, that is why there are cpu/task schedulers, context switches, etc. (Edit: more specifically, that these exist is because CPUs run multiple tasks. And even more, there is the fork syscall, for example, which can run another program which can run… etc. But this isn’t Unix specific by any means)

            That still isn’t my point though. The point was: if he knew how to open a terminal he could then determine IF he was vulnerable. That is what I meant. Whether he did indeed mean that is not relevant to my point.

          • Coyote

            I could have sworn I responded to this some days ago but nothing here. So in the case it didn’t go through, here is what I remember:
            Yes, I know. I’ve used Unix (from SunOS and Solaris, several of the BSDs, many different distributions of Linux, to name some) for near 20 years. My point was that HE did not know how to open the shell in order to test HIS machine.

            Of course programs can call another. That’s what an operating system does (among other things). And Unix has the fork syscall which combined with pipes is very, very powerful (it is powerful on its own still). I’m a programmer for Unix (nowadays only Linux distros) for years and in fact use the above mentioned functions. Basically, this is the power of operating systems. Without context switching, having one program run another, etc., computers would be very boring indeed. For what its worth, I explained the bash bug to some at Graham Cluley’s site (in comments). My point was not about me but instead about Henry (and more than that suggesting what he was trying to get across).

  • Henry

    Found Terminal, entered the line of code, and got this result: -bash: syntax error near unexpected token `(‘

  • David A. Woodbury

    Every apostrophe in the recommended line of code above — env x='() { :;}; echo vulnerable’ bash -c ‘echo this is a test’ — needs to be a plain apostrophe, not a stylized, curved one that most fonts substitute automatically. The stylized apostrophes return a syntax error in Terminal. I had to copy the line from this article and then paste it into an HTML editor (I used BBEdit) in order to replace the curvy apostrophes with plaintext straight ones. I’m running a 2011-era iMac with the new Yosemite Beta version of OS X, and once I fixed the apostrophes my system returned the result “vulnerable.” (Thank you, Intego, for the good info in this article.)

    • Intego

      Thank you David, we have updated the line of code to be plain text. Copy/pasting it now works as expected.

      • AJW

        ok, so what happens after I run this, get the ‘vulnerable’ answer, then check my system prefs where I find that guest login was enabled (I promptly disabled it and relocked my preferences), but that I had not enabled any remote login?.. I run the most current Intego premium bundle with Netbarrier on an iMac and have incoming internet connections blocked and OSX Mavericks firewall turned on as well. After checking all this I re-ran the code in terminal and it still said I was vulnerable. What am I missing?….

  • Norman Callaway

    Finally, a straight-forward explanation of the threat vector from the user’s perspective. Little media hype and no “don’t worry my child” assurances from Apple. Great job Derek. Thanks!

  • Pepper1311

    No update from Apple on site! Why email to claim one exists?

  • Kone Jkurious

    Just a quick THANK YOU for keeping me out of trouble… Appreciate your providing solution.

  • REReader

    Thank you for the very clear explanation!

    Unfortunately, I am stuck with OS 10.6.8, for which Apple has not provided a patch. I have seen elsewhere a way to patch Bash by installing XCode and then updating Bash using Terminal. That involves messing with the underlying OS code, though, which makes me nervous. Do I need to do this?

    I have never enabled remote login, and the only guest access enabled is to read files in my public folder, and I don’t run a Web server. I don’t have Gatekeeper (as I’m running 10.6.8!), but I don’t download random software. And I’m running Intego VirusBarrier and NetBarrier with an up-to-date subscription to update virus definitions. Do you think I’m good enough to be able to not have to mess with the Terminal? (My computer DID come up as “vulnerable” running your Terminal test.)


    • Coyote

      Apply the update as soon as you can. That’s your answer; yes, it is a problem, always has been and always will be, to let a security flaw (or in general any flaw) live (especially when there is a fix). It doesn’t matter if you think you’re safe or if you have the protections in place. There is ALWAYS something else and not keeping this in mind is risking being bitten hard.

      • REReader

        I tried, two different ways in fact, and I can’t get them to work.

  • Jim

    I wish someone would tell us how to deal with this on Snow Leopard systems. It seems that Apple has finally abandoned us completely.

  • susankbecker

    Ditto, REReader and Jim! I run OS X 10.6.8. Are OS X versions 10.6.8 and older not vulnerable to Bash? Does Apple not care?

    I’d appreciate any light Intego could shed on the vulnerability to Bash of OS X 10.6.8 and older versions. Apple’s view that systems are safe “by default” is inconsistent with my worldview.

    Meanwhile, what do we do? I ran the Terminal code and got the response that my system is vulnerable.


  • Coyote

    To those still wondering: this is a really old bug and yes older systems are vulnerable. For example, CentOS 7.x, which was recently released – past few months – is (could check 6.x but it requires a remote login to that server and I’m about to leave for the day) 4.2.45 and Fedora Core 20 has 4.2.48 and yes both were patched the same day (actually only half-way true: there were two exploits… the first one was fixed which was the most important and that was fixed before the major announcement, as I recall – the next day it was announced and there was another update then). And as far as I am aware, Apple has a much lesser version. Indeed there is the issue of backports but whether Apple does this or not I do not know (and is irrelevant since the flaw is old).

    What I do know is: this is a very old kind of flaw, bash is not the first and will not be the last (remote and otherwise) and more importantly, bash isn’t the only one (shell) at risk. And whether your shell default is bash or not is also irrelevant! You can specify the shell if you know enough (which really isn’t much for this!). So I would suggest that older systems are indeed very much at risk.

    “If it returns the word “vulnerable” as an answer, then your machine is in theory vulnerable.”

    It is not a theory. It IS vulnerable. What might be the case is there might not be a way to exploit it from the outside. But that doesn’t mean it cannot be done and furthermore it does not mean there is no vulnerability. Suggesting otherwise is dangerous indeed. I can think of other old examples of this type of flaw that wreaked havoc for many administrators (arbitrary command execution is very serious and even worse when it is remote) throughout the years. Lastly, remote login is something for specific needs and shouldn’t be done in general unless there is that need (servers come to mind). Just as an aside that should be kept in mind. This goes for web servers too – if you don’t have a need for it and/or you don’t have enough experience with it, you are – and yes the pun is well intended – very much risking opening another can of worms.

    • REReader

      We get that this affects our systems, Coyote. The problems is that not Apple is not issuing a patch for older systems, and not everyone knows coding or how to mess with Terminal.

  • susankbecker

    Thanks, Coyote, for your detailed and clear responses! The Security Blog didn’t send me your month-old reply until today, with your reply this week, so I was unaware until now of your very helpful comments to others in the thread.

    Terminal is not an option for me. I know enough to learn that my system is vulnerable but not enough to address the problem.

    Love your suggestion to “bug…Apple”! Now to your reply of 3 days ago, with many thanks…

    • Coyote

      You’re quite welcome. And yes, I love puns (thanks, by the way – glad you appreciate it… some don’t like puns, interestingly) and am constantly creating them, pointing out to others that they just made a pun (when they didn’t know it… or if they know it I still remark on it) and probably to the point that it – well, here we go again – bugs some people. I’ve always been quick witted (combined with a dry, sarcastic sense of humour) and I know this because of stories my parents told me of when I was still a toddler. Will get to your other response in a moment.

  • susankbecker

    Coyote, you’re very kind to add the response above, especially when I hadn’t seen or replied to your first one to me.

    Your perspective on updating to a new OS X system is very balanced and sane. My OS X system purchases hsve been app-driven: If an app necessary for my consulting practice won’t run on my OS, I buy the latest OS X version. Your comments throughout this thread have convinced me to factor security into OS purchase decisions, too.

    Many thanks !

    • Coyote

      I’m glad I could help. Yes, security should always be kept in mind. But I’ll tell you this, too: no matter how much foresight you may have, there is never enough. And everyone is guilty of (more like “prone to”) neglecting something important (or missing something). Even with ~20 years in security (and longer in programming and computers more generally), I make mistakes, always have and always will. This includes really amateur mistakes, too. That’s just the nature of being human: not perfect by any means. But I accept this and learn from it. Experience does not necessarily lead to following best-practise. That goes for no matter how experienced you are (and no matter what it is in question). I’m glad I could convince you to keep security in mind. That is exactly what I mean: the biggest mistake is being unwilling to improve yourself (or accept other view points, another person’s experience/thoughts). And that you’re able to do that is a very positive and commendable trait. So good on you (+ keep it up)!

      As for the fact I added the response:
      Well do not worry about it (though, I definitely appreciate you remarking on it, see below). I had the time and I tend to (and enjoy and also feel the need to) share knowledge and experience where I can (and never try to cover up not knowing something – if I don’t know something and I refuse to acknowledge it, I won’t learn.. and why add confusion/unhelpful “facts” to someone who is trying to learn or fix something? That is wrong, as far as I am concerned. If I don’t know the answer to something, and I know they don’t know what “42” means in that context, then I will help both of [us] by being honest). I strongly believe in openness (in computing anyway… ironically I am fairly closed-minded in general) and it is why I have sent in patches (to add features, say) to open source software or… do programming without expecting (and in fact not wanting) pay and so on. So I’m glad I could help. I appreciate (a lot) the appreciation – too many people (>= 1 is too many but it is unfortunately much more than one) do not know how to (or they neglect it) show appreciation or even say/write (show) thank you (thanks). So thank you for thanking me! Some might view that as silly – me thanking you for thanking me – but being unappreciative and taking things for granted, is something I loathe.

  • REReader

    Not the Apple fix, because Apple is not offering a fix for 10.6.8. I tried to apply fixes using the terminal, from here:

    and from here:

    And what “didn’t work” means is that I got a great number of messages saying that the names of the files couldn’t be changed, and the vulnerability tests all came back as still vulnerable.

    • Coyote

      Ah.. Yes, well, that they aren’t offering a fix is unfortunate but it goes for all software – there is a point where it is no longer reasonable to maintain, update or otherwise work with. Of course, for a corporation (e.g., Apple) you also have the profit aspect. For GNU (which bash is licensed under) and many Linux distributions, it isn’t so much profit as what is reasonable. Example CentOS has a life time of 10 years (it is special in that it is meant for servers, primarily, and notwithstanding security fixes, there are less updates). Fedora Core has 2 years and then no updates. Both are free and both are based on Red Hat Linux. So it really varies.

      There’s two ways to look at your issue (and others who have the same issue), I think. (Although obviously the best option is of course upgrading).

      1. It is a really old bug. Other shells are also affected. In addition, if you don’t run services (e.g., Apache) and don’t allow remote logins (and are careful with local logins), you’re less likely to be attacked (for obvious reasons). In addition, you’re no worse off than before (with exception of it is known but see next point). The key thing here: even if it wasn’t public it didn’t make you any safer… not known does not mean security (too many miss this) and in fact it is a false sense of security (when trying to mask the unknown or what some think is unknown or hidden as security… “security through obscurity” more or less).
      2. If you know enough to fix it yourself, fine. But I understand not all computer users will be in this category; indeed, most users just want things to work and that is that.

      It might not be the best set of options but they are the only options for now, so do what you should do anyway: always be careful, always update (what you can) and be aware that there is no such thing as 100% security – not even close (and when you know this you can act on it in the best way… issues are inevitable but the more you understand the better you are off).

  • REReader

    Thanks for your replies above and below–I only just got the email notices yesterday.

    In the end, I had to wipe my hard drive, reinstall 10.6.3 from the disk, update it up to 10.6.8–and THEN I could apply the patch, which refused to just work beforehand. Then I migrated all my files and apps from Time Machine–which took another day (and a 3-hour phone session with two different Apple Senior Techs, who didn’t even charge me and my years-out-of-warranty machine, go Apple Customer Service!) to clean up.

    But it does seem to be patched now, or at least as patched as any other Mac OS.

    • Coyote

      Glad you got it sorted. It is unfortunate you had to reinstall but at least you were prepared enough (backups). Hopefully you had the backups prior and (if not) you will for the future. In the end, all software must come to an end… whether it is good or bad software, whether it is good to the users or bad (to the victims)… it eventually ends. In the case of software that isn’t malicious (or similar), it is for the best, too, because there comes a point where you just add layer after layer… and bug fix on bug fix on… and basically you are making things so much more difficult to maintain (Microsoft are experts at this). As I think I noted, even non-commercial software developers (e.g., different distributions of Linux) have a life period (and beyond that updates won’t work). But for Microsoft – or in this case – Apple, it is also an issue of profit.

      What matters most, though, is this: you took care of this problem. Some would just shove it aside, forget about it or “try to wish it away” even if they could fix it (whether by upgrading or…). I think the best example (‘award goes to’) is the good old UK government paying Microsoft an absurd amount of pounds for a single year worth of updates (of XP), citing that they’ll be saving a lot of money (I guess when they upgrade to the next Windows they are getting money back, perhaps giving them a large bonus… )…you took care of (this) in a responsible manner. That is something many neglect. Good on you (yes, I am sincere and yes it is unfortunately true, the above… too many really don’t address problems/mistakes/etc., when in the end problems/mistakes/etc. are expected from time to time – no one is immune to it). This is so appreciated by me and I would imagine many other administrators… the amount of scans/mail relay/attack attempts (to name but three) due to insecure systems and the amount of traffic they generate, is extreme. While I can cope with the attacks/etc themselves, I don’t appreciate the logs being filled (example) and neither do I appreciate the other wasted resources. That all might seem a bit too much from me, but make no mistake: I genuinely do appreciate it, a lot, and it really is as I describe – a huge amount of resources are consumed in very little time (even low profile servers can see thousands of connects/etc., very quickly, more often than one would like to believe).

      Glad I could offer my thoughts, help in whatever way – the intent was there, regardless of how successful I was.

      • REReader

        Your link was very helpful–that’s the fix I used, ultimately.

        (And yes, I already had backups, three Time Machine backups–one offsite–and a clone. I’m a maniac for full backups! My dad, who wrote operating systems for Control Data starting in 1961, taught me that by turning off the power while I was using my first computer, a Kaypro. Never forgot to save or backup again!)

        • Coyote

          Love the story. I did similar although there’s more to it than that and I’ll just end “that” right there. Glad the link was helpful. Also glad you do have backups – it is a hard habit to get in to and especially if you don’t have it automated but it is an important habit that too many neglect. I sometimes save too often (or some would consider it that), especially considering power outages don’t actually cause a shutdown for me (exception is a dirty signal that the UPS catches and then I want it to shutdown, which has indeed happened before). Still, I wouldn’t change it even if sometimes it is every few changes in a file. It could theoretically slow me down but it really doesn’t.. what slows me down is the drug called sleep deprivation, not typing.

          Did your father work on a (one or more) well known OS then ? (Of course, you don’t have to respond here or at all.. but I’m the human version of the curious cat… especially with computers, phones – well, landline phones, not so much mobile – and science in general).

          Either way, glad I could be of help. I don’t follow Mac security nor Windows security – I just have an rss feed for G. Cluley’s site and that’s how I came across this page. (Open source security, bugs, etc., is what I primarily care about exactly because I’m in that community, directly and indirectly).

          Kind regards.

          • REReader

            My dad worked for Control Data, and worked on the OSs for their supercomputers (he was, quite literally, the last man standing in the NYC office–for a while he was the only employee still working for them, maintaining their systems). I think they were all or almost all tailored for the purchasers–I remember him commuting out to NJ for a while, working on the OS for NOA in the 70s or 80s. So, none of the big commercial ones.