A survey of software libraries used in many companies’ products suggests we may see more incidents like the Heartbleed bug.
For a few days in April, the whole world seemed to take Internet security very seriously. A critical flaw, dubbed Heartbleed, was found in software used by hundreds of thousands of websites, and the bug together with its logo became a media star.
But by late June, just over two months later, the effort to patch vulnerable Internet servers against Heartbleed appeared to have stalled, with more than 300,000 still on the Internet. OpenSSL, the open source project in whose software the bug was found, still lacks the resources it says it needs to keep its code safe. What’s more, new research suggests that the circumstances that turned Heartbleed into such a large-scale problem are commonplace.
Kymberlee Price of the security company Synack and Jake Kouns, CEO of nonprofit the Open Security Foundation, presented results of a survey of the usage and security of open source libraries on Thursday. They highlighted several open source libraries that are extremely widely used but have spotty security. A flaw in one of these libraries could have a similar impact to April’s headline-grabbing bug. “It absolutely could happen again with any third-party library,” Price told MIT Technology Review at the Black Hat conference last week.
“What is really eye-opening is that certain programs or products out on the market can have hundreds of those libraries in,” said Kouns. “Everyone is now exposed to this systemic risk.”
One of the libraries identified by Price and Kouns as a potential problem is the source of Heartbleed, OpenSSL. Several other flaws have been discovered in OpenSSL since Heartbleed, some of which may be more dangerous that the Heartbleed bug, said Kouns.
More can be expected. Despite the publicity boost from Heartbleed, OpenSSL still doesn’t have enough money to deal with such problems. After the incident, the project conducted a review and estimated it needed six full-time developers to properly maintain the software. Money pledged by IBM, HP, Google and other major tech companies in the wake of the bug has been enough to pay for only two full-time developers. “Even something that people’s moms were asking them about at the dinner table isn’t getting the support it needs,” said Price.
Another potentially problematic library is FreeType, which is used to display fonts, and is included in more than a billion devices made by companies including Apple, Google, and Sony. Kouns and Price counted more than 50 vulnerabilities found in FreeType over the past seven years. One formed the basis of an attack called “Jailbreakme” that made it possible to remotely take over iPhones (see “Got an iPhone? There’s an App for Hacking That”).
Other open source libraries flagged by the pair include LibPNG, used in hundreds of common devices and software as a way to display images, and FFMpeg, which Apple, Google, Microsoft, and Sony rely on to play video.
Most of the widely-used libraries are updated multiple times per year with security fixes, says Price. But it is not easy for software engineers to keep track of all those updates or even which versions of which libraries their company is using. And few companies apply every update of every library in a timely manner, said Price. More often, companies upgrade the libraries only when they release a new version of their own product. “If you’re only updating with each of your releases you’re probably missing some major vulnerabilities,” she said.
Some experts believe that software companies should be made legally liable for security problems in their products. One option discussed among executives at Black Hat was whether investors should have the power to call for third party audits of a company’s code, extending a process that is already a standard part of due diligence for mergers and acquisitions, Price said.
Dan Geer, chief information security officer for the CIA’s investment fund In-Q-Tel, made a more radical suggestion in his Black Hat keynote Wednesday. He called for legislation that would make software companies liable if security problems in their products caused harm.
“The only two products not covered by product liability are religion and software, and software should not escape for much longer,” Geer said. He suggested software companies be liable for whatever damages occur due to flaws in their software, but that companies that made their full source code available for inspection would only be required to give a refund if damage occurs.
That proposal would meet strong opposition from the software industry and is unlikely to gain traction. Price said the most practical – if partial – solution for now is to raise awareness of the risks that come with third party libraries, and to create tools that make it easy to be notified of the latest flaws and update the packages. “We can’t eliminate this risk, so we have to manage it,” she said.
© 2014 MIT Technology Review