Portable LibreSSL appears as project inches towards prime time

Over the weekend, the first and second versions of a portable LibreSSL package were released by the OpenBSD Foundation.

The release of LibreSSL's 2.0.x series is the first to officially support running on operating systems other than OpenBSD, with "various versions" of Linux, Solaris, Mac OS X, and FreeBSD now supported.

"This is intended as an initial release to allow the community to start using and providing feedback," said OpenBSD Foundation director and OpenBSD developer Bob Beck. "We will be adding support for other platforms as time and resources permit."

While the library has gained support for new operating systems, it is not yet ready to be the drop-in replacement for OpenSSL that the OpenBSD Foundation intends for it to be.

Gentoo developer Johannes "Hanno" Böck detailed the process of switching out OpenSSL for LibreSSL over the weekend, and while to an external user the systems appear almost identical, internally, there are a number of loops still to jump through to have a functioning system.

Böck said the most interesting issue he encountered was building OpenSSL to depend on LibreSSL, both of which are developed by OpenBSD.

"To understand this you have to understand how both LibreSSL and OpenSSH are developed," Böck wrote. "They are both from OpenBSD and they use some functions that are only available there. To allow them to be built on other systems they release portable versions which ship the missing OpenBSD-only-functions. One of them is arc4random()."

"Both LibreSSL and OpenSSH ship their compatibility version of arc4random(). The one from OpenSSH calls RAND_bytes(), which is a function from OpenSSL. The RAND_bytes() function from LibreSSL however calls arc4random(). Due to the linking order OpenSSH uses its own arc4random(). So what we have here is a nice recursion. arc4random() and RAND_bytes() try to call each other. The result is a segfault."

The fix that Böck found was to copy across LibreSSL's arc4random.c file to OpenSSH, which he said worked "surprisingly well" and after a number of other fixes and patches, was able to have a test system that used only LibreSSL.

The OpenBSD team took the decision to fork OpenSSL and create LibreSSL after looking at OpenSSL's source code after the Heartbleed bug was revealed.

In a status update of the LibreSSL project delivered in May, Beck said that it wasn't Heartbleed that created the urge to fork OpenSSL, a decision by the developers of OpenSSL to create their own custom memory allocator. implementation did.

"Essentially, they decided malloc is slow on some platforms, so let's assume that malloc is slow everywhere," said Beck.

"Let's implement our own cache that never frees anything and just reuses the objects. Better yet, the way that it reuses objects is it keeps a last-in, first-out queue, so if you actually are doing a use-after-free, chances are excellent that that object is still there."

"Matter of fact, it's almost certain that if you free something and use it immediately, that thing is still there and it doesn't matter that you freed it."

Beck said that the custom allocator made Heartbleed "that much worse", and was a "very effective exploit mitigation technique countermeasure" as it "could not have been designed better" to make attacks hard to detect.