Shellshock

Shellshock, discovered in 2014, is a significant vulnerability in the GNU Bash shell, affecting a wide range of systems. It enables attackers to execute arbitrary code on vulnerable systems, exploiting environment variables in Bash. The severity of Shellshock lies in its widespread impact, targeting systems running Bash, including web servers, DHCP clients, and network services.

Background

Bash Shell

The GNU Bourne Again Shell (Bash), introduced in 1989 by Brian Fox, is a widely used command-line interface in Unix-like operating systems. Renowned for its flexibility and extensive feature set, Bash combines capabilities from various other shells, such as the Korn Shell (ksh) and the C-Shell (csh) .

However, this complexity also introduced vulnerabilities, as highlighted by the Shellshock incident. Bash's integral role in numerous systems and devices across networks significantly amplified the impact of these vulnerabilities, underlining the importance of secure shell programming and system design.

Discovery

The discovery of Shellshock and its related vulnerabilities unfolded in 2014, starting with Stéphane Chazelas, a French software developer, uncovering the initial bug, CVE-2014-6271 (Common Vulnerability and Exposures, CVE). The vulnerability, which had gone unnoticed for over two decades, was a significant flaw in the Bash shell.

Upon its discovery, it was quickly recognized for the potential to allow attackers to execute arbitrary code (Arbitrary Code Execution, ACE) on affected systems . The revelation of Shellshock prompted an immediate and coordinated response from the software community, leading to rapid development of patches by Bash's lead developer, Chet Ramey, and widespread updates across various operating systems and networked devices .

Furthermore, it led to the identification of six distinct CVEs, ranging from CVE-2014-6271 to CVE-2014-7187, each highlighting various vulnerabilities in Bash's handling of code parsing and execution .

Reported Vulnerabilities

CVE-2014-6271

The original Shellshock vulnerability was based on how Bash processed environment variables and allowed attackers to execute arbitrary code on vulnerable systems .

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

In this example, the function is defined using the command env x='() { :;}; echo vulnerable'. After the actual function body, marked by { :;};, additional code is added – in this case, the command echo vulnerable. If the Bash version is vulnerable, it will output "vulnerable" and "this is a test." This means that it also executes the code after the function.

It's important to note that the second output string, "this is a test," is not part of the vulnerability and can be replaced with almost any other command. What matters is that when using bash -c, a new instance of Bash is created, which assigns the value to the environment variable x. During this initialization of x, the injected code echo vulnerable is executed.

CVE-2014-7169

The second discovered vulnerability, also known as Aftershock, allowed for the execution of injected code in a similar manner, even after applying the initial patch .

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

In this case, an attempt is made to assign a function to the variable x as well. The key difference from the previous vulnerability is that the function is designed to generate a syntax error while still executing code. The use of the escape character \ cancels out the following quotation mark, preventing the function definition from being completed. The redirection operator > redirects output to a file specified afterward.

Despite the syntax error in the function definition's position of =, Bash continues to execute code and, as a result, creates a file named "echo" with the content of the date command output. Finally, this file is printed to the console using cat echo.

CVE-2014-7186

Another vulnerability, which didn't execute malicious code but was used to carry out DoS attacks by causing memory overflow and application crashes, or other unexpected behavior in Bash .

x=’() { true <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF; }’; bash -c :

In the example above, a series of here documents are nested within the function body, but they are never closed with a delimiter. Each <<EOF opens a new document, which typically needs to be closed with the matching delimiter EOF. Everything between these two points is considered the content of the document .

The security vulnerability arises from the missing closing delimiters, combined with the deep nesting, causing an Out-Of-Bounds Memory-Access-Error.

CVE-2014-7187

A software crash and subsequent DoS can be caused by an Off-By-One error due to a flaw in the read token word function found in the parse.y file within the Bash source code .

(for x in {1..200} ; do echo "for x$x in ; do :"; done; for x in {1..200} ; do echo done ; done) > test-script.sh
bash test-script.sh

When using a for loop, the output of echo commands is written to the target file test-script.sh, which is executed afterward. The resulting deeply nested loops can cause Bash to mishandle them, leading to an Off-By-One error in memory access.

This can result in accessing memory outside the allocated range, potentially leading to application crashes.

CVE-2014-6277

Another security vulnerability, in contrast to the previous weaknesses, is related to uninitialized memory usage. This faulty memory access could lead to DoS or the execution of malicious code . A detailed explanation of this issue can be found in a personal blog post by Michał Zalewski.

x="() { y() { _; }; y() { _; } <<‘perl -e ’{print "A"x1000}’‘; }" bash -c :

In this command, after two empty functions y() { _; }, the << operator starts a here document. However, due to the missing delimiter string, the it is not fully terminated. As a result, the here_doc_eof pointer incorrectly points to an invalid string and remains uninitialized. Consequently, Bash could attempt to read from this uninitialized memory that has been manipulated by attackers.

This could result in unexpected behavior such as Arbitrary Code Execution (ACE) or software crashes.

CVE-2014-6278

This more complex security vulnerability allowed attackers to bypass the previously published patches through redirection and parsing errors, ultimately enabling the execution of malicious code .

x=’() { _; } >_[$($())] { echo vulnerable; id; }’ bash -c :

The expression >_[$($())] uses redirection and array syntax in a way that the Bash parser does not understand. As a result, it falls into a state that it cannot correctly reset after interpreting the nested command substitution $().

Because of this, the following code block { echo vulnerable; id; } is executed without further checks.

Impact and Attack Scenarios

Attack Vectors

Shellshock could be exploited through web servers using CGI scripts, SSH services, DHCP clients, and various network services. By manipulating environment variables, attackers could execute malicious code.

Examples of Attacks

Notable instances include a suspected attack on a voting server in Georgia, a worm targeting QNAP NAS devices, and unauthorized access to Yahoo servers. These examples highlight the broad and severe implications of Shellshock in real-world scenarios.

Defense and Mitigation Strategies

Patches and Updates

Rapid development and distribution of patches for each CVE were crucial in mitigating Shellshock. Regular system updates and applying patches are critical for maintaining security.

Best Practices

Adopting best practices, such as minimal installation to reduce attack surfaces, adhering to the principle of least privilege, regular security audits, and employee training, are essential strategies to prevent similar vulnerabilities.