Security Think Tank: Guidelines for dealing with Shellshock

What steps should businesses take to assess the true scope of their vulnerability to the Shellshock Bash bug?

The Shellshock vulnerability has been hyped up in mainstream media recently, particularly in the technology press. Compared to the severity of the Heartbleed vulnerability, it has caused widespread panic in IT circles. This is primarily due to its ubiquity across Unix and Linux operating system (OS) distributions.

So what are the facts behind the Shellshock vulnerability?

Shellshock is a colloquial and media-friendly term defining a series of vulnerabilities discovered in the Unix bash shell. It was discovered on 12 September 2014 and made public on 24 September 2014.

It is useful to contextualise the vulnerability with the bash shell and Linux distributions. Bash is a nix shell that allows a user to choreograph commands on Linux and Unix systems. The orchestration is often remotely facilitated by a Telnet or SSH connection when remote management or inter-connectivity is necessary. Bash can also operate as a parser for CGI upon web servers such as Apache and is utilised within virtualisation products such as ESX, vCenter Server Appliance, Horizon Workspace and more. 

Bash has been in use since its evolution from other shells such as the Bourne Shell in the late 80s and early 90s (it derives its name from Bourne…Bourne Again SHell). 

It is useful to know that there are many other shells that may be utilised in Unix deployments. However, bash is the default shell for both Linux and Mac OS X. The use of both of these operating systems is popular for enterprise and home applications.

This vulnerability has been present in Bash for around 22 years. Chet Ramey a senior technology architect at Case Western Reserve University in Ohio, has been maintaining the Bash open source project and believes Shellshock dates back to a new feature introduced in 1992.

The Shellshock vulnerability is likely to have been exploited prior to the supplier that utilised Bash became aware of the vulnerability's existence. Shellshock could be considered a zero-day vulnerability with some vintage.

Vulnerability Severity

The severity of the vulnerability has been determined by the US Department of Homeland Security as 10 on a one to 10 scale (CVE-2014-6271and CVE-2014-7169). 

The rationale behind this scoring is that the vulnerability is network exploitable, requires no authentication to exploit the vulnerability and that the vulnerability is broad in scope, which allows unauthorized disclosure of information, unauthorised modification and disruption of service. 

This vulnerability, if exploited upon a target asset, could impact the entire security triad of confidentiality, integrity and availability (CIA).

Practical Guidelines

The US-Cert’s advisory includes a simple command line script that users can run to test for the vulnerability. To check your system from a command line, type or cut and paste this text:

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

If the system is vulnerable, the output will be:


    this is a test

An unaffected (or patched) system will output:

    bash: warning: x: ignoring function definition attempt

    bash: error importing function definition for `x'

    this is a test

If you are vulnerable, what should you do about this?

Mobile Devices

If you are running iOS you should be safe. However, if you have a jail-broken iOS device, you could be affected depending upon the shell used. For those affected, an updated version of Bash is available via Cydia. This should be installed without delay. 

Apple reportedly claimed their devices are safe as default because advanced Unix settings are disabled

Reports upon android devices differ. Those using custom ROMs have reported being affected by Shellshock while those not customising their devices report little. The XDA Developers site has links to an updated Bash shell (4.3.30) and if your customised android device is vulnerable you should consider this installation.

Home or enterprise deployments

If you are running Microsoft home or enterprise solutions you need do nothing. This vulnerability won’t affect you.

If you are running Unix, you could use a different shell. However, for those that use Linux, there are no new mantras I have to preach in this realm. You need to download patches from your suppliers and update your software. Suppliers, such as VMWare, Apple and RedHat have been issuing patches to remediate this vulnerability. Please use them.

For those using Apple OS X with the view that Macs are impervious to attack so you need do nothing, you had better put down your latte and install the patch issued from Apple. It is worth noting that, according to internet rumor, Apple knew of Shellshock prior to the vulnerability being made public knowledge and yet they issued their patch five days after public announcement. 

That offered a five-day window of opportunity for nefarious individuals to attack Macs. Apple reportedly claimed their devices are safe as default because advanced Unix settings are disabled. However, that does not necessarily adhere to the principles of ‘defense in depth’ and it assumes Mac users won’t want to do anything more challenging than emails, social media and word processing.

Update and use your information security risk register to guide your approach to updates

Of course, Linux is the operating system of choice in a many devices. One should be mindful of the media player in your living room that is connected to your home NAS for streaming movies. What OS does the media player and NAS use? What about the remote thermostat for your home heating system and your ADSL modem router? 

In the home, it is likely that all devices are connected in one way or another to the internet and could be more likely to have the shellshock vulnerability, if present, exploited. 

It isn’t an onerous or complicated task to update these items and they should be updated in accordance with supplier instructions in an expedited fashion.

Prioritise your enterprise updates

In the enterprise, update and use your information security risk register to guide your approach to updates while following organisational security policies. Technology associated with higher risks within your register should be updated first.

If you have systems using Linux that are not connected to the outside world (they are fully air-gapped), then there is little urgency to patch these (but be mindful of the insider threat and reference your risk register for guidance). 

Concentrate on connected devices and hosts first. Consider web servers, Linux platforms that support data stores, and virtual hosts and devices deployed in the enterprise and upon any cloud environments utilised (dependent upon cloud model and service utilised).

Paul Silcox is a subject matter expert for The Security Institute and director, principal consultant at Silcox Information Security

Read more on Hackers and cybercrime prevention