Shellshock is Shocking, According to Shellers

If you’ve had a few spare moments to peruse the news, and happen to do so with an eye toward IT, you’ll have heard about Shellshock. As with many a vulnerability, there are many questions, and in this post I hope to answer some.

What is the problem?

Bash (Bourne-again Shell) is a command line interpreter packaged with most Unix variants. It’s quite handy for running commands, especially when invoked from scripts. The vulnerability roughly relates to how Bash parses environment variables (used to set the context of commands). The vulnerability allows someone entering environment variables to insert arbitrary code. Instead of just setting the context of execution, Bash executes the injected commands.

Am I vulnerable?

Yes, but probably no. If you are running a Unix-based system, including Linux, technically, your system most likely contains the vulnerability. However, that doesn’t mean a remote attacker can own your system. Your system must meet a fairly focused set of requirements:

√ Remote access; a web application being the primary example

√ An application that calls Bash

√ A system that is vulnerable

If you are running an application that calls Bash, directly or indirectly (Dash, for example), you have a problem. The most common way of calling Bash is via CGI scripts; to make a web site dynamic (following the example), in-that a supporting script executes some stuff. In its execution, the script accepts input. Part of that input could be the USER-AGENT variable in an HTTP conversation. Within that variable, one can (by virtue of this vulnerability) execute code.

Should I panic?

Only if you are vulnerable. To be vulnerable, in a way that is interesting to a remote entity, you need to meet the criteria (see above).

To be clear; if I have local access to your *nix systems, and that includes the ability to invoke Bash, I can use this vulnerability to run arbitrary commands, the first of which would be to elevate my local privileges. However, if I have access to run Bash, either you’ve delivered it to me via a remotely accessible application, or I have local access (in which case, I’ve plenty of local options for going-about escalating privilege).

shellshock

But, what about break-out?

If your application, which accepts remote input, does not call Bash, you’re safe. For example, a Java-driven web application executes within a space that is dedicated to Java. Unless the Java code dials-up Bash commands (let’s say it calls a legacy bit of stuff), someone trying to exploit this vulnerability will not succeed. It cannot “break-out”, unless there is a route, and that route happens to invoke Bash, and also passes-on environment variables.

Who should be worried?

Most applications that accept remote input, and were created in the last decade, don’t invoke Bash. There are verticals where (in IT terms) ancient code still runs. Healthcare, government, financial; these are verticals that are not praised for their agility. It is possible that they have URL’s containing /cgi-bin/, which could be problematic.

What else should I worry about?

Applications, by their very nature, should be considered in the same way that we consider end-users. If you allow applications to run as root/admin, you are handing the keys to your kingdom to everyone using that application.

Even if you run an application, let’s say Apache, as “nobody”, you must pay attention to the bits called by that application, and assume that any application can invoke code (whether you like it or not). For example, it may seem simple to run CRON jobs as root, and indeed, anecdotal evidence shows that most admins do. This vulnerability shows that not being very diligent about permissions can hurt. A web application that invokes Bash can be manipulated remotely to run commands, and invoking CRON to do so is likely to instantly escalate permissions.

What’s the conclusion?

This is not Heartbleed part II. Comparing the two is like measuring shoes with pumpkins; they simply don’t compare, and the attempted measurement doesn’t provide useful information. Heartbleed was about data leakage, while Shellshock is about executing code. The potential impact of each is undeniable, but very different.

Heartbleed had extremely wide applicability, but it did not provide instant-ownership of a targeted system (yes, extracting information can lead to it). Shellshock provides an opportunity to execute code, not just extract information, and so where Shellshock is applicable, it will be more damaging than Heartbleed. However, the number and influence of targets that are vulnerable to Shellshock is, by the nature of the vulnerability, not as wide as with Heartbleed.

Don’t panic, in other words, but do be vigilant!