The Shellshock Fallout

A Bash command that determines whether a machine is vulnerable to Shellshock. (Bf5man/Wikimedia Commons)
A Bash command that determines whether a machine is vulnerable to Shellshock. (Bf5man/Wikimedia Commons)
A Bash command that determines whether a machine is vulnerable to Shellshock. (Bf5man/Wikimedia Commons)

On September 12th, software security specialist Stéphane Chazelas discovered a security flaw in a core component of popular operating systems that run on personal computers, web servers and other connected devices. Within two weeks, the vulnerability was announced publicly and US-CERT (United States Computer Emergency Readiness Team, a branch of Homeland Security) had released a report.

The vulnerability, known colloquially as Shellshock, exists in a piece of software called Bash that was written in 1987. Bash is an interactive shell, or a piece of software that allows either a computer user or a running program (e.g., a web browser or a text editor) to interact with the computer’s operating system. Familiar examples of an interactive shell are Command Prompt for Windows users and Terminal for Mac users. Bash is built into roughly 70% of computers in the world since it is run on most Linux and Unix operating systems.

The Shellshock threat exists because of a bug, an error in programming that causes unintended consequences, introduced during the creation of Bash. If exploited, Shellshock allows attackers to run malicious code as soon as Bash is invoked on a machine. Hackers have proven (after only about one week) that a number of different security attacks are possible because of Shellshock. The security company FireEye announced on September 27th that it has already observed at least four significant types of attacks. This diversity of threat exists because of the wide variety of ways in which Bash interacts with the operating system. The operating system, in turn, interacts with the lowest-level parts of a computer, including the parts that store users’ private information.

Although updates and fixes from several sources were released in the days following the public announcement of Shellshock, recent reports indicate that the bug is going to cause lasting problems. Bash is run not only on personal computers, but also on systems such as medical devices, power plant controls, municipal water systems and common objects such as refrigerators and cameras. While personal computers and web servers are relatively straightforward to patch, or fix with additional software updates, these other devices present unique challenges. Some systems, like traffic lights, are not designed to be patched and will be especially obstinate.

The implications of Shellshock are ominous. An expert hacker can exploit Shellshock to take over an entire machine and gain access to all of its stored information. To put this risk in perspective, the Heartbleed security bug that caused widespread panic when it was discovered in April 2014 gave hackers the ability only to do things like steal passwords from a server. With access to entire machines and devices, attackers will have the ability to accomplish much more malicious goals. The National Institute of Standards and Technology has already rated Shellshock a 10 on its 10-point severity scale. Heartbleed was rated a five out of 10.

In the coming weeks, several parties will collaborate to fix the bug in Bash and limit the impact that hackers can have on machines. The main movers behind the fix will be members of the open-source (publicly available collections of software to which anyone can contribute) community, both independent and in established groups like Red Hat, a leading provider of community-driven open-source software. Aiding in the effort will be large technology companies like Amazon, which played a large role in fixing the problems that Heartbleed created. Google and Apple are already working on Shellshock fixes themselves.

What can we learn from Shellshock? One obvious question is why the vulnerability from a piece of software written in 1987 was just discovered now. The answer is that continuous testing, review and updating is part of the normal process of software development. With programs that comprise hundreds of thousands of lines of code, errors are inevitable. The best that developers can do is remain vigilant about testing and stick to rigorously defined processes.

From this perspective, the open-source technology community will grow as a result of Shellshock. It may be months or years before the threats posed by the bug are put to rest, but the process of going through traditional software development routines (especially as private companies collaborate with open-source developers as they did to fix Heartbleed) will be healthy for the community.

The community will need to be proactive as people around the world ensure that their internet-facing machines are protected from hackers. There will undoubtedly be a surge in cyber attacks in the coming weeks, some of which are likely to succeed given the difficulty of patching certain devices. Although a major data breach at a large corporation or government is unlikely to occur given the traditionally fast response times of these entities, hundreds of thousands of smaller-scale networks and machines will be at risk. It is up to the collaboration of the open-source community and tech companies to ensure that the damage is limited.

The views expressed by these authors do not necessarily reflect those of the Glimpse from the Globe staff, editors, or governors.


Jeff Grimes

Senior Correspondent Jeff Grimes is a senior at the University of Pennsylvania pursuing dual degrees in Computer Science and Economics, with a concentration in Entrepreneurial Management. He has experience in software engineering, product management, entrepreneurship and app design. Jeff has interned for Google, Facebook, Klout and Foundation Capital. He is an iPhone app developer with three apps published in the App Store. Although he has never studied politics in an academic setting, Jeff enjoys following the news and staying current on issues related to cybersecurity, technology and the Obama administration’s business policies. After graduating in May, Jeff will work fulltime for Google as a Product Manager in the San Francisco Bay Area.