Analysis: What lessons can be learned from the Heartbleed fiasco?
Five days after the news broke, it is becoming clear the continuing furore over the Heartbleed bug holds important lessons for the IT industry both about the way it responds to major incidents and also the way software is produced.
On Monday researchers at Google and Finnish security firm Codenomicon revealed a vulnerability in the widely used encryption library OpenSSL, a variant of SSL/TLS encryption technology, that could allow hackers to access the memory of supposedly secure systems.
While it is unclear exactly how many devices could be affected by the flaw, early estimates have predicted that it could be in use in as many as two-thirds of websites to secure sensitive traffic, though not every website using the software will be vulnerable. The technology, as well as other rival products offering similar protection, is visible to users in the form of a green-padlock icon on the left of their web address bar that shows when the technology is in use.
The vulnerability is in the software’s TLS (Transport Layer Security) heartbeat extension, a feature that makes it possible to keep the secure channel between the web server and the user open by sending a heartbeat message from one side of the connection to the other to ensure the connection is still there. One side will send the other side a small amount of data and the receiving side is meant to send back exactly the same data.
However in OpenSSL the code that tells the replying side how much data has been sent is user defined, which means that anyone looking to exploit the vulnerability can send a small packet of data of just a few bytes while telling the replying side that it has sent anything up to 64KB. The replying side will then return the data received, but also a chunk of data adjacent to it in its memory to make up the 64KB. In this way the heartbeat message can be used to bleed extra data from the victim’s memory in up to 64KB portions.
“Every time you send a request it is likely to be put in a different bit of physical memory,” says cyber security specialist Professor Alan Woodward, of the University of Surrey. “It’s more than likely you will get different fragments back each time so a full attack would keep sending requests and get back as much memory as it could before piecing it together later.”
In this way a hacker could lift passwords, email exchanges, bank account details and a host of other personal information that Web users have sent to a website in the belief that the communications were secure. Even more concerning is that such an exploit could be used to lift SSL keys, which would allow the attacker to decode any secure traffic in or out of the site, and would mean that even after installing patches to fix the problem sites would also have to remember to reissue new keys.
Add to this the fact that the flaw was introduced to the OpenSSL code more than two years ago and that there is no way to tell if an exploit has taken place, and it is understandable why the news has hit even the mainstream headlines. Hacking groups have even been detected runningautomated scans of the Internet in search of servers vulnerable to the bug.
Luckily the vulnerability only affects versions 1.0.1 to 1.0.1 of OpenSSL and patches to fix the vulnerability have been released and quickly implemented by most of the major websites who have admitted they are affected. But what is worrying researchers now is news that the bug could also affect embedded devices such as Internet routers, virtual private networks (VPNs), teleconferencing equipment, point-of-sale terminals and even industrial control technology.
“All that firmware is much more difficult to upgrade so there might be quite a long and nasty tail to this,” says Woodward. “How many people at home know how to upgrade the firmware in their router? I suspect that while the risk to the domestic user is low there will be a lot of businesses out there using this equipment.”
While the potential scale of the problem caused by the bug is sizeable, web users have been subjected to conflicting messages about what they can do to limit their exposure. Hugh Boyes, the Institution of Engineering and Technology’s (IET) cyber security lead, believes the response from the cyber security industry has been far from perfect and the incident could hold lessons for future widespread problems such as this.
“It’s serious, but it’s not the end of the Internet. The problem is you always have these elements of the IT security industry that always want everything to be a Doomsday scenario,” he says. “I’ve been monitoring the stuff coming out. There’s been all sorts of different advice: change your passwords; don’t change your passwords; everybody’s affected; no, not everybody’s affected. Unless you’re very clued up as an IT geek it’s potentially very confusing.
“From an industry perspective I think we need to think about how we handle incidents like this and how you reassure your customers and users who are not at risk.”
And the timing of the problem could not be worse for the security industry. On Tuesday Microsoft stopped offering technical support and security updates for its Windows XP operating system, potentially opening the door to a host of security issues. In response the IT community has been trying to encourage users to upgrade to supported operating systems, but Boyes is worried this message will be lost among the furore surrounding Heartbleed.
“In terms of the longer term threat XP is probably very significant,” he says. “Now you’ve got this incident occurring, which raises the consciousness of security issues, but any message about XP will have disappeared under the Heartbleed outpouring.”
The comparison with the XP issue raises another important aspect of the Heartbleed fiasco – the software is open source meaning that anyone is able to view the code, unlike in propriety systems where companies jealously guard the make-up of their software. In theory this should increase the level of scrutiny software is subjected too and make it less likely for bugs in the code to slip through the net.
But in the case of OpenSSL its core development team is made up of just four volunteers who rely on donations and sponsorship. The German software developer responsible for the flaw Dr Robin Seggelmann has put his hands up to the error in an interview with the Sydney Morning Herald, but pointed out that it was also missed by a reviewer when it was introduced into the OpenSSL encryption protocol over two years ago. “How can something so vital on the web be down to just four programmers, only one of whom is full time?” says the University of Surrey’s Woodward.
The fact the error was made in the first place is made more understandable by the fact that OpenSSL is written in the C programming language, an older language which requires everything to be explicitly spelled out by the programmer unlike more modern languages. “It was a small error that frankly any of us could have made,” says Woodward. “It’s different for old legacy code where it’s easier to make mistakes. It’s simpler to overlook things like memory management.”
While the incident is likely to raise questions about the merits of an open source approach, the IET’s Boyes is keen to stress that there are many companies who do not make their code public that have suffered from serious bugs such as this. “Both open source and closed source have problems with software quality,” he added.
Regardless of the open source, closed source debate the incident does raise general issues about software quality control. The IET has been contributing towards the government-funded Trustworthy Software Initiative (TSI) – a not-for-profit organisation based at the Cyber Security Centre of De Montfort University designed to evangelise about the need for software trustworthiness and help draw up guidelines for programmers. Boyes believes incidents such as the Heartbleed bug emphasise the importance of this kind of project.
“There’s a strong case saying that the IT industry really does need to improve its software engineering and reduce the number of bugs out there,” he says. “The current trend is just to push out software then issue the updates. That really isn’t a good business model and it’s arguably a differentiator that is emerging – whether a supplier offers trustworthiness.”