Why the discovery of “big” bugs is a good thing

2014 will be going down in the cybersecurity history books with two gargantuan flaws in widely used software discovered over the course of six months – or less, actually.

The bugs have a lot in common: They were both discovered in widely (or globally) used open-source software and – as if things weren’t bad enough – both were quite easy to exploit (though the actual damage estimates are uncertain). Both Heartbleed and Shellshock caused a global scare and it’s not hard to see why. By the way, that’s probably the first time software flaws have received their own names.

So why are “big” bug discoveries a good thing? #security

Tweet

Further discoveries?

So what’s next? Just after the Heartbleed revelation, some experts claimed more “big” discoveries were on the way. Shellshock, discovered last month, proved that was correct. It’s logical to presume that in a matter of months we will encounter something similarly “huge”.

Despite all of the disturbances they may cause, the discovery of such bugs is a really good thing.

A good thing

Yes, at first it looks like a disaster. Security experts ring the alarm; businesses owners call their IT staff to demand checking and patching jobs are done quickly; and admins gnash their teeth because it’s Friday, 6:30 p.m., but comply because to not do so may be a disaster.

That’s actually the best-case scenario. The worst (and much more common) is that despite all the bells ringing a business owner shrugs off the news. The patching is done months later, at best. Admins love to say “don’t touch it if it works”, so all the updates are applied only if absolutely necessary. The question of whether or not a new big bad flaw creates such a necessity is usually a subject for debate.

The more such serious flaws are discovered, the more we’ll see best-case scenarios: the more these bugs are publicized, the more attention (and alarm) they draw.

Speaking further of Heartbleed and Shellshock, it is necessary to mention that both have been discovered and publicized by white-hat security experts. Just imagine if bad guys had discovered this instead.

Code review

One more thing, mostly related to open source software: It is a bit of a shame that Heartbleed and Shellshock have been found in open source packages. Open source advocates often state the software’s openness provides some extra security since every person capable of reading the code may inspect it and find the mistakes, if there are any.

Unfortunately, this guarantees nothing: Heartbleed was introduced in 2012, and evaded all revisions for two years. Shellshock was present in Bourne again shell, probably since 1992, i.e. for 22 years, and again, no one had found it until recently.

The possibility to inspect open code doesn’t mean that code inspection is actually done, nor that it is done successfully.

According to Robert Graham, the code of Bash itself is “shockingly obsolete“: “We have modern objective standards about code quality, and bash doesn’t meet those standards.”

Graham then goes on to criticize the Bash coding style, and apparently for good reason: It’s a badly written code that sometimes makes it very difficult for code reviewers to ensure the safety of its functions. This is an issue not limited to Bash alone, but at least this explains why Shellshock kept slipping under the radar for that long.

Business consequences

Given everything that’s been said, what are the consequences for businesses and their IT staffs?

First of all, it’s about preparedness. The best-case scenario should become a routine one. Got a bug? Squash it as soon as the flyswatter is available from the software vendor’s website, and don’t wait until your place is crawling with them. It most likely won’t be just your place (your company server) alone. Shellshock bug has been immediately exploited to create a big fat botnet that’s DDoS’ing and bruteforcing. Who will its owners point at next? No one can guarantee it won’t be you.

Got a bug? Squash it now; the flyswatter is available from the vendor’s site #security

Tweet

Also, an external code review for the open software packages used in the company’s infrastructure may be quite a useful service. This will require funds, of course, but a successful attack would cost much more.