It appears that Red Hat assurances regarding updates released thus far to fix bash vulnerabilities have unleashed an Lernaean Hydra effect, spawning and spurring the discovery of several more bugs.
Exploit Mechanics and Attack Vectors
To recap, the bash bug, now around 22 years old dating back to version 1.13, allows attackers to interact with a host operating system by exploiting a vulnerable web server (Or any bash linked application/service/client). The attacker aims to inject data into system environmental variables. Normally these variables are used by the operating system as a resource for knowledge about where to find required files, configurations for its own function as well as the programs running on it. The bash vulnerability allows malformed data inside these seemingly benign environmental variable scripts. These scripts can contain commands which bash is tricked into interpreting. In the case of a webserver this can lead to the attacker being able to run commands with the same administrator privileges as the webserver itself, leading to full control of the compromised system.
What does this mean in terms of exploitation possibilities? This vulnerability could open the door to attackers gaining remote access and control of a system to then exploit the system to spread malware, deface system hosted websites, create botnets to launch DDoS attacks, steal personal data, send spam and phishing emails and the perpetration crude but effective destructive wiping attacks. The first Shellshock botnet, “wopbot”, has been used to attack Akamai and US DoD networks.
Security Alerts Issued
The vulnerability is being taken seriously as the ICO, concerned about the disclosure of personal data, urges businesses to install the latest patches for this vulnerability as they become available. CERT-UK, the Computer Emergency Response Team established in March 2014 by the National Cyber Security Strategy, have also issued an alert. CERT-UK suggests that the threat of Shellshock, which affects Unix, Linux, MacOS and many embedded architecture devices, may be bigger than the password revealing, Heartbleed bug, which only affected OpenSSL.
The US National Vulnerability Databases has rated the severity of the bug as 10/10, with an easy exploitation complexity rating of ‘low’. US financial regulators have urged financial institutions to act quickly to identify and fix all of their vulnerable systems and software, including third party applications, to ensure “Shellshock” does not expose them to fraud.
Why is Bash Still Vulnerable?
Several developers have reported that the same vulnerabilities that existed after the first patch (CVE-2014-7169) still exist after the second patch (CVE-2014-6271). These developers are urging a complete rethink in the approach to future patches. Computing Scientist, David A. Wheeler asserts that until bash stops automatically parsing environment variables, it will continue to be vulnerable. An open source developer, Norihiro Tanaka, demonstrated that he was able to bypass the second patch and pass through executable commands by using the name “cat” for the environmental variable, a Unix utility of the same name exists that is used to concatenate files.
Detection
Due to the nature of the attack vectors associated with the Shellshock bug and its prolonged existence, there is a need for organisations to conduct an internal review of their systems and ensure the necessary assurance work is conducted to identify compromises to security and gain assurance.
Shellshock Timeline
Timeline of notable Shellshock bash patches and attacks
Patches Released
On Sept 25th the Free Software Foundation released bash patches. These patches are reported to fix the original flaw CVE-2014-6271 and an additional flaw, discovered by Tavis Ormandy, which spawned from the incomplete CVE-2014-7169.
Several vendors, including Oracle, have begun releasing patches to fix their products that are liked to bash. Furthermore, Florian Weimar has released an unofficial patch that puts function exporting in a separate namespace. The fix isolates function-parsing code from attacker-controlled strings in several identified use cases.
Proposed Future Solution
So while bash is not yet completely fixed, there is a clear pathway currently under development that aims to fix problems with bash. The approach is twofold, firstly Florain Wiemar, a security expert, proposed the adding of a prefix to bash functions. Adding the prefix aims to prevent functions from having the same name as system variables. Secondly, Dr. Christos Zoulas proposes only allowing the importing of environmental variables via bash when explicitly requested. Explicit requests stop bash command parsing from inadvertently executing malicious code residing in surplus environmental variables.
Solution Implications
An unfortunate caveat of any workable solution is the dissolution of backward compatibility for bash. While Wheeler does not believe the majority of bash-dependent systems would suffer, many software systems that rely on bash may need their code tested and if needs be, modified. However, just as Wheeler has shut down several of his websites until he has confidence the problem has been fixed, the same may need to follow for older services to ensure that assurance via patching and testing can be completed to provide operational confidence.
For now though, it is important for organisations for patch vulnerable systems, establish effective protective network monitoring and to ensure their end users systems are also kept up to date to ensure they are part of the solution.