There’s nothing the Internet loves more than a fat, juicy story that it can sink its sharpened, yellowing canines into. And for the security community, the OpenSSL heartbleed vulnerability has been the equivalent of a 72-ounce steak. But an Internet-breaking vulnerability like this one is no good unless we can learn something from it (or at least give it a clever hashtag).
So let’s have a look at what’s gone down in the last few days and see what lessons we can take from all this.
The Internet is brittle. Actually, this isn’t a new lesson. The people who think about these things for a living have been saying this for years, or decades, in some cases. But they’ve probably been too kind. The Internet is a fish shack in the Florida Keys propped up on stilts, and the constant battering from the waves and erosion of the sea floor are taking their toll. It’s sort of listing to one side and there’s some barnacles growing on the pilings, but it’s still standing. For now. The infrastructure that supports the Internet is fragile and it’s dependent upon a small handful of old protocols. And that kind of prey rarely escape the notice of predators for long.
The long-term effects may be silent but deadly. OpenSSL is everywhere. Everywhere. By some estimates, it’s implemented on about two-thirds of Web sites, large ones, small ones, in-between ones. A good number of the owners of the sites that use OpenSSL likely have no idea that their sites are affected, because they rely on hosting providers. And let’s not forget about the untold number of embedded devices that may have OpenSSL implemented in their firmware. Those devices are much harder to locate, test and patch than a typical Web server is.The really bad news, though, is that we may not know the ultimate effect of this vulnerability for some time, as it’s difficult to know whether an attacker has exploited the bug on a given target. We may see data breaches months from now that involve an attack on the OpenSSL vulnerability. And it is also difficult to determine how many sites have patched their systems, without a massive scan.
Breaking crypto–don’t do that. There’s been no shortage of speculation about the possibility of the NSA having an unspecified capability to break an encryption system such as SSL. But much of what we’ve seen from the leaked documents has shown that the agency, like most attackers, relies on implementation flaws and vulnerabilities in the code. They don’t need to build a supercomputer in a cave in North Dakota to break a cryptosystem when they can rely on someone making a mistake and get the same result. Human error is much more common than the ability to break an encryption algorithm.
The disclosure debate is still a thing. Well, sort of. News of the OpenSSL vulnerability first appeared Monday when the OpenSSL Project posted an advisory with a short description of the problem. Quickly, the scope of the vulnerability began to sink in and researchers realized how many sites, systems and devices could be vulnerable. Then people began wondering why some companies and vendors apparently had early warning about the vulnerability and others didn’t get the same courtesy. That discussion went downhill rather quickly. Large-scale vulnerabilities like the OpenSSL bug, by their nature, make it almost impossible to warn every company, site owner or vendor that’s potentially affected. This isn’t a flaw in a product with four customers. It’s the whole Internet. Neel Mehta, the researcher who discovered the bug, reported it to OpenSSL, which produced a patch and alerted users. That’s how things should work.
Internet-wide bugs still happen. Vulnerabilities like this one are, thankfully, relatively rare. Major bugs in ubiquitous software happen on a regular basis (see: Web browsers). We’ve seen serious problems in Apache, the DNS system, Microsoft IIS and other software that run large parts of the Internet in the past, and they’ve caused major problems in some cases. The OpenSSL vulnerability has all the makings of that level of vulnerability, given the package’s ubiquity and the potential consequences of a successful exploit against it. We think of systems such as utilities, SCADA and others as critical infrastructure, but, as Dan Kaminsky points out in his essay on heartbleed, there is entirely separate class of software that qualifies for that description. And that’s where the big fish still lie. “The answer is that we need to take Matthew Green’s advice, start getting serious about figuring out what software has become Critical Infrastructure to the global economy, and dedicating genuine resources to supporting that code. It took three years to find Heartbleed. We have to move towards a model of No More Accidental Finds,” Kaminsky wrote.
Image from Flickr photos of Dorothy Finley.
