Here’s something else to blame on last April’s Heartbleed security bug: It smeared the line between security holes that users can do something about, and those we can’t. Getting that distinction right is going to be crucial as we weather a storm of vulnerabilities and hacks that shows no sign of abating.
Last week the OpenSSL Foundation announced it was patching six newly discovered vulnerabilities in the same software that Heartbleed lived in. The first reaction from many of us was a groan–here we go again. Heartbleed triggered what was probably the single largest mass-password change in history: In response to the bug, some 86 million internet users in the U.S. alone changed at least one password or deleted an internet account. The thought of a repeat was (and is) shudder-inducing.
But the truth is, the new vulnerabilities have nothing in common with Heartbleed except that they inhabit the same software–the OpenSSL crypto library responsible for encrypting traffic for about two-third’s of the world’s web servers. They aren’t nearly as bad Heartbleed, and there’s no reason to change passwords.
The most serious of the bugs allows a hacker lurking between a user and a website–perhaps someone parking on a coffee shop’s open WiFi–to trick both sides into using weak encryption that can be easily cracked. For the attacker to make use of the new bug, he has to already be in a position to do many other evil things, like spy on your unencrypted traffic.
And it turns out, you’re only in danger if your computer and the server are both running the vulnerable code–and most popular browsers don’t use OpenSSL. Firefox, desktop Chrome, Safari, and Internet Explorer aren’t affected. (Chrome on the Android was vulnerable).
Together, these limitations make the new hole about a zillionth as serious as Heartbleed, from a consumer perspective. It really doesn’t compare.
Heartbleed wasn’t a crypto bug. It was worse. It allowed an attacker to remotely read a random chunk of 64 thousand bytes of the web server’s memory–and to do it quickly and easily, without commitment or risk. Anything in the server’s memory could be exposed, including user password and session cookies.
Though Heartbleed resided in encryption code, it could just as easily have been in code that resolves website addresses or synchronizes the computers’ clock. Unlike the new bugs, it had nothing to do with the core purpose of OpenSSL.
Normally, a published vulnerability in server code is a massive headache for system administrators but not for users. At large consumer-facing companies like Yahoo and eBay, an announcement of a security hole sets off a race between website administrators and black hat hackers: The admins need to test and install the patch before the hackers produce attack code that lets them use the vulnerably to pillage. It’s a ritual that’s ruined many late nights and weekends, but if the admins win the race, everything’s fine.
Only if they lose does the vulnerability becomes an intrusion, with all the resulting fallout–clean-up, forensics, notification e-mails, password changes, apologies, and public statements about how seriously the company takes security.
Heartbleed changed that well-worn pattern. Unlike most vulnerabilities, it was virtually impossible to tell if the bug had been used against a website–it left no traces, no fingerprints. It was also relatively easy to exploit. Heartbleed attack code began circulating the same day the vulnerability was announced. The race was lost while the echo of the starting gun was still ringing in the air.
Even then, the user reaction would probably have been muted. But a Netherlands-based security company called Fox IT actively (and courageously, given the U.S.’s broad computer crime laws) executed Heartbleed against Yahoo and posted a redacted screenshot of the memory dump. The image showed a user named Holmsey79 was logged into Yahoo at the time, and that his password was exposed. That single screenshot proved in an instant that Heartbleed was a real and direct threat to user data. Nobody could brush it aside as a theoretical problem.
So even as the patching was underway, users of virtually every top website were urged to change their passwords. The Pew survey in April found that 64 percent of Internet users had heard of Heartbleed, and 39 percent had either changed passwords or canceled accounts.
Whether you actually needed to change your passwords depends on your personal risk tolerance. Heartbleed has an element of chance to it. The attacker can’t target a particular individual’s password–the attack is more like dumpster diving at an office park and hoping to find something good. The odds of any one person being a victim were small. But some number of users–like Holmsey79–undoubtedly were exposed.
I changed no passwords in response to Heartbleed, but I generated new keys for my SecureDrop anonymous tip box and relaunched it at a new address. As a user, I wasn’t that worried. As a sys admin of my own server, I was very worried.
As bad as Heartbleed was (and is–countless thousands of website remain unpatched), it actually marked an improvement in what we consider a critical security hole. Ten or 15 years ago, a critical bug in server code was one that allowed hackers to get remote root on the machine–not just peek into its memory at random. There were tons of these bugs–in Microsoft’s IIS web server, the BIND open source DNS software, Microsoft’s SQL server. In addition to giving hackers complete access, these holes were “wormable,” meaning black hats could write exploits that would infect a machine, and then use it to spread to more machines. These are the vulnerabilities that spawned worms like Code Red and Slammer that ripped through the Internet like a natural disaster.
With those bugs, nobody was under the impression that the regular old users could counter the risk by changing their passwords. But Heartbleed was showered with so much attention, and came with some a clear and actionable prescription, that it cemented the idea that we can personally counter a massive internet security hole by being diligent users. In a way, it was almost empowering: It’s natural to want to do something when there’s a scary security announcement. Changing passwords makes us feel we have some control over the situation.
But Heartbleed was an exception, not the rule. The new OpenSSL holes are far more typical. The next time the internet gets in an uproar over a web server security bug, the best thing to do is take a deep breath.
That doesn’t mean you can ignore every security hole. A bug in a browser or a consumer operating system like OS X or Windows definitely requires action on your part–usually a software update, not a password change.
But server-side bugs like the new OpenSSL holes point to deeper problems that won’t be solved by changing your passwords. These are infrastructure issues–crumbling overpasses on an aging highway. Changing the oil in your car won’t help.
Provided from: wired.