7fgpv8pm 1411703073.jpg?ixlib=rb 1.1

Shell shocked – but what should you do about the Bash bug?

Apple computers could be at risk from the latest Bash bug. Flickr/Oliver, CC BY-NC

Shell shocked – but what should you do about the Bash bug?

A serious security flaw has been discovered in a ubiquitous utility program present on a wide variety of important computer systems, including many Unix-based servers and Macintosh desktop computers.

Shell shock”, as it has been dubbed, has meant another round of sleepless nights for system administrators around the world as they attempt to protect their systems, and Mac users should be wary until a fix for their systems is available.

The security flaw, discovered by Edinburgh-based programmer Stephane Chazelas, affects a software tool called Bash.

Bash – the duct tape of a Unix system

Bash is a Unix shell, or “command-line interpreter”, which is a tool that people who used a personal computer in the 1980s and early 1990s were all too familiar with, but younger computer users may never have seen directly.

A shell being used interactively. This system has Bash installed, but uses an alternative for system administration purposes.

Shells have a similar job to the recently reinstated Start Menu on a Windows PC - they are used to start other applications on a system. Despite the fact that most non-technical users haven’t had to use shells for many years, they are still installed on every Windows or Mac OS X computer, as well as all Linux and Unix systems.

Windows systems use their own unique shell, which is not affected by the current bug. But many (though not all) Unix-based systems, including Mac OS X, by default use Bash.

Bash (which stands for Bourne Again SHell) was first released in 1989 by programmer Brian Fox and is now distributed as free (open source) software by the GNU Project. Its design can be directly traced back to the origins of Unix in the late 1960s.

System administrators and programmers still often use shells directly, for a variety of reasons. But the security risk from the current bug primarily relates to another use of shells – as a largely invisible intermediary when one program starts another.

Starting a program may appear simple, but the process of figuring out exactly which program to execute, and providing configuration information, can actually be quite complicated.

Therefore, many systems delegate this process to the shell, rather than tackling it directly, and Bash acts as the duct tape that binds systems together. For instance, the Apache web server can use Bash in this way to invoke other programs to generate dynamic web pages.

Mishandling configuration information

The bug in Bash, present in all versions dating back at least to 1994, relates to the handling of configuration information. (A more technical summary of the bug and its consequences is available from Unix vendor Redhat.)

Bash should simply pass such configuration information to the programs it starts on either the user’s or another program’s behalf. But a maliciously formatted configuration “string” can cause Bash to do literally anything the “user” running Bash has permission to do.

When Bash was used as originally designed, by a human at a command prompt, this was no big deal. A user who could enter these configuration strings could issue the same (potentially malicious) commands at a command prompt anyway.

The problem today is that other programs, accessible via a network, pass information received from possibly malicious sources on the internet as configuration strings to Bash. Bash could then misinterpret these as commands to execute.

For instance, as previously mentioned, one way the common Unix-based Apache web server can dynamically generate web pages uses Bash in an intermediary role.

If this particular feature is enabled on a specific web server, a remote attacker could send a malicious request for a web page that causes Bash to be invoked, and the malformatted configuration information passed to Bash. Bash will then run the commands the attacker requests on the web server, giving the attacker full control over the server.

While web servers are one of the more obvious ways in which this vulnerability could be exploited, it is not the only one. Many other standard services, accessible from a network, are vulnerable. For instance, the standard tools for configuring network access are a potential entry point, putting not only servers but desktop computers with the vulnerable version of Bash at risk.

Because it can be easily exploited remotely, and potentially gives an attacker full control over a system, this vulnerability is known as a “remote root” exploit – the worst kind.

Given this, and the ubiquity of vulnerable systems, security analysts have described it as comparable to the earlier “Heartbleed” vulnerability.

Are you at risk from shell shock?

For system administrators, shell shock has already been, and will continue to be a headache, particularly as an early attempt to fix the vulnerability does not provide full protection.

At this stage, the general internet-using public will probably need to do less than for Heartbleed, for the following reasons:

  • There is, as yet, no reported evidence of attackers using shell shock to attack systems before the public disclosure of the bug
  • Bash is not installed by default on Windows PCs and servers, and while it is available, very few systems have it installed. So the vast majority of desktop PCs are not affected directly
  • Most servers for high-profile websites long ago ceased to use Bash as an intermediary between the web server and content generation programs, both for security and performance reasons. Therefore, vulnerable servers are likely to be less high-profile ones, unlike Heartbleed where some of the world’s largest websites were vulnerable

If a website finds that it was vulnerable, users may be requested to change passwords; but at this point users should wait until they are requested to do so by individual websites.

Periodically changing passwords is a good idea in any case, but doing so right now unless specifically advised is actually not a good idea as it would be better to wait for administrators to fix the bug first.

Macs are vulnerable

No official patches to fix the underlying vulnerability have been released by Apple yet. The unofficial patches circulating are not only very difficult for non-technical users to install, they don’t yet fully protect against the vulnerability.

Apple users should take care and wait for patches. Flickr/Andrew Scott, CC BY-NC-SA

Users who administer their own system should install system updates as soon as they become available from Apple.

Most Mac desktop systems do not have many network-accessible “server” programs running on them, limiting the ways in which the bug could be exploited.

The usual suspects of dodgy email attachments represent one possibility but as yet no “proof of concept attacks” along these lines have been reported.

But connecting to a malicious Wi-Fi hotspot is one way systems – particularly laptops – could be attacked, and the attacker could gain full access to the system.

Again, no such attacks have been reported to date but Mac users should be very careful about what Wi-Fi networks they choose to connect to until this vulnerability is patched.

The Conversation is a non-profit + your donation is tax deductible. Help knowledge-based, ethical journalism today.