Shellshock (software bug)
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]
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 source code history of Bash shows that the vulnerabilities had existed since approximately 1992.[4]
The first bug causes Bash to unintentionally execute commands when the commands are concatenated to the end of function definitions stored in the values of environment variables.[1][4] Within days of the publication of this, intense scrutiny of the underlying design flaws discovered a variety of related vulnerabilities, (CVE-2014-6277, CVE-2014-6278, CVE-2014-7169, CVE-2014-7186, and CVE-2014-7187); which maintainer Chet Ramey addressed with a series of further patches.[5][6]
Attackers exploited Shellshock within hours of the initial disclosure by creating botnets on compromised computers to perform distributed denial-of-service attacks and vulnerability scanning.[7][8] Millions of attacks and probes related to the bug were recorded by security companies in the days following the disclosure.[9][10] 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][11]
Apple Inc. commented that Mac OS X systems are safe by default, unless users configure advanced UNIX services. Such advanced users are typically capable of turning the services off until a patch built using Xcode can be implemented.[12][13] Although notified of the vulnerability before it was made public, the company did not release a corresponding OS X update until 29 September.[14][15]
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 source code history of Bash shows that the vulnerabilities had existed undiscovered since approximately version 1.13 in 1992[4] (or even earlier yet - since version 1.05).[16] The maintainers of the Bash source code have difficulty pinpointing the time of introduction due to the lack of comprehensive changelogs.[1]
In Unix-based operating systems, and in 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.[17] Separately from these, Bash also maintains an internal list of functions, which are named scripts that can be executed from within the program.[18] Since Bash operates both as a command interpreter and as a command, it is possible to execute Bash from within itself. When this happens, the original instance can export environment variables and function definitions into the new instance.[19] 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.[20] 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.
On 1 October, Zalewski released details of the final bugs, and confirmed that Florian's patch does indeed prevent them.[21]
Reports of attacks
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.[8][7][22] Kaspersky Labs reported that machines compromised in an attack, dubbed "Thanks-Rob", were conducting DDoS attacks against three targets, which they did not identify.[7] 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.[8]
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.[9] 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.[10]
On 6 October, it was widely reported that Yahoo! servers had been compromised in an attack related to the Shellshock issue.[23][24]
Specific exploitation vectors
CGI-based web server
When a web server uses the Common Gateway Interface (CGI) to handle a document request, it passes various details of the request to a handler program in the environment variable list. For example, the variable HTTP_USER_AGENT has a value that, in normal usage, identifies the program sending the request. If the request handler is a Bash script, or if it executes one for example using the system(3) call, Bash will receive the environment variables passed by the server and will process them as described above. This provides a means for an attacker to trigger the Shellshock vulnerability with a specially crafted server request.[4] The security documentation for the widely used Apache web server states: "CGI scripts can ... be extremely dangerous if they are not carefully checked."[25] and other methods of handling web server requests are often used. There are a number of online services which attempt to test the vulnerability against web servers exposed to the Internet.[citation needed]
OpenSSH server
OpenSSH has a "ForceCommand" feature, where a fixed command is executed when the user logs in, instead of just running an unrestricted command shell. The fixed command is executed even if the user specified that another command should be run; in that case the original command is put into the environment variable "SSH_ORIGINAL_COMMAND". When the forced command is run in a Bash shell (if the user's shell is set to Bash), the Bash shell will parse the SSH_ORIGINAL_COMMAND environment variable on start-up, and run the commands embedded in it. The user has used their restricted shell access to gain unrestricted shell access, using the Shellshock bug.[26]
DHCP servers
Some DHCP clients can also pass commands to Bash; a vulnerable system could be attacked when connecting to an open Wi-Fi network. A DHCP client typically requests and gets an IP address from a DHCP server, but it can also be provided a series of additional options. A malicious DHCP server could provide, in one of these options, a string crafted to execute code on a vulnerable workstation or laptop.[11]
QMail server
Depending on the specific system configuration, a qmail mail server can pass external input through to Bash in a way that could exploit a vulnerable version.[27][citation needed]
IBM HMC restricted shell
Users can exploit the bug to gain access to an unrestricted shell from a restricted shell on IBM Hardware Management Consoles.[28] IBM released a patch to resolve this.[29]
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.[30] 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".[6][31]
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".[32]
On 27 September 2014, Michał Zalewski announced his discovery of several other Bash vulnerabilities,[5] one based upon the fact that Bash is typically compiled without address space layout randomization.[33] Zalewski also strongly encouraged all concerned to immediately apply a patch made available by Florian Weimer.[5][33]
CVE-2014-6277
Discovered by Michał Zalewski.[5][33][34] this vulnerability relates to the parsing of function definitions in environment variables by Bash, and can cause a segfault.[35]
CVE-2014-6278
Also discovered by Michał Zalewski.[36][35] this relates to the parsing of function definitions in environment variables by Bash.
CVE-2014-7169
On the same day the original vulnerability was published, Tavis Ormandy discovered this related bug[26] which is demonstrated in the following code:
env X='() { (a)=>\' sh -c "echo date"; cat echo
On a vulnerable system this would execute the command "date" unintentionally.[26]
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 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.
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, as shown below:
$ X='() { (a)=>\' bash -c "echo date"
date
$ cat echo
cat: echo: No such file or directory
CVE-2014-7186
Florian Weimer found this bug,[6] which relates to an out-of-bounds memory access error in the Bash parser code.[37]
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
Also found by Florian Weimer,[6] this is an off-by-one error in the Bash parser code, allowing out-of-bounds memory access.[38]
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".
Notes
References
- ^ a b c d e f g Perlroth, Nicole (25 September 2014). "Security Experts Expect 'Shellshock' Software Bug in Bash to Be Significant". New York Times. Retrieved 25 September 2014.
- ^ 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.
- ^ a b Seltzer, Larry (29 September 2014). "Shellshock makes Heartbleed look insignificant". ZD Net. Retrieved 29 September 2014.
- ^ a b c d Leyden, John (24 September 2014). "Patch Bash NOW: 'Shell Shock' bug blasts OS X, Linux systems wide open". The Register. Retrieved 25 September 2014.
- ^ a b c d Saarinen, Juha (29 September 2014). "Further flaws render Shellshock patch ineffective". iTnews. Retrieved 29 September 2014.
- ^ a b c d Vaughan-Nichols, Steven (27 September 2014). "Shellshock: Better 'bash' patches now available". ZDNet. Retrieved 29 September 2014.
- ^ a b c Greenberg, Andy (25 September 2014). "Hackers Are Already Using the Shellshock Bug to Launch Botnet Attacks". Wired. Retrieved 28 September 2014.
- ^ a b c Saarinen, Juha (26 September 2014). "First Shellshock botnet attacks Akamai, US DoD networks". iTnews. Retrieved 26 September 2014.
- ^ a b 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.
- ^ a b Strohm, Chris; Robertson, Jordan (30 September 2014). "Shellshock Draws Hacker Attacks, Sparks Race to Patch Bug". Businessweek. Retrieved 1 October 2014.
- ^ a b Cerrudo, Cesar (30 September 2014). "Why the Shellshock Bug Is Worse than Heartbleed". MIT Technology Review. Retrieved 1 October 2014.
- ^ Chacos, Brad (26 September 2014). "Apple Says Users Safe". Mac World. Retrieved 26 September 2014.
- ^ "Apple Working Quickly". iMore. 26 September 2014. Retrieved 26 September 2014.
- ^ Gallagher, Sean. "Apple working on "Shellshock" fix, says most users not at risk". Retrieved 29 September 2014.
- ^ Ragan, Steve (30 September 2014). "Apple's Shellshock patch is incomplete experts say". CSO Online. Retrieved 9 October 2014.
- ^ Kobrin, Eric (3 October 2014). "oss-sec mailing list archives". Seclists.org. Retrieved 3 October 2014.
- ^ "Open Group Base Specification: exec". Retrieved 2 October 2014.
- ^ "Bash Reference Manual: Shell Functions". Retrieved 2 October 2014.
- ^ "Bash Reference Manual: Bourne Shell Builtins". Retrieved 2 October 2014.
- ^ "Bash 4.3 source code, file variables.c, lines 315-388". Retrieved 2 October 2014.
- ^ "Bash bug: the other two RCEs, or how we chipped away at the original fix (CVE-2014-6277 and '78)". Icamtuf blog. 1 October 2014. Retrieved 8 October 2014.
- ^ Various (26 September 2014). "Web attacks build on Shellshock bug". BBC. Retrieved 26 September 2014.
- ^ Boren, Zachary (6 October 2014). "Shellshock: Romanian hackers are accessing Yahoo servers, claims security expert". Independent. Retrieved 7 October 2014.
- ^ "Yahoo! Shellshocked Like Ninja Turtles!". Retrieved 7 October 2014.
- ^ "Apache HTTP Server 2.2 Documentation: Security Tips". Retrieved 2 October 2014.
- ^ a b c "The Laws of Vulnerabilities". Retrieved 26 September 2014.
- ^ "Further flaws render Shellshock patch ineffective", Sep 29, 2014, Juha Saarinen, itnews.com.au
- ^ "IBM HMC is a vector for CVE-2014-6271 (bash "shellshock")
- ^ "Security Bulletin: Vulnerabilities in Bash affect DS8000 HMC (CVE-2014-6271, CVE-2014-7169, CVE-2014-7186, CVE-2014-7187, CVE-2014-6277, CVE-2014-6278)". IBM. 3 October 2014. Retrieved 8 October 2014.
- ^ "Vulnerability Summary for CVE-2014-6271". NIST. 4 October 2014. Retrieved 8 October 2014.
- ^ "Bash specially-crafted environment variables code injection attack". Red Hat Security. Retrieved 2 October 2014.
- ^ Gallagher, Sean (26 September 2014). "Still more vulnerabilities in bash? Shellshock becomes whack-a-mole". Arstechnica. Retrieved 26 September 2014.
- ^ a b c Staff (28 September 2014). "Shellshock, Part 3: Three more security problems in Bash (in german)". Heise Online. Retrieved 28 September 2014.
- ^ Staff (27 September 2014). "National Cyber Awareness System Vulnerability Summary for CVE-2014-6277". National Institute of Standards and Technology. Retrieved 28 September 2014.
- ^ a b Constatin, Lucian (29 September 2014). "Improved patch tackles new Shellshock Bash bug attack vectors". PC World. Retrieved 1 October 2014.
- ^ Staff (30 September 2014). "National Cyber Awareness System Vulnerability Summary for CVE-2014-6278". National Institute of Standards and Technology. Retrieved 1 October 2014.
- ^ Staff (29 September 2014). "National Cyber Awareness System Vulnerability Summary for CVE-2014-7186". National Institute of Standards and Technology. Retrieved 1 October 2014.
- ^ Staff (29 September 2014). "National Cyber Awareness System Vulnerability Summary for CVE-2014-7187". National Institute of Standards and Technology. Retrieved 1 October 2014.
External links
![](http://upload.wikimedia.org/wikipedia/en/thumb/4/4a/Commons-logo.svg/30px-Commons-logo.svg.png)
- 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)