UPDATE: The initial round of patches to fix CVE-2014-6271 have proven ineffective at fully resolving the issue; a new CVE code has been issued, “CVE-2014-7169“, use this to track news and updates regarding this bug and patch status.
Remember Heartbleed? Get ready to bleed again, ‘Shellshock’ looks set to equal or even exceed it.
Clik here to view.
Got anything nice planned for the weekend?
Huh?
A short while ago it was publicly revealed that a massive security hole, formal name of ‘CVE-2014-6271‘ and recently christened ‘Shellshock‘, exists in the Bourne Again Shell. Commonly known as ‘bash’, this command-line interface that ships by default with almost all modern distributions of Linux, many commercial variants of UNIX and UNIX-like systems, embedded systems, NAS systems and Mac OS X with Bash as the default shell; currently this includes all versions subsequent to 10.2 (earlier OS X versions shipped with tcsh rather than bash). If you have installed Bash from ported code, even FreeBSD and OpenBSD can be affected, although the base installation for these systems seems secure for now.
To directly quote from the official announcement;
Bash supports exporting not just shell variables, but also shell functions to other bash instances, via the process environment to (indirect) child processes. Current bash versions use an environment variable named by the function name, and a function definition starting with “() {” in the variable value to propagate function definitions through the environment. The vulnerability occurs because bash does not stop after processing the function definition; it continues to parse and execute shell commands following the function definition.
The critical bug permits arbitrary code to be appended to an environment variable within a Bash environment, or within a service relying upon Bash to process environment variables. This last point is especially concerning, as large tracts of familiar services rely heavily upon Bash processing and Bash environment variables for basic functionality. You may think that your machine doesn’t interact with any Bash scripts, but if your web application calls a Bash shell command like exec(), the potential for exploitation still exists.
Clik here to view.
Push it. There’s never been a better time.
Machines vulnerable to this bug are subject to, at the very least, the following remote exploitation:
- Fork bombing – instant remote Denial-of-Service with a single GET request
- Data theft – any file accessible (/etc/shadow anyone?) can be exfiltrated
- Ping flooding – any server can be co-opted to flood-ping another, instant DDoS potential
- Backdoor installation – a shell can be spawned and bound to a port on the server
- Rootkits – malicious code can be downloaded from elsewhere and executed directly
Due to the ubiquity of the Bash interface and how deeply interwoven it has become with standard network services such as OpenSSH, Apache webservers, Common Gateway Interface and any number of daemons like DHCP it is now trivial to remotely exploit a Bash-dependent service for arbitrary code execution.
Clik here to view.
A not-so-subtle visual metaphor for our current situation
This is just as bad as it sounds. A quick Google search for vulnerable CGI servers reveals results numbering in the millions.
Who is at risk?
Anyone responsible for a machine that runs Bash, right now, personal or otherwise, that is even vaguely connected to the internet. That’s a sizeable chunk of normal internet users with computers running Mac OS X or any Linux-like operating system; this can include Android versions that run bash, this can include your home servers and NAS boxes if they run embedded Linux with Bash.
It also includes an enormous proportion of what people think of as ‘The Internet’: production servers, web servers, firewalls and databases, anything that is touched by the current Bash codebase is plagued by this vulnerability and must be patched immediately.
Clik here to view.
The smart money says, all these servers need a patch
What can I do?
Update your Bash-enabled systems, all of them. Right. This. Second. Stop reading this blog post and apply your patches. If a patch is unavailable, apply mitigations as suggested by your vendor until the patch is released ; if no mitigations are available either, consider creative alternatives or shout at negotiate with your software vendor until they make some available. Once that is done, check with the following Bash code snippet:
x='() { :;}; echo vulnerable' bash
If following this your command line outputs the string ‘vulnerable‘ then bad luck, you have a problem, as a patch is not yet available for your system and it remains vulnerable to attack. It is critical that you pursue a patched status as aggressively as possible, this is honestly not something that can wait longer than it needs to. Keep an eye on the news released by your software vendor, Apple in particular can occasionally be somewhat reticent in their patching of major vulnerabilities.
Clik here to view.
Seriously Apple, no rush fellas.
Certain vendors such as RedHat are producing quick-fix mitigations to reject the incoming bad code, but as poorly understood as the variety of vectors are it is unlikely that all avenues can be covered by band-aid solutions. The only true path to salvation is to apply all the patches from the Bash upstream codebase and rebuild / update your Bash installation.
For critical machines without available patches, the good option is to rebuild the Bash packages manually with the updated source code. The procedure varies from system to system, we can only advise you to refer to the current upstream codebase for rebuild instructions.
If it is simply impossible for a machine to receive a patched Bash version, the easiest solution is simply to eliminate the possibility of Bash being called. This can be accomplished by altering the file structure to replace calls to Bash to Dash or another unaffected shell. This may very well break some scripts or calls, so use with extreme caution;
$mv /bin/bash /bin/_bash $chmod ugo-x /bin/_bash $ln -s /bin/dash /bin/bash
Why all the concern?
For a start, Proof-of-Concept exploit code is already floating around on Pastebin, so the cat is very much out of the bag mere hours after the official announcements. Patches have already been released by major vendors to coincide with the lifting of the public embargo on this information, so the security teams of major Linux distributions certainly consider it of the very highest priority.
Depending on system configuration and levels of inbuilt security, the potential vectors include, but are in no way limited to, the following:
- Malicious HTTP-GET requests running code against public-facing web servers
- Crafted SSH connections abusing allowed scripts like rsync and rlogin
- Crafted CUPS print requests delivering exploit code between networks
- Rogue Wifi Access Points delivering hostile code via the DHCP negotiation process
The full range of vectors by which this bug can be exploited hasn’t been explored yet, but even the earliest indications are all bad news and getting worse. Remote code execution appears to be a reality for the overwhelming majority of Bash-enabled systems, which in turn represents the majority of internet-connected computers.
Clik here to view.
An even less subtle visual metaphor for next week’s situation
Crucially, this form of vulnerability is very attractive to the authors of malware, viruses and worm code due to its simplicity, flexibility and universal presence.
Patch Bash as soon as possible.
Further Reading
- https://lists.debian.org/debian-security-announce/2014/msg00220.html
- http://www.theregister.co.uk/2014/09/24/bash_shell_vuln/
- https://security-tracker.debian.org/tracker/CVE-2014-6271
- https://access.redhat.com/articles/1200223
- http://blog.erratasec.com/2014/09/bash-bug-as-big-as-heartbleed.html
- http://seclists.org/oss-sec/2014/q3/650
- http://www.troyhunt.com/2014/09/everything-you-need-to-know-about.html
- https://securityblog.redhat.com/2014/09/24/bash-specially-crafted-environment-variables-code-injection-attack/