Funding from the Core Infrastructure Initiative has helped the maintainers of OpenSSL, one of the Internet’s most-deployed pieces of open source software, begin to get the crypto implementation on its feet.
Despite its ubiquity, OpenSSL has historically been under-funded and under-resourced, though no one outside those close to the project knew how dire the situation was until Heartbleed and other Internet-wide bugs started experts looking closely at the security of open source software.
With funding from CII and other corners of the Internet, full time help has been hired to maintain the regular flow of patches and feature upgrades, and since last spring, get the code base ship-shape for a full-fledged security audit.
NCC Group Cryptography Services, the security company behind the first phase of the TrueCrypt audit, Monday announced that it, in partnership with the Linux Foundation, will conduct an audit of OpenSSL, looking at key components likely to put installations at risk in the event of a critical vulnerability.
-Tom Ritter
“A number of folks who have contributed their free time and professional time, kept OpenSSL growing,” said Tom Ritter, principal security engineer at NCC. “A lot of those contributions were around making OpenSSL more efficient and improving speed—and security improvements. Now, being able to have people work on it fulltime in a maintenance capacity goes long way. Any project that old accumulates technical debt takes that takes time and effort to pay down. Having fulltime focus on bug maintenance is super important.”
OpenSSL’s code cleanup paved the way for the audit, Ritter said. Engineers spent significant time re-reading areas of code of most concern—and fixing bugs along the way—in order to make the code more reliable, consistent and secure. Ritter said work on the audit should begin shortly, and the first set of results will be made available mid-Summer after OpenSSL has had time to review the results and patch.
Ritter said the audit will be concentrated only in certain critical areas of the OpenSSL codebase, and will not be comprehensive. In scope are the TLS stacks, covering protocol flow, state transitions, and memory management. The BIOS, high-profile crypto algorithms and fuzzing of the ASN.1 and x509 parsers will also happen, Ritter said, adding that input and feedback from the current OpenSSL team also contributed to what ultimately ended up in scope for the audit.
“We chose areas around OpenSSL where a flaw here might be of higher severity than other areas,” Ritter said. “The types of things we’ll be looking for are things such as protocol mishandling or state transitions, things like that, even timing attacks in crypto algorithms, or memory corruption that would yield a denial of service condition or remote code execution. Those are the types of bugs looking for. If find one of those, it has the possibility of being fairly critical.”
In scope for OpenSSL audit: TLS stacks, covering protocol flow, state transitions, and memory management. via @Threatpost
Tweet
Unlike the TrueCrypt audit where one of the stated goals was to determine whether the popular encryption software had been backdoored, that isn’t necessarily the case with OpenSSL, Ritter said.
“You haven’t heard much about [backdoors] in OpenSSL,” Ritter said. “Our real goal is to find any sort of exploitable security concerns. I think that we’re focusing on it from the perspective of a security audit.”
Expect Ritter and his team to spend plenty of time in front of large whiteboards for the next few months, tracing out function flows and diagram the code in order to support the manual and automated code review it will take to properly assess OpenSSL. And while the audit may not yield something as dramatic as Heartbleed, you can expect Ritter’s team to be looking in that direction.
“Certainly looking at historical bugs in the platform gives us an idea of the types of flaws present still; it will be helpful,” Ritter said. “I’m not going to say we’re doing to go in expecting to find any particular bug in a particular area, but looking at historical bugs does guide us in certain areas as do a lot of the less high-profile bugs. Looking at just about any bug and seeing the underlying causes of it gives us a sense that if something similar is happening elsewhere, there could be a bug there.”
