A shock to the system
Shellshock has been with us for a week now, and as the dust starts to settle I think it is time to take a look.
Shellshock refers to a set of problems in the open source command shell Bash, or the Bourne Again SHell. There are many blogs and articles on Shellshock, so once again I’m not trying to tell you things that are widely covered elsewhere but there are some significant problems with the coverage and I want to take a look at them here. This is not a news service; if you want to track Shellshock information please try some of the links at the end of the article, and pretty much any other IT security page at the moment.
One of the less helpful parts of the reporting is the idea that somehow the Heartbleed SSL vulnerability and Shellshock are comparable. True, they both got media friendly names as soon as the news was released but heartbleed got the cool logo.
The superficial comparisons are that they are both open source issues, they are both potentially externally facing, network exploitable and don’t need to be authenticated. They also received a great deal of general publicity; finally they both produced a great deal of activity over a short period of time.
Now, considering the differences:
Heartbleed was only present in a small number of SSL installations that were running modern implementations; many systems were too old to be vulnerable to Heartbleed. There are no systems running the Bash shell that are too old, they are vulnerable unless patched in the last few days. The Bash shell may appear on any Linux, as well as most conventional Unix systems and some embedded devices.
Heartbleed (2011) is a fault, we know it is the coding error and it is fixed, the problems with Bash are decades old and may not really be a fault at all. Bash (1989) was written before the modern Internet and concepts such as ‘secure by design’ and it may well be that the code was always meant to work this way. So, Heartbleed may allow a backdoor, Shellshock is more like a front door.
Heartbleed is very hard to exploit, it might be necessary to run the attack thousands of time before valuable data is captured. It is possible to exploit vulnerable Bash code with a single attack string. Part of the same issue is that Heartbleed packets are pretty easy to detect using tools like network IDS, despite the fact they aren’t usually logged by the vulnerable asset itself. The strings used to exploit Shellshock are arguably valid code, and so creating a solid detection with a low false positive rate is much harder.
So, is Shellshock worse than Heartbleed, undoubtedly yes. The Bash shell was never created as a security system, just to be useful. It is as old as the 486 processor and the fall of the Berlin wall.
Bash trusts user inputs in a way that modern systems shouldn’t do. Attack code is already publically available and is in use, (see web links below.) Such code might be useful for compromise as well as denial of service. Where a system is vulnerable results can be expected immediately, not like Heartbleed.
The Bash code is simple; any attacker with even basic web and scripting skills can create a new attack and manipulate target systems in new ways. I expect more from Shellshock over the next few weeks and the discovery of more vulnerabilities in decade old code that we have very quietly all become dependent on.
The following external links are recommendations of the author. This is a fast moving situation, so it is important to keep up with the latest information from security professionals and vendors.
Shellshock technical deep dives
General news article