The big security news last week was Shellshock, a vulnerability that affects the Bash shell on *nix operating systems (including Macs). So good news, Windows admins, you get to sit this one out.

For the rest of the world, the impact of Shellshock is still unclear and perhaps that’s what is making it most unsettling. Comparisons have been drawn to the Heartbleed vulnerability since it was released, and you can find folks arguing on both sides saying “it’s worse than Heartbleed” or “not as bad.”

The important thing to keep in mind is that it’s a different class of vulnerability. That, in and of itself, makes such a comparison relatively useless.

Heartbleed allowed spying on arbitrary chunks of memory, whereas Shellshock can allow remote code execution. The latter is probably the more concerning of the two, but it’s also important to keep in mind that this remote code execution occurs with the privilege of the affected process.

From a practical standpoint, what this means is if you have elevated privileges on the process attacked, the damage will be more significant and vice versa. So let’s take a scenario that’s been thrown out in numerous circles – a web server with CGI scripts that are capable of calling Bash.

This is not terribly uncommon, so what’s the impact? Well, it depends. If the CGIs can call out to Bash with the privilege of a normal user, the impact is significant – attackers can possibly function as a normal user, examining files, writing data and potentially causing all sorts of mischief. If, however, the privileges are minimal on that account, the damage is likely to be less.

This certainly helps make the case for least-privilege in any sort of environment. However, there are a number of things that can be considered for this, and future attacks of this nature:

  • Run with least privilege. I think it’s pretty obvious why that is necessary!
  • Disable unnecessary functionality. If you don’t need things like CGI, turn them off – doubly so for any kind of remote access services.
  • Do not give web users or other non-user process accounts a shell – whenever possible. For example, if my server is running under the context of “webuser,” having that user’s shell set to /bin/false should eliminate the threat from attack vectors such as this. That user has no shell to exploit.
  • Sanitize your web application inputs. Many attacks are taking advantage of the ability to include malicious content in HTTP headers and similar input sources. Make certain ALL input to systems is sanitized and does not allow unnecessary, malformed data whenever possible. Many good resources on reducing these risks exist, including from OWASP. One that might be particularly relevant is
  • Consider web application firewalls to help provide an additional layer of protection and notification.
  • Make sure you are patching your systems on a regular basis. Also be sure to monitor security mailing lists, RSS feeds and other information sources for events such as this. Be prepared to respond in the event of a potentially critical vulnerability.

One thing I want to point out, while we are talking here about web servers, this is not necessarily limited to just those as an attack vector. Other remote processes can be similarly affected, and therein lies the concern – it is unclear WHAT attack vectors exist and who is vulnerable.

The other concern is just how many platforms actually run some variant of *nix under the hood, and how exploitable those are. This ranges from advanced enterprise-grade devices to consumer items that exist in someone’s basement or closet. It is also important to point out that there are worms of varying effectiveness already exploiting some of these vulnerabilities.

So how bad will this be? Time will tell. I tend to fall on the “more-concerned-than-not” side, and it’s certainly something we are watching carefully.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>