Shellshock Bash

[Juliano Nichols]

Shellshockalso known as Bashdoor,[1] is a family of security bugs[2] in the Unix Bash shell, the first of which was disclosed on 24 September 2014. Shellshock could enable an attacker to cause Bash to execute arbitrary commands and gain unauthorized access[3] to many Internet-facing services, such as web servers, that use Bash to process requests.

On 12 September 2014, Stphane Chazelas informed Bash's maintainer Chet Ramey[1] of his discovery of the original bug, which he called "Bashdoor". Working with security experts, Mr. Chazelas developed a patch[1] (fix) for the issue, which by then had been assigned the vulnerability identifier CVE-2014-6271.[4] The existence of the bug was announced to the public on 2014-09-24, when Bash updates with the fix were ready for distribution.[5]

The bug Chazelas discovered caused Bash to unintentionally execute commands when the commands are concatenated to the end of function definitions stored in the values of environment variables.[1][6] Within days of its publication, a variety of related vulnerabilities were discovered (CVE-2014-6277, CVE-2014-6278, CVE-2014-7169, CVE-2014-7186 and CVE-2014-7187). Ramey addressed these with a series of further patches.[7][8]

Attackers exploited Shellshock within hours of the initial disclosure by creating botnets of compromised computers to perform distributed denial-of-service attacks and vulnerability scanning.[9][10] Security companies recorded millions of attacks and probes related to the bug in the days following the disclosure.[11][12]

The Shellshock bug affects Bash, a program that various Unix-based systems use to execute command lines and command scripts. It is often installed as the system's default command-line interface. Analysis of the source code history of Bash shows the bug was introduced on 5 August 1989, and released in Bash version 1.03 on 1 September 1989.[14][15][16]

Shellshock is an arbitrary code execution vulnerability that offers a way for users of a system to execute commands that should be unavailable to them. This happens through Bash's "function export" feature, whereby one Bash process can share command scripts with other Bash processes that it executes.[17] This feature is implemented by encoding the scripts in a table that is shared between the processes, known as the environment variable list. Each new Bash process scans this table for encoded scripts, assembles each one into a command that defines that script in the new process, and executes that command.[18] The new process assumes that the scripts found in the list come from another Bash process, but it cannot verify this, nor can it verify that the command that it has built is a properly formed script definition. Therefore, an attacker can execute arbitrary commands on the system or exploit other bugs that may exist in Bash's command interpreter, if the attacker has a way to manipulate the environment variable list and then cause Bash to run. At the time the bug was discovered, Bash was installed on macOS and many Linux operating systems as the main command interpreter, so that any program that used the system function to run any other program would use Bash to do so.

The presence of the bug was announced to the public on 2014-09-24, when Bash updates with the fix were ready for distribution,[5] though it took some time for computers to be updated to close the potential security issue.

Within an hour of the announcement of the Bash vulnerability, there were reports of machines being compromised by the bug. By 25 September 2014, botnets based on computers compromised with exploits based on the bug were being used by attackers for distributed denial-of-service (DDoS) attacks and vulnerability scanning.[9][10][19] Kaspersky Labs reported that machines compromised in an attack, dubbed "Thanks-Rob", were conducting DDoS attacks against three targets, which they did not identify.[9] On 26 September 2014, a Shellshock-related botnet dubbed "wopbot" was reported, which was being used for a DDoS attack against Akamai Technologies and to scan the United States Department of Defense.[10]

On 26 September, the security firm Incapsula noted 17,400 attacks on more than 1,800 web domains, originating from 400 unique IP addresses, in the previous 24 hours; 55% of the attacks were coming from China and the United States.[11] By 30 September, the website performance firm CloudFlare said it was tracking approximately 1.5 million attacks and probes per day related to the bug.[12]

On 6 October, it was widely reported that Yahoo! servers had been compromised in an attack related to the Shellshock issue.[20][21]Yet the next day, it was denied that it had been Shellshock that specifically had allowed these attacks.[22]

The maintainer of Bash was warned about the first discovery of the bug on 2014-09-12; a fix followed soon.[1] A few companies and distributors were informed before the matter was publicly disclosed on 2014-09-24 with CVE identifier CVE-2014-6271.[4][5] However, after the release of the patch there were subsequent reports of different, yet related vulnerabilities.[28]

On 26 September 2014, two open-source contributors, David A. Wheeler and Norihiro Tanaka, noted that there were additional issues, even after patching systems using the most recently available patches. In an email addressed to the oss-sec and bash-bug mailing lists, Wheeler wrote: "This patch just continues the 'whack-a-mole' [sic] job of fixing parsing errors that began with the first patch. Bash's parser is certain [to] have many many many other vulnerabilities".[29]

On 27 September 2014, Michał Zalewski from Google Inc. announced his discovery of other Bash vulnerabilities,[7] one based upon the fact that Bash is typically compiled without address space layout randomization.[30] On 1 October, Zalewski released details of the final bugs and confirmed that a patch by Florian Weimer from Red Hat posted on 25 September does indeed prevent them. He has done that using a fuzzing technique with the aid of software utility known as american fuzzy lop.[31]

This original form of the vulnerability (CVE-2014-6271) involves a specially crafted environment variable containing an exported function definition, followed by arbitrary commands. Bash incorrectly executes the trailing commands when it imports the function.[32] The vulnerability can be tested with the following command:

In systems affected by the vulnerability, the above commands will display the word "vulnerable" as a result of Bash executing the command "echo vulnerable", which was embedded into the specially crafted environment variable named "x".[8][33]

The system displays syntax errors, notifying the user that CVE-2014-6271 has been prevented, but still writes a file named 'echo', into the working directory, containing the result of the 'date' call.

The next day, Red Hat officially presented according updates for Red Hat Enterprise Linux,[45][46] after another day for Fedora 21.[47]Canonical Ltd. presented updates for its Ubuntu Long Term Support versions on Saturday, 27 September;[48]on Sunday, there were updates for SUSE Linux Enterprise.[49]The following Monday and Tuesday at the end of the month, Mac OS X updates appeared.[50][51]

On 1 October 2014, Michał Zalewski from Google Inc. finally stated that Weimer's code and bash43-027 had fixed not only the first three bugs but even the remaining three that were published after bash43-027, including his own two discoveries.[31] This means that after the earlier distribution updates, no other updates have been required to cover all the six issues.[46]

To reassure a few, I didn't find the bug by observing exploits, I haveno reason to believe it's been exploited before being disclosed(though of course I can't rule it out). I did not find it bylooking at bash's code either.

That more or less came from some reflection on some behaviours ofsome software I find dangerous (the behaviours, not thesoftware). The kind of behaviour that makes you think: thatdoesn't sound like a good idea.

In this case, I was reflecting on the common configuration ofssh that allows passing environment variables unsanitised fromthe client provided their name starts with LC_. The idea is sothat people can keep using their own language when sshing intoother machines. A good idea until you start to considerhow complex localisation handling is especially when UTF-8 isbrought into the equation (and seeing how badly it's handled bymany applications).

Back in July 2014, I had already reported a vulnerability inglibc localisation handling which combined with that sshdconfig, and two other dangerous behaviours of the bash shellallowed (authenticated) attackers to hack into git serversprovided they were able to upload files there and bash wasused as the login shell of the git unix user (CVE-2014-0475).

I was thinking it was probably a bad idea to use bash as the loginshell of users offering services over ssh, given that it's quitea complex shell (when all you need is just parsing a very simple command line) and has inherited most of the misdesigns of ksh.Since I had already identified a few problems with bash beingused in that context (to interpret ssh ForceCommands), I waswondering if there were potentially more there.

AcceptEnv LC_* allows any variable whose name startswith LC_ and I had the vague recollection that bash exportedfunctions (a dangerous albeit at time useful feature) wereusing environment variables whose name was something likemyfunction() and was wondering if there was not somethinginteresting to look at there.

I was about to dismiss it on the ground that the worst thing onecould do would be to redefine a command called LC_somethingwhich could not really be a problem as those are not existingcommand names, but then I started to wonder how bashimported those environment variables.

That's when I realised the extent of the problem, confirmed that it wasexploitable over HTTP as well (HTTP_xxx/QUERYSTRING... env vars), other ones like mail processing services, later DHCP (and probably a long list) andreported it (carefully).

3a8082e126