When the OpenBSD foundation sent LibreSSL out the door last weekend, it was with the full intention of getting some feedback and scrutiny in return, all in the name of making the crypto library stable and secure.
What they likely didn’t expect were claims surfacing that LibreSSL shared some of the same fundamental weaknesses as OpenSSL, from which it was forked.
A Linux developer and administrator yesterday posted a notice on his website that the pseudo random number generator in LibreSSL is less safe than the OpenSSL PRNG that it is intended to supplant.
Andrew Ayer, founder of secure backup service Opsmate, provided an example of a test program which, when linked to LibreSSL and made two different calls to the PRNG, returned the same data. He called it “a catastrophic failure of the PRNG.” The same test program when linked to OpenSSL returned different data each time.
“After testing and examining the codebase, my feedback is that the LibreSSL PRNG is not robust on Linux and is less safe than the OpenSSL PRNG that it replaced,” Ayer said.
Requests for comment and confirmation from OpenBSD founder Theo De Raadt and OpenBSD developer Bob Beck went unanswered prior to publication.
LibreSSL 2.0.0 and 2.0.1 were released over the weekend and support a number of platforms beyond OpenBSD, including several Linux flavors, as well as Mac OS X and Solaris.
The OpenBSD Foundation announced its intention to fork OpenSSL in April and spent considerable time before then and since cleaning up volumes of code that bloated OpenSSL. LibreSSL surfaced after the disclosure of the Heartbleed OpenSSL vulnerability.
“I firmly believe that LibreSSL is in a better situation than OpenSSL is now,” Beck told Threatpost Tuesday. “Having said that, is there more cleanup to do? Absolutely. But if I had a choice between this or OpenSSL, I’d pick this.”
The OpenBSD team has been carefully considering what to eliminate or re-write from OpenSSL into LibreSSL. OpenSSL, meanwhile, remains a popular cryptographic library, used in a large number of applications, but for too long has suffered as an under-funded, under-staffed initiative. That neglect led to a lifeline from the Core Infrastructure Initiative, which pledged enough funding to hire two full-time developers and pay for an audit of the OpenSSL code, similar to the TrueCrypt audit.
Ayer said the problem with the LibreSSL PRNG stems from features meant to make it “fork-safe.”
“The problem is that LibreSSL provides no way to safely use the PRNG after a fork. Forking and PRNGs are a thorny issue – since fork() creates a nearly-identical clone of the parent process, a PRNG will generate identical output in the parent and child processes unless it is reseeded. LibreSSL attempts to detect when a fork occurs by checking the PID,” he said. “If it differs from the last PID seen by the PRNG, it knows that a fork has occurred and automatically reseeds. This works most of the time. Unfortunately, PIDs are typically only 16 bits long and thus wrap around fairly often. And while a process can never have the same PID as its parent, a process can have the same PID as its grandparent. So a program that forks from a fork risks generating the same random data as the grandparent process. This is what happens in the fork_rand program, which repeatedly forks from a fork until it gets the same PID as the grandparent.”
Beck said in April that 90,000 lines of C code had already been deleted and the code had been converted to modern C programming practices, including modern memory allocation practices and integer overflow avoidance, just to name two. The LibreSSL developers had also 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.
