Blog

When Linux Got Bashed!

Security experts have warned that a serious flaw could be about to affect. But what exactly is the bug that's been dubbed Shellshock, and what does it do. Well, Shellshock is also known as the bash bug for the software it exploits. Hackers use a virus to scan vulnerable system running Linux and UNIX operating systems and then infect them. Bash is a command-line shell this lets users issue commands to launch programs and features within the software by typing in text. It's typically used by programmers and shouldn't be open to the wide world though shellshock changes that. It's so serious it's been rated 10 out of 10 by the national vulnerability database.

When did we first learn of it and how long have we been at risk?
The first mention I've found on the public airwaves was this very brief summary on seclists.org. The detail came in the advisory I mentioned earlier an hour later so getting towards mid-afternoon Wednesday in Europe or morning in the US. It's still very fresh news with all the usual press speculation and Chicken Little predictions it's too early to observe any widespread exploitation in the wild, but that could also come very soon if the risk lives up to its potential.

Scroll back beyond just what has been disclosed publicly and the bug was apparently discovered last week by Stephane Chazelas, a "Unix/Linux, network and telecom specialist" bloke in the UK. Having said that, in Akamai's post on the bug, they talk about it having been present for "an extended period of time" and of course vulnerable versions of Bash go back two and a half decades now. The question, as with Heartbleed, will be whether or not malicious actors were aware of this before now and indeed whether they were actively exploiting it.

What is Bash?
Bash is a *nix shell or in other words, an interpreter that allows you to orchestrate commands on Unix and Linux systems, typically by connecting over SSH or Telnet. It can also operate as a parser for CGI scripts on a web server such as we'd typically see running on Apache. It's been around since the late 80s where it evolved from earlier shell implementations (the name is derived from the Bourne shell) and is enormously popular. There are other shells out there for UNIX variants, the thing about Bash though is that it's the default shell for Linux and Mac OS X which are obviously extremely prevalent operating systems. That's a major factor in why this risk is so significant – the ubiquity of Bash – and it's being described as "one of the most installed utilities on any Linux system".

When half the net is running Apache (which is typically found on Linux), that's a significant size of a very, very large pie. That same Netcraft article is reporting that we've just passed the one billion websites mark too and whilst a heap of those are sharing the same hosts, that's still a whole lot of Bash installations. Oh – that's just web servers too, don't forget there are a heap of other servers running Linux and we'll come back to other devices with Bash a bit later too.

Bash can be used for a whole range of typical administrative functions, everything from configuring websites through to controlling embedded software on a device like a webcam. Naturally this is not functionality that's intended to be open to the world and in theory, we're talking about authenticated users executing commands they've been authorised to run. In theory.

What's the Bug?
Bash processes trailing strings after function definitions in the values of environment variables, which allows remote attackers to execute arbitrary code via a crafted environment, as demonstrated by vectors involving the ForceCommand feature in OpenSSH sshd, the mod_cgi and mod_cgid modules in the Apache HTTP Server, scripts executed by unspecified DHCP clients, and other situations in which setting the environment occurs across a privilege boundary from Bash execution.

The risk centres on the ability to arbitrarily define environment variables within a Bash shell which specify a function definition. The trouble begins when Bash continues to process shell commands after the function definition resulting in what we'd classify as a "code injection attack".