The Web has been abuzz with discussion of the HeartBleed flaw. Security vendors and experts have been falling all over themselves to offer advice on detecting or mitigating the flaw; consultants have been offering businesses advice on how to deal with the problem; businesses with websites have been fretting about how to respond; the NSA has been accused of having known about — and exploited — the vulnerability; and the Obama administration has said that the NSA should disclose vulnerabilities like this unless they impinge upon national security.
Nowhere in all the excitement is there any mention of how much work is done for little or no reward by the volunteers at the OpenSSL Project, which created the code containing the HeartBleed vulnerability.
The many large corporations that use OpenSSL have hastened to inform their customers and the public that they are working to remediate the problem. None of them, however, have said anything about how much time or money they are investing to help the OpenSSL Project in its work.
Most major commercial firms use OpenSSL encryption, which has become the most widely used encryption on the Web.
Working Hard for the Money
The OpenSSL Project’s developers are “mostly part-time volunteers with full-time day jobs,” Steve Marquess, president of the OpenSSL Foundation, which was set up to handle the business and financial transactions the project requires, told LinuxInsider.
“Commercial vendors worldwide have utilized OpenSSL heavily, and that’s great,” Marquess said, “but last year, which was typical, we received a grand total of under (US)$2,000” in donations. That sum “doesn’t cover much due diligence, which goes entirely unappreciated until it is found wanting.”
The donations are presented at the end of the year to the project member “who did the most thankless work that year,” Marquess remarked.
The foundation earns some money from commercial contracting, which is the only source of income for project members without full-time outside employment, Marquess disclosed. It also has annual software support contracts with some customers.
Project members have a heavy workload because “the very high level of skill and experience needed to effectively contribute to OpenSSL is a rare commodity, and those who have it tend to be in high demand by employers and other causes,” Marquess pointed out.
It’s not as if Marquess hasn’t tried to remedy the OpenSSL Project’s funding and manpower shortages. “I have had discussions with a number of companies, with limited results,” he said, but he declined to name any specific companies.
OpenSSL’s Response to the Flaw
OpenSSL has been around since 1998 and “any code base, especially one with such complexity, requires an appropriate degree of scrutiny,” Zulfikar Ramzan, CTO of Elastica, told LinuxInsider.
However, the lack of adequate funding and the shortage of staff at the OpenSSL Project make it difficult to eyeball code as closely as should be done.
“More manpower to invest in the tedious and unsung toil of code review would help,” Marquess said. “Formal could audits would be great but would require funding we don’t have.”
That having been said, commercial software is itself bug-ridden, and here’s where the two differ: The OpenSSL Foundation reacted promptly to news of the flaw and provided a fix, and the German programmer who submitted the flawed code, Robin Seggelmann, apologized publicly.
Software vendors often don’t remedy flaws until prodded to do so by disclosures from researchers, and who can forget Steve Jobs telling customers they were holding the iPhone incorrectly when complaints about the iPhone 4’s reception surfaced?
“This [HeartBleed] problem reinforces the fact that even open source software, which has lots of eyes looking at it, is prone to security flaws,” Martin Gallo, senior security consultant at Core Security, told LinuxInsider. “But commercial software is no different, and fixing issues with it could be more difficult because you can rely only on the software’s vendor.”
More Help Is Needed
“HeartBleed will not be the last vulnerability found in OpenSSL,” warned Elastica’s Ramzan, because “it is a complex code base and is constantly evolving, which means the likelihood of a future issue is all but a certainty.”
The speed with which existing vulnerabilities are discovered and new vulnerabilities are prevented “will be commensurate with the quality of technical resources devoted to the project,” Ramzan continued.
Whether the new issues will be as severe as HeartBleed is uncertain, but “if we want to mitigate the risk of another HeartBleed it will be important to have more people contribute to, and scrutinize, OpenSSL,” Ramzan said.
The idea of releasing code to open source is that if the code is publicly available and can be inspected, then security issues can, in theory, be identified more quickly. This openness also exposes the code more readily to bad guys, however, and, “as projects become under-resourced by good guys, they can come under increasing risk,” Ramzan said. “Ultimately, we need to ensure that the scales don’t tip excessively in the wrong direction.”