Jump to content

Shellshock (software bug)

From Wikipedia, the free encyclopedia

This is an old revision of this page, as edited by 50.185.134.48 (talk) at 06:54, 30 September 2014. The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

"Bash bug" redirects here. For the related bug reporting tool, see bashbug.

Shellshock, also known as Bashdoor,[1] is a security bug[2] in the widely used Unix Bash shell 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][4]

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

Stéphane Chazelas discovered the bug on 12 September 2014[1] and suggested the name "bashdoor".[1] The bug was assigned the CVE identifier CVE-2014-6271 and kept under embargo until 24 September 2014 14:00 UTC, in order to ensure that security updates were available for most systems[6] as soon as the details were made public. The name "shellshock" is attributed to Andreas Lindh[7][8][9][10] from a Tweet on 24 September 2014 at 11:16am.[11]

Analysis of the sourcecode history of Bash shows that the vulnerabilities had existed undiscovered since approximately version 1.13 in 1992.[5] The maintainers of the Bash sourcecode have difficulty pinpointing the time of introduction due to the lack of comprehensive changelogs.[1]

By 25 September 2014, botnets based on computers compromised with this exploit were being used by attackers for distributed denial-of-service attacks and vulnerability scanning.[12][13] On 26 September 2014, the security firm Incapsula noted 17,400 attacks on more than 1,800 web domains, originating from 400 unique I.P. addresses, in the previous 24-hours; 55% of the attacks, according to Incapsula, were coming from China and the United States.[14]

Apple Inc. commented that most Mac users were likely not affected, unless they were advanced users.[15][16] Although notified of the vulnerability before it was made public, the company did not release a corresponding OS X update until September 29th.[17][18]

Background

The Shellshock vulnerability 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.

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.[19] Separately from these, Bash also maintains an internal list of functions, which are named scripts that can be executed from within Bash.[20] 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.[21] 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.[22] 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.

Continued issues addressing vulnerabilities

On the same day the bug was published, Tavis Ormandy discovered a related bug which was assigned the CVE identifier CVE-2014-7169.[3] Official and distributed patches for this began releasing on 26 September 2014.[citation needed]

While working on patching Shellshock, Red Hat researcher Florian Weimer found two more bugs, CVE-2014-7186 and CVE-2014-7187.[23]

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".[24]

On 27 September 2014, Michal Zalewski announced his discovery of several other Bash vulnerabilities,[25] one based upon the fact that bash is typically compiled without address space layout randomization.[26] Zalewski also strongly encouraged all concerned to immediately apply a patch made available by Florian Weimer.[25][26]

Reported vulnerabilities

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.

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.[27] Red Hat has provided commands to test for the vulnerability: 

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".[28]

Subsequent reports

CVE-2014-6277

As of 29 September 2014, the details of this additional vulnerability have not been made public.[25][26][29]

CVE-2014-6278

As of 29 September 2014, the details of this additional vulnerability have not been made public.[25][30]

CVE-2014-7169

Tavis Ormandy, while working on CVE-2014-6271, identified an additional issue, 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.[3]

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'
[root@ ec2-user]# 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

This issue is caused by the same code issues identified in Bash, but leverages the use of multiple "<<EOF" declarations.[citation needed]

Testing example

Here is an example of the vulnerability: 

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

This issue is caused by the same code issues identified in Bash, but leverages the use of multiple "done" declarations.[citation needed]

Testing example

Here is an example of the vulnerability: 

(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".

Exploitation vectors

Within an hour of the announcement of the Bash vulnerability, there were reports of machines being compromised by the bug. By 25 September 2014, various attacks verified 'in the wild' were reported, ranging from DoS to command & control deployment attempts via malware called "BASHLITE".[31][32] Kaspersky Labs reported that machines compromised in an attack, dubbed "Thanks-Rob", were conducting DDoSes against three targets, which they did not identify.[13] On 26 September 2014, a botnet based on computers compromised with this exploit was reported. Dubbed "wopbot", the botnet was being used for a distributed denial-of-service (DDoS) attack against Akamai Technologies and to scan the United States Department of Defense.[12] Two other mentioned exploits were detailed. One attacks a web server that processes requests via the Common Gateway Interface (CGI), which allows manipulation of environment variables.[5] Another uses the "ForceCommand" feature of Secure Shell implementations to gain unrestricted shell access on an account that normally places the user in a restricted shell.[3] An attack on DHCP services has also been proven.[33][34]

References

  1. ^ a b c d e Perlroth, Nicole (25 September 2014). "Security Experts Expect 'Shellshock' Software Bug in Bash to Be Significant". New York Times. Retrieved 25 September 2014.
  2. ^ Although described in some sources as a "virus," Shellshock is instead a coding mistake in a program that comes with some operating systems. See => Staff (25 September 2014). "What does the "Shellshock" bug affect?". The Safe Mac. Retrieved 27 September 2014.
  3. ^ a b c d "The Laws of Vulnerabilities". Retrieved 26 September 2014.
  4. ^ Seltzer, Larry (29 September 2014). "Shellshock makes Heartbleed look insignificant". ZD Net. Retrieved 29 September 2014.
  5. ^ a b c Leyden, John (24 September 2014). "Patch Bash NOW: 'Shell Shock' bug blasts OS X, Linux systems wide open". The Register. Retrieved 25 September 2014.
  6. ^ "oss-security - Re: CVE-2014-6271: remote code execution through bash". Retrieved 26 September 2014.
  7. ^ Fox-Brewster, Tom (26 September 2014). "Shellshock just 'a blip' says Richard Stallman as Bash bug attacks increase". The Guardian. Retrieved 29 September 2014.
  8. ^ Walsh, Scott (24 September 2014). "CVE-2014-6271: BASH Lets You Do Bad Things. (SHELLSHOCK)". InvisibleThreat. Retrieved 29 September 2014.
  9. ^ Graham, Robert (24 September 2014). "@DavisSec I credit @addelindh for coining "shellshock"". Twitter. Retrieved 29 September 2014.
  10. ^ Davis, Christopher (24 September 2014). "Shell Shock AKA Baaaaad BASH bug". Retrieved 29 September 2014.
  11. ^ Lindh, Andreas (24 September 2014). "@addelindh "FTFY"". Twitter. Retrieved 29 September 2014.
  12. ^ a b Saarinen, Juha (26 Septemberr 2014). "First Shellshock botnet attacks Akamai, US DoD networks". iTnews. Retrieved 26 September 2014. {{cite news}}: Check date values in: |date= (help)
  13. ^ a b Greenberg, Andy (25 September 2014). "Hackers Are Already Using the Shellshock Bug to Launch Botnet Attacks". Wired. Retrieved 28 September 2014.
  14. ^ Perlroth, Nicole (26 September 2014). "Companies Rush to Fix Shellshock Software Bug as Hackers Launch Thousands of Attacks". New York Times. Retrieved 29 September 2014.
  15. ^ Chacos, Brad (26 September 2014). "Apple Says Users Safe". Mac World. Retrieved 26 September 2014.
  16. ^ "Apple Working Quickly". iMore. 26 September 2014. Retrieved 26 September 2014.
  17. ^ Gallagher, Sean. "Apple working on "Shellshock" fix, says most users not at risk". Retrieved 29 September 2014.
  18. ^ http://support.apple.com/kb/DL1769?viewlocale=en_US&locale=en_US
  19. ^ Open Group Base Specification: exec
  20. ^ Bash Reference Manual: Shell functions
  21. ^ Bash Reference Manual: Bourne Shell Builtins
  22. ^ Bash 4.3 source code, file variables.c, lines 315-388
  23. ^ Vaughan-Nichols, Steven (27 September 2014). "Shellshock: Better 'bash' patches now available". ZDNet. Retrieved 29 September 2014.
  24. ^ Gallagher, Sean (26 September 2014). "Still more vulnerabilities in bash? Shellshock becomes whack-a-mole". Arstechnica. Retrieved 26 September 2014.
  25. ^ a b c d Saarinen, Juha (29 September 2014). "Further flaws render Shellshock patch ineffective". iTnews. Retrieved 29 September 2014.
  26. ^ a b c Staff (28 September 2014). "Shellshock, Part 3: Three more security problems in Bash (in german)". Heise Online. Retrieved 28 September 2014.
  27. ^ http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-6271
  28. ^ https://securityblog.redhat.com/2014/09/24/bash-specially-crafted-environment-variables-code-injection-attack/
  29. ^ Staff (27 September 2014). "National Cyber Awareness System Vulnerability Summary for CVE-2014-6277". National Institute of Standards and Technology. Retrieved 28 September 2014.
  30. ^ Staff (09 September 2014). "CVE Report - CVE-2014-6278". Common Vulnerabilities and Exposures. Retrieved 29 September 2014. {{cite web}}: Check date values in: |date= (help)
  31. ^ Various (26 September 2014). "Shellshock Updates: BASHLITE C&Cs Seen, Shellshock Exploit Attempts in Brazil". Trend Micro. Retrieved 26 September 2014.
  32. ^ Various (26 September 2014). "Web attacks build on Shellshock bug". BBC. Retrieved 26 September 2014.
  33. ^ Selvan, Sabri. "Everything you need to know about Bash Bug "ShellShock"". Retrieved 29 September 2014. {{cite web}}: Unknown parameter |site= ignored (help)
  34. ^ "DHCPShock". Retrieved 29 September 2014.
Wikimedia Commons has media related to Shellshock.
Retrieved from "https://en.wikipedia.org/w/index.php?title=Shellshock_(software_bug)&oldid=627647438"