Shellshock – what you need to know

News of the Bash Bug/Shellshock vulnerability is being widely covered since the Ars Technica article published yesterday afternoon.  There is speculation that this bug is going to be more catastrophic than Heartbleed, and like the much publicized OpenSSL vulnerability, we won’t know the full extent of its impact for some time. There are still some major questions to be answered, but for now here is what we do know:

• While I expect we will find there are fewer public-facing programs with the Bash vulnerability than we found to be vulnerable to OpenSSL, the impact of exploiting this bug on any given server is much more severe than exploiting the Heartbleed bug. The National Vulnerability Database has given it a CVSS score of 10 out of 10 due to its high impact and low exploit complexity.  The exploit complexity is trivial – basically all an attacker has to do is send the text of the shell commands he or she wants to execute after the string () { :;}; in a way that gets set as an environment value sent to bash.  There is plenty of simple example out there just ready for cut and paste.
• Most Linux servers contains Bash, but not all are set up in a way that is Internet accessible. There are many remote exploit vectors – the most popular of which is through a type of web application interface called CGI-BIN. (Veracode is currently exploring ways to help our customers scan for this vulnerability).
• A proof of concept has been published on a way to attack linux machines that connect to a hostile network through the use of a malicious DHCP server: It has been speculated that Macs have the same vulnerability because they contain the bash bug too but as of yet no one has demonstrated an exploit through this vector. It seems that Apple rewrote the DHCP client. It doesn’t use system() calls which would have made it vulnerable like Linux is.
• The good news is that the patch seems to be working to prevent remote code execution; at this time there are no remote code execution exploits that work on the latest patch. A 2^nd bug has been found that is not fixed by the patch that could allow an attacker to access some files on a vulnerable system.  This is not as bad as remote code execution, but still systems should be patched when the new patch becomes available.
• It is being reported that cyber-criminals scanning and trying to exploit systems. However, I haven’t seen a confirmed compromise yet.  It’s clearly only a matter of time before a compromise is confirmed, as white-hat and black-hat hackers are scanning and finding vulnerable systems at least in the thousands.

There is no ambiguity as to what caused this bug – it was a coding error where Bash executes code from the environment that it shouldn’t be. Attackers can exploit the bug remotely because many programs take input over the network, like a web app or a DHCP client, and transfer it without sanitizing it into environment variables that Bash will then execute. Bash has a command injection bug. Networked programs that pass untrusted data to bash open this up to be a remote command injection bug. It is surprising how long this vulnerability has been around –  20 years!

The best way to protect Internet connected computers and devices is to update Bash. That may not be practical for embedded devices like IP enabled cameras or routers that run on Linux. I haven’t seen any IoT devices shown to be vulnerable but I expect some to be.  We will have to wait for the manufacturers to speak up or researchers to have time to test.

One lesson from this is developers should be sanitizing the untrusted inputs they receive before handing them over to another process like Bash running on the machine.  They should assume that the program they didn’t code contains security bugs and limit the exploitation of those bugs as much as possible.

The other lesson is some security bugs like the error in Bash are in obscure parts of the program that don’t get much usage and certainly don’t get much inspection.  This one lasted 20 years!  This is all the more reason not to trust that other tools and components are securely written.  Sanitize all data and make it as safe as possible before calling another process with it.