The techno-sphere is on fire again, this time with news of a newly discovered vulnerability present in a ubiquitous component of the internet infrastructure. Just a few months ago, Heartbleed gave us all a lesson on how OpenSSL works and how to secure network communications. It also demonstrated that the infrastructure we rely on has gaping security holes. At the time, experts called Heartbleed the “worst security flaw ever.” But the industry responded and the furor died down. Now, a vulnerability in Bash dubbed Shellshock has taken Heartbleed’s place as the worst ever. We’ll leave it to others to hash out which flaw deserves the title of ‘worst.’ What matters is that our infrastructure is vulnerable and there are almost certainly other exploits that haven’t be found yet. Or they have been found and just haven’t been publicised.

This latest vulnerability is within Bash, the de facto command line shell that exists on all Unix/Linux systems. Bash is likely the default shell on your systems as well. In the attack, Bash incorrectly handles trailing code in function definitions. With a particular connection type, Bash can even be positioned to execute arbitrary commands allowing an attacker to do whatever they wish with the system. Attack vectors based on this vulnerability are numerous.

More detailed information on the exploit, can be found here.

ArsTechnica also has a great writeup.

Regardless of the details, this represents a profound vulnerability in a ubiquitous bit of code.  How can we prevent against exploits based on fundamental flaws in the internet’s infrastructure? A sound, layered architecture and good security practices can put boundaries around attacks against infrastructure Bash (Shellshock) or OpenSSL (Heartbleed).

In any well-conceived system, controls should be in place to govern access to systems and constraints need to be in place to limit permissions to modify systems. But this does not replace the need for good security procedures. Multi-factor authentication, hardened kernels, web servers running with least privilege permissions, a regular patching strategy, user input sanitization, centralized logging -- these are agreed upon fundamentals which should be implemented.

The best layered approach can mitigate, but not eliminate our vulnerability to this type of infrastructure attack. The fastest way to a full resolution is a quick and comprehensive patching strategy. A rational configuration management system is a key underpinning to assessing the state of systems and patching. We use Chef and Scriptrock here, and the process of assessing and updating all of our systems was done with a few commands (from a trusted host).

We’ve patched all systems susceptible to this attack and it’s obvious that everyone needs to do the same. And since the recent fixes don’t completely resolve the problem across all system types, we’ll continue to evaluate and patch. But based on our assessment, we don’t feel we were exposed based on this vulnerability, given our layered approach to securing our systems.

The furor over Bash will most likely die down within the next week or two. But the next major vulnerability in our infrastructure is most likely out there waiting to be discovered. Perhaps the bad guys already know about it and are using it -- as was speculated with Heartbleed. Or perhaps not. There is no way to be sure. In the meantime, we’re prepared to assess our state and remediate as quickly as possible.