Jump to content

Shellshock (software bug)

From Wikipedia, the free encyclopedia

This is an old revision of this page, as edited by 64.186.39.4 (talk) at 20:32, 26 September 2014 (The site was launched on Thursday the 25th). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

For other uses, see Shell shock (disambiguation).

Shellshock, also known as the Bash bug and Shellshocker,[1] is a security bug in the widely-used Unix Bash shell, causing Bash to execute commands from environment variables unintentionally.[2][3] While Bash is not an Internet-facing service, many Internet-facing daemons call Bash internally. An attacker can use an Internet-facing service that sets the contents of an environmental variable to cause Bash to execute the commands in the variable. Some web servers calling Bash files as CGI scripts are known to be vulnerable. DHCP clients are also potentially vulnerable, and more affected services are expected to be found.[4]

The bug was discovered by Stéphane Chazelas, a French software developer who lives in Edinburgh, 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[5] as soon as the details of the vulnerability were available to attackers.

Apple Inc commented that most Mac users were likely not affected, unless they are advanced users. Even with this announcement, however, a patch was quickly provided to deal with the issue and was circulated throughout the internet.[6][7][8]

On the same day the bug was published, Tavis Ormandy discovered a related bug which was assigned the CVE identifier CVE-2014-7169.[4] Official and distributed patches for this began releasing on 26 September 2014.[4][9][10][11][12][13][14][15]

On Thursday 2014-09-25 the website shellshocker.net was published, documenting much of the information found online and displaying one of several logos found on the internet. According to the website, it is run by the health IT team at Medical Informatics Engineering.[16]

CVE-2014-6271 vulnerability details

Bash supports exporting Bash function definitions inside environment variables. For example, the following defines a "hello world" function inside environment variable named, "HELLO_WORLD_VAR"

HELLO_WORLD_VAR='() {echo "Hello World";};'

Note that the function is defined only, not executed, when Bash starts. The bug is that Bash did not stop parsing at the end of the function, but instead, continued interpreting. So if an attacker could set the value of the environment variable to, for example,

HELLO_WORLD_VAR='() {echo "Hello World";}; rm /path/to/file'

Then Bash first would define, but not execute, the function (only defining it is harmless), but immediately, execute the malicious command "rm /path/to/file", effectively giving shell access to the attacker.

The attacker would still have to get his code inserted into an environment variable, but many Internet-facing daemons will insert user-supplied code into an environment variable, since it normally would be considered harmless.

Web server example[citation needed][original research?]

When sending a request for a document from a web server, for example http://www.example.com/, the user always sends along a text string called the user agent, indicating the name of the user's current browser. This user agent text string typically is then put into the environment variable HTTP_USER_AGENT by the web server, and will be seen by the web server process and all its child processes. Since the contents of the user agent string is arbitrary, it can be set to, for example, "() {echo "Hello World";}; rm /path/to/file", which due to the Bash bug will run the command "rm /path/to/file" if parsed by a Bash shell. If the web server, or a child of the web server, runs a Bash shell while servicing the request, the command will be run. Note that not all web servers will run Bash scripts while servicing requests.

SSH server example

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 his restricted shell access to gain unrestricted shell access, using the Shellshock bug.[4]

DHCP example

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.[17]

Log parsing[citation needed][original research?]

The bug can potentially effect machines that are not directly connected to the internet when examining log files. Tools that use bash when parsing log files can inadvertently execute the malicious code while processing lines from log files that contain the function/code. If fields from the log contain the malicious code and are stored in bash variables, they will be executed when a child process is launched. This could effect, for example, machines used for forensic analysis.

Testing

Example of shell output on vulnerable system:[18] 

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

Output after initial patch: 

$ env x='() { :;}; echo vulnerable' bash -c "echo this is a test"
bash: warning: x: ignoring function definition attempt
bash: error importing function definition for `x'
this is a test

To check for the bug using only native bash commands (when the env binary is unavailable or untrusted) type: 

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

CVE-2014-7169 vulnerability details

Tavis Ormandy(Twitter) pointed out that setting the environment variable X

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

would trigger a bug in Bash to execute the command "date" unintentionally.[4]

Testing

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

 
$ 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.[9][10][11][12][13][14][15]

Exploitation

On 26 September 2014, within a day of the announcement of the vulnerability, the first botnet based on computers compromised with this exploit was reported. Dubbed "wopbot", the botnet was being used to attack Akamai Technologies and the United States Department of Defense.[19]

References

  1. ^ a b Staff (25 September 2014). "Are You Open to Being Shell-Shocked?". Host-project.org. Retrieved 26 September 2014. Cite error: The named reference "host-project" was defined multiple times with different content (see the help page).
  2. ^ Leyden, John (24 September 2014). "Patch Bash NOW: 'Shell Shock' bug blasts OS X, Linux systems wide open". The Register. Retrieved 25 September 2014.
  3. ^ Perlroth, Nicole (25 September 2014). "Security Experts Expect 'Shellshock' Software Bug in Bash to Be Significant". New York Times. Retrieved 25 September 2014.
  4. ^ a b c d e "The Laws of Vulnerabilities". Retrieved 26 September 2014.
  5. ^ "oss-security - Re: CVE-2014-6271: remote code execution through bash". Retrieved 26 September 2014.
  6. ^ "Apple Says Users Safe". Mac World. 26 September 2014. Retrieved 26 September 2014.
  7. ^ "Recompile BASH to Avoid Shellshock". Stackexchange. 26 September 2014. Retrieved 26 September 2014.
  8. ^ "Apple Working Quickly". iMore. 26 September 2014. Retrieved 26 September 2014.
  9. ^ a b "Ubuntu". Retrieved 26 September 2014.
  10. ^ a b "Red Hat". Retrieved 26 September 2014.
  11. ^ a b "Red Hat 2". Retrieved 26 September 2014.
  12. ^ a b "CentOS 5.10". Retrieved 26 September 2014.
  13. ^ a b "CentOS 5.11". Retrieved 26 September 2014.
  14. ^ a b "CentOS 6". Retrieved 26 September 2014.
  15. ^ a b "CentOS 7". Retrieved 26 September 2014.
  16. ^ "About Shellshocker.net". Retrieved 26 September 2014.
  17. ^ "Shellshock DHCP RCE Proof of Concept", Geoff Walton, TrustedSec
  18. ^ "How do I recompile Bash to avoid the remote exploit CVE-2014-6271 and CVE-2014-7169". Retrieved 25 September 2014.
  19. ^ 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)
Wikimedia Commons has media related to Shellshock.
Retrieved from "https://en.wikipedia.org/w/index.php?title=Shellshock_(software_bug)&oldid=627202381"