Shellshock (software bug)

From Infogalactic: the planetary knowledge core
Jump to: navigation, search

<templatestyles src="Module:Hatnote/styles.css"></templatestyles>

<templatestyles src="Module:Hatnote/styles.css"></templatestyles>

A simple logo in the style of the heartbleed bug intended to be used in effective communication of the shellshock 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-facing services, such as some web server deployments, use Bash to process certain requests, 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 contacted Bash's maintainer, Chet Ramey, on 12 September 2014[1] telling Ramey about his discovery of the original bug, which he called "Bashdoor". Working together with security experts, he soon had a patch as well.[1] The bug was assigned the CVE identifier CVE-2014-6271.[4] It was announced to the public on 24 September 2014 when Bash updates with the fix were ready for distribution.[5]

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][6] 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 Ramey addressed 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]

Shellshock could potentially compromise millions of unpatched servers and other systems. Accordingly, it has been compared to the Heartbleed bug in its severity.[3][13]

Apple Inc. commented that 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 an official OS X patch is available, or they may use Xcode to replace system-provided Bash with a custom-compiled version that incorporates unofficial patches.[14][15][16] Although notified of the vulnerability before it was made public, the company did not release a corresponding OS X update until 29 September 2014, at which time the OS X bash Update 1.0 was released.[17][18][19]

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 the vulnerabilities had existed since version 1.03 of Bash released in September 1989,[20][21] introduced by Bash's original author Brian Fox.

The basic vulnerability of Shellshock is that affected versions of Bash can be made to execute commands written by an attacker. This happens through the "function export" feature, whereby scripts created in one running instance of Bash can be shared with subordinate instances.[22] This feature is implemented by encoding the scripts within a table that is shared between the instances, known as the environment variable list. Each new instance of Bash scans this table for encoded scripts, assembles each one into a command that defines that script in the new instance, and executes that command.[23] The scripts are assumed to come from another instance, but the new instance 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.

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.[9][10][24] 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.[25][26] Yet the next day, it was denied that it had been Shellshock that specifically had allowed these attacks.[27]

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.[6]
Security documentation for the widely used Apache web server states: "CGI scripts can ... be extremely dangerous if they are not carefully checked."[28] 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.[29]
DHCP clients
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.[13]
Qmail server
When using Bash to process email messages (e.g. through .forward or qmail-alias piping), the qmail mail server passes external input through in a way that can exploit a vulnerable version of Bash.[30][31]
IBM HMC restricted shell
The bug can be exploited to gain access to Bash from the restricted shell of the IBM Hardware Management Console,[32] a tiny Linux variant for system administrators. IBM released a patch to resolve this.[33]

Reported vulnerabilities

Overview

The maintainer of Bash was warned about the first discovery of the bug on 12 September 2014; a fix followed soon.[1] A few companies and distributors were informed before the matter was publicly disclosed on 24 September 2014 with CVE identifier CVE-2014-6271.[4][5] 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".[34] However, this rather was some general reasoning without actually presenting exploitation examples and implied restricting Bash functionality with the effect that some Bash scripts won't work any more, even if not intended to harm other users.

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.[35] 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.[36]

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.[37] 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".[8][38]

CVE-2014-6277

Discovered by Michał Zalewski.[7][35][39] this vulnerability relates to the parsing of function definitions in environment variables by Bash, and can cause a segfault.[40]

CVE-2014-6278

Also discovered by Michał Zalewski.[40][41] 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[29] which is demonstrated in the following code:

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

On a vulnerable system this would execute the command "date" unintentionally.[29]

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 and Todd Sabin found this bug,[8][36] which relates to an out-of-bounds memory access error in the Bash parser code.[42]

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,[8] this is an off-by-one error in the Bash parser code, allowing out-of-bounds memory access.[43]

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". This test requires a shell that supports brace expansion.[44]

Patches

Until 24 September 2014, Bash maintainer Chet Ramey provided a patch version bash43-025 of Bash 4.3 addressing CVE-2014-6271,[45] which was already packaged by distribution maintainers. On 24 September, bash43-026 followed, addressing CVE-2014-7169.[46] Then CVE-2014-7186 was discovered. Florian Weimer from Red Hat posted some patch code for this "unofficially" on 25 September,[47] which Ramey incorporated into Bash as bash43-027.[48][49]—These patches provided code only, helpful only for those who know how to compile ("rebuild") a new Bash binary executable file from the patch file and remaining source code files.

The next day, Red Hat officially presented according updates for Red Hat Enterprise Linux,[50][51] after another day for Fedora 21.[52] Canonical Ltd. presented updates for its Ubuntu Long Term Support versions on Saturday, 27 September,[53] on Sunday, there were updates for SUSE Linux Enterprise.[54] The following Monday and Tuesday at the end of the month, Apple OS X updates appeared.[55][56]

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

All of them have also been covered for the IBM Hardware Management Console.[33]

References

  1. 1.0 1.1 1.2 1.3 1.4 1.5 Lua error in package.lua at line 80: module 'strict' not found.
  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 => Lua error in package.lua at line 80: module 'strict' not found.
  3. 3.0 3.1 Lua error in package.lua at line 80: module 'strict' not found.
  4. 4.0 4.1 Lua error in package.lua at line 80: module 'strict' not found.
  5. 5.0 5.1 Lua error in package.lua at line 80: module 'strict' not found.
  6. 6.0 6.1 Lua error in package.lua at line 80: module 'strict' not found.
  7. 7.0 7.1 7.2 Lua error in package.lua at line 80: module 'strict' not found.
  8. 8.0 8.1 8.2 8.3 Lua error in package.lua at line 80: module 'strict' not found.
  9. 9.0 9.1 9.2 Lua error in package.lua at line 80: module 'strict' not found.
  10. 10.0 10.1 10.2 Lua error in package.lua at line 80: module 'strict' not found.
  11. 11.0 11.1 Lua error in package.lua at line 80: module 'strict' not found.
  12. 12.0 12.1 Lua error in package.lua at line 80: module 'strict' not found.
  13. 13.0 13.1 Lua error in package.lua at line 80: module 'strict' not found.
  14. Lua error in package.lua at line 80: module 'strict' not found.
  15. Lua error in package.lua at line 80: module 'strict' not found.
  16. Lua error in package.lua at line 80: module 'strict' not found.
  17. Lua error in package.lua at line 80: module 'strict' not found.
  18. Lua error in package.lua at line 80: module 'strict' not found.
  19. Lua error in package.lua at line 80: module 'strict' not found.
  20. Lua error in package.lua at line 80: module 'strict' not found.
  21. Lua error in package.lua at line 80: module 'strict' not found.
  22. Lua error in package.lua at line 80: module 'strict' not found.
  23. Lua error in package.lua at line 80: module 'strict' not found.
  24. Lua error in package.lua at line 80: module 'strict' not found.
  25. Lua error in package.lua at line 80: module 'strict' not found.
  26. Lua error in package.lua at line 80: module 'strict' not found.
  27. Lua error in package.lua at line 80: module 'strict' not found.
  28. Lua error in package.lua at line 80: module 'strict' not found.
  29. 29.0 29.1 29.2 Lua error in package.lua at line 80: module 'strict' not found.
  30. "qmail is a vector for CVE-2014-6271 (bash shellshock)", Sep 27, 2014, Kyle George, qmail mailing list
  31. "Further flaws render Shellshock patch ineffective", Sep 29, 2014, Juha Saarinen, itnews.com.au
  32. "IBM HMC is a vector for CVE-2014-6271 (bash "shellshock")
  33. 33.0 33.1 Lua error in package.lua at line 80: module 'strict' not found.
  34. Lua error in package.lua at line 80: module 'strict' not found.
  35. 35.0 35.1 Lua error in package.lua at line 80: module 'strict' not found.
  36. 36.0 36.1 36.2 Lua error in package.lua at line 80: module 'strict' not found.
  37. Lua error in package.lua at line 80: module 'strict' not found.
  38. Lua error in package.lua at line 80: module 'strict' not found.
  39. Lua error in package.lua at line 80: module 'strict' not found.
  40. 40.0 40.1 Lua error in package.lua at line 80: module 'strict' not found.
  41. Lua error in package.lua at line 80: module 'strict' not found.
  42. Lua error in package.lua at line 80: module 'strict' not found.
  43. Lua error in package.lua at line 80: module 'strict' not found.
  44. Lua error in package.lua at line 80: module 'strict' not found.
  45. Lua error in package.lua at line 80: module 'strict' not found.
  46. Lua error in package.lua at line 80: module 'strict' not found.
  47. Lua error in package.lua at line 80: module 'strict' not found.
  48. Lua error in package.lua at line 80: module 'strict' not found.
  49. Lua error in package.lua at line 80: module 'strict' not found.
  50. Lua error in package.lua at line 80: module 'strict' not found.
  51. 51.0 51.1 Lua error in package.lua at line 80: module 'strict' not found.
  52. Lua error in package.lua at line 80: module 'strict' not found.
  53. Lua error in package.lua at line 80: module 'strict' not found.
  54. Lua error in package.lua at line 80: module 'strict' not found.
  55. Lua error in package.lua at line 80: module 'strict' not found.
  56. Lua error in package.lua at line 80: module 'strict' not found.

External links