Shellshock (software bug)

Last updated

Shellshock
Shellshock-bug.svg
A simple Shellshock logo, similar to the Heartbleed bug logo.
CVE identifier(s) CVE- 2014-6271 (initial),
CVE- 2014-6277,
CVE- 2014-6278,
CVE- 2014-7169,
CVE- 2014-7186,
CVE- 2014-7187
Date discovered12 September 2014;9 years ago (2014-09-12)
Date patched24 September 2014;9 years ago (2014-09-24)
DiscovererStéphane Chazelas
Affected software Bash (1.0.3–4.3)

Shellshock, also known as Bashdoor, [1] is a family of security bugs [2] in the Unix Bash shell, the first of which was disclosed on 24 September 2014. Shellshock could enable an attacker to cause Bash to execute arbitrary commands and gain unauthorized access [3] to many Internet-facing services, such as web servers, that use Bash to process requests.

Contents

On 12 September 2014, Stéphane Chazelas informed Bash's maintainer Chet Ramey [1] of his discovery of the original bug, which he called "Bashdoor". Working with security experts, Mr. Chazelas developed a patch [1] (fix) for the issue, which by then had been assigned the vulnerability identifier CVE - 2014-6271 . [4] The existence of the bug was announced to the public on 2014-09-24, when Bash updates with the fix were ready for distribution. [5]

The bug Chazelas discovered caused 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 its publication, a variety of related vulnerabilities were discovered ( CVE - 2014-6277 ,CVE- 2014-6278 ,CVE- 2014-7169 ,CVE- 2014-7186 andCVE- 2014-7187 ). Ramey addressed these 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]

Because of the potential to compromise millions of unpatched systems, Shellshock was compared to the Heartbleed bug in its severity. [3] [13]

Background

The Shellshock bug 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. Analysis of the source code history of Bash shows the bug was introduced on 5 August 1989, and released in Bash version 1.03 on 1 September 1989. [14] [15] [16]

Shellshock is an arbitrary code execution vulnerability that offers a way for users of a system to execute commands that should be unavailable to them. This happens through Bash's "function export" feature, whereby one Bash process can share command scripts with other Bash processes that it executes. [17] This feature is implemented by encoding the scripts in a table that is shared between the processes, known as the environment variable list. Each new Bash process scans this table for encoded scripts, assembles each one into a command that defines that script in the new process, and executes that command. [18] The new process assumes that the scripts found in the list come from another Bash process, but it 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. At the time the bug was discovered, Bash was installed on macOS and many Linux operating systems as the main command interpreter, so that any program that used the system function to run any other program would use Bash to do so.

The presence of the bug was announced to the public on 2014-09-24, when Bash updates with the fix were ready for distribution, [5] though it took some time for computers to be updated to close the potential security issue.

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] [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. [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. [20] [21] Yet the next day, it was denied that it had been Shellshock that specifically had allowed these attacks. [22]

Specific exploitation vectors

CGI-based web server
When a web server uses the Common Gateway Interface (CGI) to handle a document request, it copies certain information from the request into the environment variable list and then delegates the request to a handler program. If the handler is a Bash script, or if it executes Bash, then 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 document request. [6]
Security documentation for the widely used Apache web server states: "CGI scripts can ... be extremely dangerous if they are not carefully checked," [23] and other methods of handling web server requests are typically used instead. 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. [24]
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. [25] [7]
IBM HMC restricted shell
The bug can be exploited to gain access to Bash from the restricted shell of the IBM Hardware Management Console, [26] a tiny Linux variant for system administrators. IBM released a patch to resolve this. [27]

Reported vulnerabilities

Overview

The maintainer of Bash was warned about the first discovery of the bug on 2014-09-12; a fix followed soon. [1] A few companies and distributors were informed before the matter was publicly disclosed on 2014-09-24 with CVE identifier CVE - 2014-6271. [4] [5] However, after the release of the patch there were subsequent reports of different, yet related vulnerabilities. [28]

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 and bash-bug mailing lists, 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". [29]

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. [30] 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 . [31]

Initial report (CVE-2014-6271)

This original form of the vulnerability (CVE - 2014-6271) 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. [32] The vulnerability can be tested with the following command:

envx='() { :;}; 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] [33]

CVE-2014-6277

Discovered by Michał Zalewski, [7] [30] [34] the vulnerability CVE - 2014-6277, which relates to the parsing of function definitions in environment variables by Bash, can cause a segfault. [35]

CVE-2014-6278

Also discovered by Michał Zalewski, [35] [36] this bug (CVE - 2014-6278) 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 (CVE - 2014-7169), [24] which is demonstrated in the following code:

envX='() { (a)=>\'bash-c"echo date";catecho

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

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'$ catechoFri 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$ catechocat: echo: No such file or directory

CVE-2014-7186

Florian Weimer and Todd Sabin found this bug (CVE - 2014-7186), [8] [31] 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 (nested "here documents"):

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] CVE - 2014-7187 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:

(forxin{1..200};doecho"for x$x in ; do :";done;forxin{1..200};doechodone;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. [39]

Patches

Until 24 September 2014, Bash maintainer Chet Ramey provided a patch version bash43-025 of Bash 4.3 addressing CVE-2014-6271, [40] which was already packaged by distribution maintainers. On 24 September, bash43-026 followed, addressing CVE-2014-7169. [41] Then CVE-2014-7186 was discovered. Florian Weimer from Red Hat posted some patch code for this "unofficially" on 25 September, [42] which Ramey incorporated into Bash as bash43-027. [43] [44] —These patches provided source 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 patches added a variable name prefix when functions are exported; this prevented arbitrary variables from triggering the vulnerability and enabled other programs to remove Bash functions from the environment.

The next day, Red Hat officially presented according updates for Red Hat Enterprise Linux, [45] [46] after another day for Fedora 21. [47] Canonical Ltd. presented updates for its Ubuntu Long Term Support versions on Saturday, 27 September; [48] on Sunday, there were updates for SUSE Linux Enterprise. [49] The following Monday and Tuesday at the end of the month, Mac OS X updates appeared. [50] [51]

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

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

Related Research Articles

<span class="mw-page-title-main">Bash (Unix shell)</span> GNU replacement for the Bourne shell

Bash is a Unix shell and command language written by Brian Fox for the GNU Project as a free software replacement for the Bourne shell. The shell's name is an acronym for Bourne-Again SHell, a pun on the name of the Bourne shell that it replaces and the notion of being "born again". First released in 1989, it has been used as the default login shell for most Linux distributions and it was one of the first programs Linus Torvalds ported to Linux, alongside GCC. It is available on nearly all modern operating systems.

Uncontrolled format string is a type of code injection vulnerability discovered around 1989 that can be used in security exploits. Originally thought harmless, format string exploits can be used to crash a program or to execute harmful code. The problem stems from the use of unchecked user input as the format string parameter in certain C functions that perform formatting, such as printf . A malicious user may use the %s and %x format tokens, among others, to print data from the call stack or possibly other locations in memory. One may also write arbitrary data to arbitrary locations using the %n format token, which commands printf and similar functions to write the number of bytes formatted to an address stored on the stack.

Code injection is the exploitation of a computer bug that is caused by processing invalid data. The injection is used by an attacker to introduce code into a vulnerable computer program and change the course of execution. The result of successful code injection can be disastrous, for example, by allowing computer viruses or computer worms to propagate.

In computing, a here document is a file literal or input stream literal: it is a section of a source code file that is treated as if it were a separate file. The term is also used for a form of multiline string literals that use similar syntax, preserving line breaks and other whitespace in the text.

<span class="mw-page-title-main">Comparison of command shells</span>

A command shell is a command-line interface to interact with and manipulate a computer's operating system.

In programming and software development, fuzzing or fuzz testing is an automated software testing technique that involves providing invalid, unexpected, or random data as inputs to a computer program. The program is then monitored for exceptions such as crashes, failing built-in code assertions, or potential memory leaks. Typically, fuzzers are used to test programs that take structured inputs. This structure is specified, e.g., in a file format or protocol and distinguishes valid from invalid input. An effective fuzzer generates semi-valid inputs that are "valid enough" in that they are not directly rejected by the parser, but do create unexpected behaviors deeper in the program and are "invalid enough" to expose corner cases that have not been properly dealt with.

A file inclusion vulnerability is a type of web vulnerability that is most commonly found to affect web applications that rely on a scripting run time. This issue is caused when an application builds a path to executable code using an attacker-controlled variable in a way that allows the attacker to control which file is executed at run time. A file include vulnerability is distinct from a generic directory traversal attack, in that directory traversal is a way of gaining unauthorized file system access, and a file inclusion vulnerability subverts how an application loads code for execution. Successful exploitation of a file inclusion vulnerability will result in remote code execution on the web server that runs the affected web application. An attacker can use remote code execution to create a web shell on the web server, which can be used for website defacement.

The Pwnie Awards recognize both excellence and incompetence in the field of information security. Winners are selected by a committee of security industry professionals from nominations collected from the information security community. Nominees are announced yearly at Summercon, and the awards themselves are presented at the Black Hat Security Conference.

The Java software platform provides a number of features designed for improving the security of Java applications. This includes enforcing runtime constraints through the use of the Java Virtual Machine (JVM), a security manager that sandboxes untrusted code from the rest of the operating system, and a suite of security APIs that Java developers can utilise. Despite this, criticism has been directed at the programming language, and Oracle, due to an increase in malicious programs that revealed security vulnerabilities in the JVM, which were subsequently not properly addressed by Oracle in a timely manner.

<span class="mw-page-title-main">Heartbleed</span> Security bug in OpenSSL

Heartbleed is a security bug in some outdated versions of the OpenSSL cryptography library, which is a widely used implementation of the Transport Layer Security (TLS) protocol. It was introduced into the software in 2012 and publicly disclosed in April 2014. Heartbleed could be exploited regardless of whether the vulnerable OpenSSL instance is running as a TLS server or client. It resulted from improper input validation in the implementation of the TLS heartbeat extension. Thus, the bug's name derived from heartbeat. The vulnerability was classified as a buffer over-read, a situation where more data can be read than should be allowed.

JASBUG is a security bug disclosed in February 2015 and affecting core components of the Microsoft Windows Operating System. The vulnerability dated back to 2000 and affected all supported editions of Windows Server 2003, Windows Vista, Windows Server 2008, Windows 7, Windows Server 2008 R2, Windows 8, Windows Server 2012, Windows RT, Windows 8.1, Windows Server 2012 R2, and Windows RT 8.1.

<span class="mw-page-title-main">Stagefright (bug)</span> Software bug in Android

Stagefright is the name given to a group of software bugs that affect versions from 2.2 "Froyo" up until 5.1.1 "Lollipop" of the Android operating system exposing an estimated 950 million devices at the time. The name is taken from the affected library, which among other things, is used to unpack MMS messages. Exploitation of the bug allows an attacker to perform arbitrary operations on the victim's device through remote code execution and privilege escalation. Security researchers demonstrate the bugs with a proof of concept that sends specially crafted MMS messages to the victim device and in most cases requires no end-user actions upon message reception to succeed—the user doesn't have to do anything to 'accept' exploits using the bug; it happens in the background. A phone number is the only information needed to carry out the attack.

BASHLITE is malware which infects Linux systems in order to launch distributed denial-of-service attacks (DDoS). Originally it was also known under the name Bashdoor, but this term now refers to the exploit method used by the malware. It has been used to launch attacks of up to 400 Gbps.

<span class="mw-page-title-main">Dirty COW</span> Computer security vulnerability

Dirty COW is a computer security vulnerability of the Linux kernel that affected all Linux-based operating systems, including Android devices, that used older versions of the Linux kernel created before 2018. It is a local privilege escalation bug that exploits a race condition in the implementation of the copy-on-write mechanism in the kernel's memory-management subsystem. Computers and devices that still use the older kernels remain vulnerable.

EternalBlue is a computer exploit developed by the U.S. National Security Agency (NSA). It was based on a vulnerability in Microsoft networking software that the NSA had known about for several years but had not disclosed to Microsoft. When the NSA discovered in 2017 that the exploit was stolen, Microsoft was informed and released security patches in March 2017. The Shadow Brokers hacker group publicly released EternalBlue on April 14, 2017.

<span class="mw-page-title-main">BlueKeep</span> Windows security hole

BlueKeep is a security vulnerability that was discovered in Microsoft's Remote Desktop Protocol (RDP) implementation, which allows for the possibility of remote code execution.

SIGRed is a security vulnerability discovered in Microsoft's Domain Name System (DNS) implementation of Windows Server versions from 2003 to 2019.

PrintNightmare is a critical security vulnerability affecting the Microsoft Windows operating system. The vulnerability occurred within the print spooler service. There were two variants, one permitting remote code execution (CVE-2021-34527), and the other leading to privilege escalation (CVE-2021-1675). A third vulnerability (CVE-2021-34481) was announced July 15, 2021, and upgraded to remote code execution by Microsoft in August.

Log4Shell (CVE-2021-44228) is a zero-day vulnerability in Log4j, a popular Java logging framework, involving arbitrary code execution. The vulnerability had existed unnoticed since 2013 and was privately disclosed to the Apache Software Foundation, of which Log4j is a project, by Chen Zhaojun of Alibaba Cloud's security team on 24 November 2021. Before an official CVE identifier was made available on 10 December 2021, the vulnerability circulated with the name "Log4Shell", given by Free Wortley of the LunaSec team, which was initially used to track the issue online. Apache gave Log4Shell a CVSS severity rating of 10, the highest available score. The exploit was simple to execute and is estimated to have had the potential to affect hundreds of millions of devices.

The Microsoft Support Diagnostic Tool (MSDT) is a legacy service in Microsoft Windows that allows Microsoft technical support agents to analyze diagnostic data remotely for troubleshooting purposes. In April 2022 it was observed to have a security vulnerability that allowed remote code execution which was being exploited to attack computers in Russia and Belarus, and later against the Tibetan government in exile. Microsoft advised a temporary workaround of disabling the MSDT by editing the Windows registry.

References

  1. 1 2 3 4 5 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 design flaw in a program that comes with some operating systems. See => Staff (25 September 2014). "What does the "Shellshock" bug affect?". The Safe Mac. Archived from the original on 29 September 2014. Retrieved 27 September 2014.
  3. 1 2 Seltzer, Larry (29 September 2014). "Shellshock makes Heartbleed look insignificant". ZDNet . Retrieved 29 September 2014.
  4. 1 2 Florian Weimer (24 September 2014). "Re: CVE-2014-6271: remote code execution through bash". oss-sec (Mailing list). Retrieved 1 November 2014.
  5. 1 2 3 Florian Weimer (24 September 2014). "Re: CVE-2014-6271: remote code execution through bash". oss-sec (Mailing list). Retrieved 1 November 2014.
  6. 1 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.
  7. 1 2 3 4 Saarinen, Juha (29 September 2014). "Further flaws render Shellshock patch ineffective". iTnews. Retrieved 29 September 2014.
  8. 1 2 3 4 Vaughan-Nichols, Steven (27 September 2014). "Shellshock: Better 'bash' patches now available". ZDNet. Retrieved 29 September 2014.
  9. 1 2 3 Greenberg, Andy (25 September 2014). "Hackers Are Already Using the Shellshock Bug to Launch Botnet Attacks". Wired. Retrieved 28 September 2014.
  10. 1 2 3 Saarinen, Juha (26 September 2014). "First Shellshock botnet attacks Akamai, US DoD networks". iTnews. Retrieved 26 September 2014.
  11. 1 2 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.
  12. 1 2 Strohm, Chris; Robertson, Jordan (30 September 2014). "Shellshock Draws Hacker Attacks, Sparks Race to Patch Bug". Businessweek. Archived from the original on 1 October 2014. Retrieved 1 October 2014.
  13. 1 2 Cerrudo, Cesar (30 September 2014). "Why the Shellshock Bug Is Worse than Heartbleed". MIT Technology Review . Retrieved 1 October 2014.
  14. Fox, Brian (21 March 1990). "Bash 1.05 ChangeLog". Archived from the original on 6 December 2023. Retrieved 14 October 2014.
  15. Chazelas, Stéphane (10 October 2014). "when was shellshock introduced". Stéphane Chazelas and Chet Ramey confirm the vulnerability introduction date on Bash official communication channel. Archived from the original on 20 December 2016. Retrieved 14 October 2014.
  16. Chazelas, Stéphane (25 September 2014). "When was the shellshock (CVE-2014-6271/7169) bug introduced, and what is the patch that fully fixes it?".
  17. "Bash Reference Manual: Shell Functions" . Retrieved 2 October 2014.
  18. "Bash 4.3 source code, file variables.c, lines 315-388" . Retrieved 2 October 2014.
  19. Various (26 September 2014). "Web attacks build on Shellshock bug". BBC . Retrieved 26 September 2014.
  20. Boren, Zachary (6 October 2014). "Shellshock: Romanian hackers are accessing Yahoo servers, claims security expert". Independent. Retrieved 7 October 2014.
  21. "Yahoo! Shellshocked Like Ninja Turtles!". Archived from the original on 9 October 2014. Retrieved 7 October 2014.
  22. Hanno Böck (7 October 2014). "Yahoo durch Shellshock angegriffen". Golem - IT-News für Profis (in German). Retrieved 30 October 2014.
  23. "Apache HTTP Server 2.2 Documentation: Security Tips" . Retrieved 2 October 2014.
  24. 1 2 3 Wolfgang Kandek (24 September 2014). "The Laws of Vulnerabilities". Qualys.com. Archived from the original on 3 May 2016. Retrieved 26 September 2014.
  25. Kyle George (27 September 2014). "qmail is a vector for CVE-2014-6271 (bash shellshock)". qmail (Mailing list).
  26. "IBM HMC is a vector for CVE-2014-6271 (bash "shellshock")". IBM . Archived from the original on 19 January 2020.
  27. 1 2 "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 2 November 2014.
  28. "Shellshock". 13 February 2015. Retrieved 17 September 2016.
  29. Gallagher, Sean (26 September 2014). "Still more vulnerabilities in bash? Shellshock becomes whack-a-mole". Arstechnica . Retrieved 26 September 2014.
  30. 1 2 Staff (28 September 2014). "Shellshock, Part 3: Three more security problems in Bash (in german)". Heise Online . Retrieved 28 September 2014.
  31. 1 2 3 "Bash bug: the other two RCEs, or how we chipped away at the original fix (CVE-2014-6277 and '78)". lcamtuf blog. 1 October 2014. Retrieved 8 October 2014.
  32. "Vulnerability Summary for CVE-2014-6271". NIST. 4 October 2014. Retrieved 8 October 2014.
  33. "Bash specially-crafted environment variables code injection attack". Red Hat Security. Retrieved 2 October 2014.
  34. Staff (27 September 2014). "National Cyber Awareness System Vulnerability Summary for CVE-2014-6277". National Institute of Standards and Technology . Retrieved 28 September 2014.
  35. 1 2 Constatin, Lucian (29 September 2014). "Improved patch tackles new Shellshock Bash bug attack vectors". PC World . Retrieved 1 October 2014.
  36. Staff (30 September 2014). "National Cyber Awareness System Vulnerability Summary for CVE-2014-6278". National Institute of Standards and Technology . Retrieved 1 October 2014.
  37. Staff (29 September 2014). "National Cyber Awareness System Vulnerability Summary for CVE-2014-7186". National Institute of Standards and Technology . Retrieved 1 October 2014.
  38. Staff (29 September 2014). "National Cyber Awareness System Vulnerability Summary for CVE-2014-7187". National Institute of Standards and Technology . Retrieved 1 October 2014.
  39. Ramey, Chet. "Re: CVE-2014-7187". lists.gnu.org.
  40. "BASH PATCH REPORT". GNU.org . 12 September 2014. Retrieved 2 November 2014.
  41. "BASH PATCH REPORT". GNU.org . 25 September 2014. Retrieved 2 November 2014.
  42. Weimer, Florian (25 September 2014). "Re: CVE-2014-6271: remote code execution through bash". Openwall Project . Retrieved 2 November 2014.
  43. "BASH PATCH REPORT". GNU.org . 25 September 2014. Retrieved 2 November 2014.
  44. Gallagher, Sean (26 September 2014). "New "Shellshock" patch rushed out to resolve gaps in first fix [Updated]" . Retrieved 2 November 2014.
  45. "Important: bash security update". Red Hat. 30 September 2014. Retrieved 2 November 2014.
  46. 1 2 "Bash Code Injection Vulnerability via Specially Crafted Environment Variables (CVE-2014-6271, CVE-2014-7169)". Red Hat. 2 October 2014. Retrieved 2 November 2014.
  47. "[SECURITY] Fedora 21 Update: bash-4.3.25-2.fc21". FedoraProject.org. 27 September 2014. Retrieved 2 November 2014.
  48. "USN-2364-1: Bash vulnerabilities". Canonical Ltd. 27 September 2014. Retrieved 2 November 2014.
  49. "SUSE Security Update: Security update for bash". OpenSUSE. 28 September 2014. Retrieved 2 November 2014.
  50. Clover, Juli (29 September 2014). "Apple Releases OS X Bash Update to Fix 'Shellshock' Security Flaw in Mavericks, Mountain Lion, and Lion". MacRumors.com. Retrieved 2 October 2014.
  51. Slivka, Eric (30 September 2014). "Apple Releases OS X Yosemite Golden Master Candidate to Developers [Update: Also Public Beta]". MacRumors.com. Retrieved 2 October 2014.