How to resolve Shellshock on Mac OS X, web servers and more

A serious software vulnerability called the “Bash Bug” or “Shellshock” has just come to light and it affects a wide range of computers and digital devices, many of which will need to be fixed to prevent them leaking information or being taken over by malicious persons. The systems affected include Mac OS X computers, many web servers, and some home networking devices like routers. This blog post offers some preliminary advice about what to do in response to Shellshock, as well as links to more in-depth resources that should be helpful to more technically-minded readers.

[Update: Apple has released “OS X bash update 1.0” to protect Mac OS X systems from this problem. Now available for: Mavericks, Mountain Lion, and Lion. Users of Mavericks should note that there was a recent OS X upgrade from 10.9.4 to 10.9.5 and you must install that before installing the bash fix.]

[Update: New Knowledgebase article: What is Shellshock and does ESET protect me from it?.]

What is the problem?

The official name of this vulnerability is the GNU Bash Remote Code Execution Vulnerability (CVE-2014-6271) and it is a serious one, on a par with Heartbleed, and it could enable an attacker to gain control over a targeted computer. Of course, all of that might sound irrelevant to the average Internet user who has never heard of bash. So I will let my colleague Cameron Camp, an experienced Linux user, set the scene with five main points. After that we will offer some advice for different groups of people affected by this bug. Here’s Cameron:

  1. Bash is short for Bourne-again shell and it is the command line interface that most folks use on a Linux and sometimes BSD Mac servers and computers. So basically Bash is the primary way you give your Linux server commands, turn stuff on and off, start web servers and so on: it’s how you manually manage your server 90% of the time. Think of it as what your desktop is to a Windows or Mac machine, but for servers. But Bash is more than that, it’s also the nuts and bolts of how a large chunk of the Linux server itself launches and controls operations that it executes all the time like scheduling tasks, doing updates, and the like.
  2. Bash doesn’t just run on normal Linux serverish things, it’s loaded on a significant percentage of home routers, smart meters, smart appliances, smart cars, and other stuff that you don’t really think of as running Linux. Basically a huge chunk of things that route Internet traffic run bash. This extends to the core routing of data centers and facilities like that around the world.
  3. Right now we are at the very beginning of the “what could this break” cycle. Already we know that it could break CGI scripts running on Apache boxes. Okay, but there’s a ton of other exploits possible once someone weaponizes this, and before folks have a chance to patch their devices. Some vulnerability scanning is now going around, undoubtedly lots more will follow. Keep in mind that some BSD/Linux boxes haven’t been rebooted in five years or more! They often lag behind on updates to fix security issues.e
  4. I’m watching the traffic stream on some trust groups right now and the messages are flying around, with folks sharing data back and forth about active exploit attempts, so that’s good, but these groups are very technical, so that information has to be translated for public consumption accompanied by practical advice.
  5. Lastly, in simple terms, breaking Bash means you can tell a server to execute something without really authenticating, so it’s sort of like telling bash to go do stuff without being logged in, which definitely fits the definition of “a very bad thing”.

Where can I get more technical details?

How does it affect/impact me?

  • Windows users: your machines are fine, but you could be at risk of malicious code infection when visiting web servers compromised by exploitation of Shellshock. Now is a good time to make sure your anti-malware is up-to-date.
  • Mac users: sadly the bash that comes with Mac OS X is vulnerable until patched. We are awaiting a patch from Apple. Look for this and install it right away. Now is a good time to make sure your anti-malware is up-to-date.
  • Home Internet users, domestic network operators: We do not yet have a definitive list of which devices are affected. For now, assume that yours is and stand by for updates from your ISP or the router manufacturer while monitoring sites like We Live Security for more information about active threats exploiting this vulnerability. If you want to be pro-active, check out the support forum for your ISP or router vendor. Email or phone them to find out if your device is affected. Also, check that your anti-malware is up-to-date.
  • SOHO and SMB: Same as above if you are doing your own IT. If you use a Managed Service Provider, check with them.
  • IT departments: Review all systems that use bash and follow appropriate remediation steps as reported by Linux distributors, such as RedHat and Debian and Ubuntu. There is a lot of information on this NGINX page and this Cisco page.
  • Anyone with a website hosted by web hosting company: Check their support page for news and updates.
  • Anyone with a virtual private server: Check with your provider’s support page. You may need to tackle this issue yourself, in which case engage an appropriate expert.

We are monitoring developments related to the Shellshock bash bug vulnerability and will post updates to the We Live Security blog.

Major hat tip to Cameron, not only for clarifying several technical points, but also for engaging in the Linux community, pushing patches, and fixes.
 

Author Stephen Cobb, ESET

  • Coyote

    Re: “Keep in mind that some BSD/Linux boxes haven’t been rebooted in five
    years or more! They often lag behind on updates to fix security issues.e”

    This is not only misleading it is factually incorrect. It is also very ignorant of Unix and its many strengths (including how updates are managed). In actuality, servers (especially open source software, which I might add bash IS) get updates far quicker (unless it is something like Apple applying their own patch and taking much longer than upstream does)! Yes, servers tend to stay up for years – I know as I maintain such servers. But the fact is most things don’t require a reboot. Unlike Windows (except maybe Windows servers ? I don’t know nor do I really care), BSD Unix (the family itself), Linux (the many distributions), others, do not need to reboot for a mere update. Server remain up as that is their purpose. Being up for years does not mean updates are not applied. That is ludicrous! The only variable is the admin.

    Example: once the Heartbleed patch was pushed to the repositories, all of the Linux servers I maintain (which one being up for near 3 years at the time) were updated. Not in weeks, not in days, not even in hours. No reboot required at all. Same with shells. Sometimes you need to restart a service depending on what was updated and how it is used, but that is not to suggest downtime, either (with heartbleed it would be wise because OpenSSL is a shared library that is loaded by the services and based on how Unix and Linux work, a file can be “deleted” but still open and in use (and working perfectly I might add)). This is why servers stay up – there isn’t any need for a reboot. But they get the updates as they are available. Down time is irrelevant.

    The only time a reboot is needed is if the kernel is being updated AND only if the kernel needs to be loaded (e.g., if the kernel you have loaded is not vulnerable to a flaw or a bug that is being fixed, why bother rebooting?). I seem to remember that there are ways to not even need to reboot for kernels. There’s a reason why file system checks are done after X amount of mounts OR days since last mount, too. It is expected to be up a long time (okay there are potentially many reasons but the point is the same).

Follow us

Copyright © 2016 ESET, All Rights Reserved.