CVE-2014-6271 (“Shellshock”): How it works

A Brief (Skippable) Introduction:

So, first, I’d like to say that I might differ from other security analysts on the Interwebs in that I don’t tend to flail my arms and cry out in agony at the sight of any given security exploit.

You may or may not prefer this approach.

Back when “Heartbleed” (CVE-2014-0160 for those of you not irrevocably taken in by silly marketing/media nomenclature) was revealed, I was skeptical of its potential for damage, guessing that actually retrieving important data such as encryption keys or user information would be sufficiently difficult to be infeasible to all but the most dedicated hacking teams.  That’s not to say that such groups of hackers don’t exist, or that they aren’t the most important threat faced by certain Internet-joined computer systems, but it’s an important distinction to make nonetheless; it is an oft-overlooked, yet critical security injunction to know thyself.  Many threats faced by banking systems, for example, are not likely to be faced by home or small office networks (assuming those small offices aren’t carrying similarly valuable payloads).  The average joe needs to worry far more about spam and generic malware infections than targeted advanced persistent threats.

Anyway, the point is, my opinion was later shown to be somewhere on the softer side of correct when CloudFlare’s challenge system was successfully breached and the private encryption key was stolen.  Sure, the system was a best-case scenario for exploitation by hackers (and I’m still wondering about the impact of the system reboot / service management actions on the placement of the encryption key data in memory), but nonetheless, the system was breached quickly enough that I must admit I was incorrect about the severity of the security flaw.

Nonetheless, I do think the vast majority of security news agencies overreacted to the severity of the issue, which actually increased the severity of the issue by drawing more attention.  So the end state of the matter might have been at least partially a self-fulfilling prophecy that must be respected for what it is.  At the very least, thanks to the lackadaisical security practices rampant throughout the implementation of open source technology (and any technology, really), the exploit will continue to cause problems for poorly-maintained systems for years to come.

I think perhaps the most concerning revelation from the entire debacle was that the NSA reported that they had no knowledge of the flaw.  I believe them when they say that they did not, but that, itself, is pretty scary.  If they had no knowledge of the flaw, it’s likely because they need no knowledge of it.  Who knows how many exploits the NSA is sitting on when it comes to open source software?

And this latest exploit, CVE-2014-6271 (“Shellshock”…sigh…), demonstrates what every learned security professional already suspects: that there are other, even more critical flaws which are hiding for longer amounts of time in code even more popular than OpenSSL (and that’s a feat).  I was informing my superiors that CVE-2014-6271 makes CVE-2014-0160 look minor by comparison, and it appears the respected Larry Seltzer over at ZDNet agrees.

The Title Story:

So how exactly does this exploit work, and can we have a rough idea of the extent to which it can impact a system?

Basically, the exploit revolves around the fact that bash will mistakenly execute code contained in a maliciously-formatted environment variable declaration passed to the shell during process creation.  Something like:

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

Here, the user is launching bash after creating an environment variable (which will be passed to the new bash process) which is formed to trick bash into executing the code block “echo vulnerable.”  This is accomplished by placing the string “() { :;};” in front of the code which will be executed by bash.  As a feature, bash will create function definitions out of environment variable contents.  The string mentioned above causes bash to create a function with an empty definition (the contents of the curly braces constitute the function definition) .  The exploit consists of the fact that bash will continue to execute commands listed after the function definition (after the semicolon).  This function definition creation feature was simply poorly designed and, like a sudo definition ending in a wildcard which allows for the same problem, arbitrary code following the definition is permitted and executed.

So what’s the extent of the damage possibilities here?  Well, the bash process must be launched by a process accessible to the attacker, so that’s a good thing.  If the processes surfaced to users are well-regulated, your system is in a lot better condition to withstand attacks against this exploit than if not.  Take a CGI script offered to web users by apache, for example:  if your apache process is running as a user whose rights are constrained to only allow access to that data which is needed for the CGI script to function and SELinux is enabled, constraining the process further with mandatory access control, well then you’re likely in pretty ok shape.  If, on the other hand, you have apache running as root and SELinux is in permissive mode or disabled entirely, then this vulnerability gives anyone with access to that CGI script full root control over your system.

Again, basic security practices can really mitigate this situation.  Dan Walsh discusses in his blog just such a CGI script exploitation and the potential benefits conferred by a system properly configured with SELinux.  There, you can see that the vulnerability is being exploited to create a file in the /tmp directory, to which all users have the capacity to write data, meaning that even in the situation I described above, it is likely that the vulnerability would allow for this behavior.  This leads to further worries that someone leverage the vulnerability to load code into the /tmp directory and then execute it.

But here, again, basic security practices will mitigate the threat.  It is standard practice to not only create a separate file system for the /tmp directory, but also to mount that file system with the noexec and nosuid options.  This will mitigate not only the threat of a malicious hacker filling up one’s entire system with senseless /tmp data (since it has its own file system, only /tmp would be filled; this is a problem, but much less of one than an entire system being brought to a halt from an entirely-full operating system volume) but also the /tmp directory is no longer a potential platform for code execution.

And that would basically reduce the threat to one of filling up the /tmp directory.  An attacker would no longer be able to use the system as a bot or a platform for a worm or many other nefarious purposes.

Now, as you can see, a lot of this is conditional on the nature of the process(es) surfaced to the hacker(s) – the most important piece of knowledge to have here is that the vulnerability relies on the privileges of the process used to spawn the new bash process, so if you constrain those down and use SELinux to restrict the surfaced processes as tightly as possible, you’ve done quite a lot for yourself.  If you further constrain world-writable areas of the system with good file system definitions and mounts, you’re really in good shape to weather this storm.

Again, modern security efforts in an enterprise environment should be largely composed of the implementation of basic security features (especially SELinux).  The difficulty comes from wrangling unwilling vendors into compliance and having the know-how to work with what you get as effectively as possible.  System administrators are the last line of defense against this stuff – once the software creators themselves have failed and produced a vulnerability, the only mitigation left is sound administration of the system resulting in an environment for each process wherein the process is not given any unnecessary leeway to cause problems.

Let me know if you have any specific inquiries or questions here – I’d love to address them to the best of my capability.

This entry was posted in Information Technology and tagged , , . Bookmark the permalink.

1 Response to CVE-2014-6271 (“Shellshock”): How it works

  1. Good to see a well balenced article about ShellShock, so many article are just proper gating the hype. If your readers are interested to find out more about how SELinux can be used to protect against ShellShock, they may be interested in the blog article below, which talks about how we have used SELinux in our system design to mitigate exactly this type of threat.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s