Heartbleed may have been the final straw, but the movement to create a fork of OpenSSL called LibreSSL had its roots in another issue that made the crypto libraries untenable for folks at OpenBSD.
LibreSSL is an initiative spurred on by OpenBSD founder Theo de Raadt to split off and develop a cleaner version of OpenSSL, not only in terms of security vulnerabilities but also updating the code and programming practices.
Bob Beck, an OpenBSD developer, told Threatpost via email that 90,000 lines of C code have already been deleted as the code has been converted slowly to modern C programming practices, including modern memory allocation practices and integer overflow avoidance, just to name two.
“I’d say we’ve probably already ‘improved’ it,” Beck said. “For the time being we want to make sure that other than anything we find that is intrinsically dangerous, we want to preserve API compatibility so
we don’t break all the software out there that uses this.”
Beck said the discussion about forking OpenSSL began not with Heartbleed but with the implementation of a LIFO (Last In, First Out) memory cache that killed compatibility tools such as Coverity and Valgrind that are used for memory debugging and leak detection that help sniff out critical bugs in code.
“Forking isn’t something we take lightly, we know darn good and well it’s a lot of work, however it had become painfully obvious in the past while that we would not be getting useful fixes from upstream,” Beck said. “For myself, and for Theo, I know it’s been in the works seriously since we saw that allocator. Once the idea started being shopped around in our developer community it became clear that many other developers in OpenBSD were not sad to see this happen, and had some prior experience in the area that enabled things to take off quickly. For the most part, once we started finding the worst of the horror, it was a case of whining or acting. We decided to act.”
Since the public disclosure of the Heartbleed OpenSSL vulnerability and the rush to not only patch infrastructure reliant on the library for encryption, but also the revocation of hundreds of thousands of digital certificates, people are taking a closer look at OpenSSL development and the lack of human and capital resources available to the project.
“The OpenSSL team, which is surprisingly small, has been given the task of maintaining the world’s most popular TLS library. It’s a hard job with essentially no pay. It involves taking other folks’ code (as in the case of Heartbeat) and doing a best-possible job of reviewing it. Then you hope others will notice it and disclose it responsibly before disasters happen,” wrote Johns Hopkins professor and crypto expert Matthew Green. “The OpenSSL developers have a pretty amazing record considering the amount of use this library gets and the quantity of legacy cruft and the number of platforms (over eighty!) they have to support. Maybe in the midst of patching their servers, some of the big companies that use OpenSSL will think of tossing them some real no-strings-attached funding so they can keep doing their job.”
Beck said the basic crypto algorithms in OpenSSL work just fine because they were written by cryptographers.
“That’s the minority of the code,” Beck said. “The rest is all about protocol conversion, packaging objects to send over the network, and getting entropy to generate keys.”
The LibreSSL developers have found 20-year-old chunks of unmaintained code in OpenSSL, “abandonware,” as Beck put it, code that was added for FIPS certification and never attended to again.
“Important bugs sat in OpenSSL’s tracker for four years—until we found them and fixed them in our tree,” Beck said. “Most of the code doesn’t use anything approaching best practices for modern C code. Lots of it will make your eyes bleed and roll backwards into your skull as your brain tries desperately not to see it. There are lots of magical string lengths in there that we are slowly killing.”
In addition, Beck said, a good number of these issues are exposed a visible APIs to other applications, and they’ve been busy converting the library not to use them.
“Long term it would be better to have none of that stuff in there at all,” Beck said. “We’ve found a few things that might scream ‘interesting’ to an exploit author, but we’re not exploit authors or bug bounty chasers. We’re C programmers. We look at this and say ‘That ideom is dangerous.’ We find lots of those, we rip them out and replace them with what we know to be safe.”
