Shellshock, also known as Bashdoor,^[1] is a family of security bugs^[2] in the widely used Unix Bash shell, the first of which was disclosed on 24 September 2014. Many Internet daemons, such as web servers, use Bash to process certain commands, allowing an attacker to cause vulnerable versions of Bash to execute arbitrary commands. This can allow an attacker to gain unauthorized access to a computer system.^[3]

The bugs cause Bash to unintentionally execute commands when they are stored in specially crafted environment variables.^[1][4] Within days of the initial vulnerability, a series of further related vulnerabilities in Bash were found, leading to the need for further patches.^[5]

By 25 September 2014, botnets based on computers compromised with the bug were being used by attackers for distributed denial-of-service attacks and vulnerability scanning.^[5][6] Millions of attacks and probes related to the bug were recorded by security companies in the days following the disclosure.^[7][8] The bug could potentially be used to compromise millions of servers and other systems, and it has been compared to the Heartbleed bug in its severity.^[3][9]

Stéphane Chazelas discovered the original bug on 12 September 2014^[1] and suggested the name "bashdoor".^[1] The bug was assigned the CVE identifier CVE-2014-6271.^[1] Analysis of the sourcecode history of Bash shows that the vulnerabilities had existed since approximately 1992.^[4]

Apple Inc. commented that most Mac users were likely not affected, unless they were advanced users.^[10][11] Although notified of the vulnerability before it was made public, the company did not release a corresponding OS X update until 29 September, but it did not fix all known vulnerabilities.^[12][13]

Background

The Shellshock vulnerabilities affect 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. Bash is free software developed collaboratively and overseen since 1992 on a volunteer basis by Chet Ramey, a professional software architect.^[1] Analysis of the sourcecode history of Bash shows that the vulnerabilities had existed undiscovered since approximately version 1.13 in 1992.^[4] The maintainers of the Bash sourcecode have difficulty pinpointing the time of introduction due to the lack of comprehensive changelogs.^[1]

In Unix-based operating systems, and other operating systems that Bash supports, each running program has its own list of name/value pairs called environment variables. When one program starts another program, it provides an initial list of environment variables for the new program.^[14] Separately from these, Bash also maintains an internal list of functions, which are named scripts that can be executed from within Bash.^[15] Since Bash is both a command interpreter and a command, it is possible to execute Bash from within Bash. When this happens, the original instance can export environment variables and function definitions into the new instance.^[16] Function definitions are exported by encoding them within the environment variable list as variables whose values begin with parentheses ("()") followed by a function definition. The new instance of Bash, upon starting, scans its environment variable list for values in this format and converts them back into internal functions. It performs this conversion by creating a fragment of code from the value and executing it, thereby creating the function 'on-the-fly', but affected versions do not verify that the fragment is a valid function definition.^[17] Therefore, given the opportunity to execute Bash with a chosen value in its environment variable list, an attacker can execute arbitrary commands or exploit other bugs that may exist in Bash's command interpreter.

The name "shellshock" is attributed^{[failed verification]} to Andreas Lindh from a Tweet on 24 September 2014.^{[18][non-primary source needed]}

On October 1st, Zalewski released details of the final bugs, and confirmed that Florian's patch does indeed prevent them. Zalewski says fixed

Impact

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.^[6][5][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.^[5] 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.^[6]

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.^[7] 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.^[8]

Specific possible exploitation vectors

• CGI-based web server components ^{[citation needed]}
• Port/Socket listening services and applications ^{[citation needed]}
• Dynamic host configuring services and applications ^{[citation needed]}
• System applications that are not network enabled ^{[citation needed]}

Reported vulnerabilities

Initial report (CVE-2014-6271)

This original form of the vulnerability 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.^[20] The vulnerability can be tested with the following command:

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

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".^[21][22]

There was an initial report of the bug made to the maintainers of Bash (Report# CVE-2014-6271). The bug was corrected with a patch to the program, however, after the release of the patch there were subsequent reports of different, yet related vulnerabilities. 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 list and the bash bug list, Wheeler wrote: "This patch just continues the 'whack-a-mole' job of fixing parsing errors that began with the first patch. Bash's parser is certain [to] have many many many other vulnerabilities".^[23]
On 27 September 2014, Michal Zalewski announced his discovery of several other Bash vulnerabilities,^[24] one based upon the fact that bash is typically compiled without address space layout randomization.^[25] Zalewski also strongly encouraged all concerned to immediately apply a patch made available by Florian Weimer.^[24][25]

CVE-2014-6277

CVE-2014-6277 relates to the parsing of function definitions in environment variables by Bash. It was discovered by Michał Zalewski.^{[24][25][26][27]}

CVE-2014-6278

CVE-2014-6278 relates to the parsing of function definitions in environment variables by Bash. It was discovered by Michał Zalewski.^[28][27]

CVE-2014-7169

On the same day the bug was published, Tavis Ormandy discovered a related bug which was assigned the CVE identifier CVE-2014-7169.^[29] Official and distributed patches for this began releasing on 26 September 2014.^{[citation needed]} Demonstrated in the following code:

env X='() { (a)=>\' sh -c "echo date"; cat echo

which would trigger a bug in Bash to execute the command "date" unintentionally. This would become CVE-2014-7169.^[29]

Testing example

Here is an example of a system that has a patch for CVE-2014-6271 but not CVE-2014-7169:

$ X='() { (a)=>\' bash -c "echo date"
bash: X: line 1: syntax error near unexpected token `='
bash: X: line 1: `'
bash: error importing function definition for `X'
$ cat echo
Fri Sep 26 01:37:16 UTC 2014

The patched system displays the same error, notifying the user that CVE-2014-6271 has been prevented. However, the attack causes the writing of a file named 'echo', into the working directory, containing the result of the 'date' call. The existence of this issue resulted in the creation of CVE-2014-7169 and the release patches for several systems.

A system patched for both CVE-2014-6271 and CVE-2014-7169 will simply echo the word "date" and the file "echo" will not be created.

$ X='() { (a)=>\' bash -c "echo date"
date
$ cat echo
cat: echo: No such file or directory

CVE-2014-7186

CVE-2014-7186 relates to an out-of-bounds memory access error in the Bash parser code.^[30] While working on patching Shellshock, Red Hat researcher Florian Weimer found this bug.^[21]

Testing example

Here is an example of the vulnerability, which leverages the use of multiple "<<EOF" declarations:

bash -c 'true <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF' ||
echo "CVE-2014-7186 vulnerable, redir_stack"

A vulnerable system will echo the text "CVE-2014-7186 vulnerable, redir_stack".

CVE-2014-7187

CVE-2014-7187 relates to an off-by-one error, allowing out-of-bounds memory access, in the Bash parser code.^[31] While working on patching Shellshock, Red Hat researcher Florian Weimer found this bug.^[32]

Testing example

Here is an example of the vulnerability, which leverages the use of multiple "done" declarations:

(for x in {1..200} ; do echo "for x$x in ; do :"; done; for x in {1..200} ; do echo done ; done) | bash ||
echo "CVE-2014-7187 vulnerable, word_lineno"

A vulnerable system will echo the text "CVE-2014-7187 vulnerable, word_lineno".

References

External links

• NIST National Vulnerability Database & CVE Common Vulnerabilities and Exposures
  • CVE-2014-6271 - 20140924nist & 20140909cve (first bug)
  • CVE-2014-6277 - 20140927nist & 20140909cve (under review)
  • CVE-2014-6278 - 20140930nist & 20140909cve (under review)
  • CVE-2014-7169 - 20140924nist & 20140924cve (second bug)
  • CVE-2014-7186 - 20140929nist & 20140925cve (under review)
  • CVE-2014-7187 - 20140929nist & 20140925cve (under review)
• Bash source code from the GNU Project, includes patches for known vulnerabilities (28 September 2014)
• FireEye confirms: Malware droppers, Reverse shells & backdoors, Data exfiltration, and DDoS
• SANS: Collection of attacks seen in the wild (29 September 2014)