LibreSSL ships first portable version, now up to 48% less huge!

Filed Under: Cryptography, Featured, Vulnerability

Just under three months ago, we wrote about a coding project called LibreSSL.

LibreSSL was started by the redoubtable OpenBSD team in the wake of the Heartbleed vulnerability in OpenSSL, a very widely-used open source cryptographic toolkit for secure communications.

Heartbleed revisited

In case you missed the excitement, Heartbleed was an OpenSSL buffer overflow bug that allowed one end of a TLS connection (client or server, it didn't matter) to trick the other end into barfing up 64KB chunks of its own private memory space.

Of course, the memory space of programs like web servers, even randomly sampled in comparatively small grabs, can contain extremely interesting, not to mention confidential, data.

As you probably know, so-called RAM scraping malware snoops on memory, albeit more systematically, to steal things like credit card numbers, which are usually encrypted on disk, but unencrypted in memory.

As US retailer Target found out at the end of 2013, malware that snooped on memory in Target's tills managed to steal about 40,000,000 credit cards in just a few weeks.

Heartbleed didn't provide anywhere near the precision of RAM scraping malware, but you didn't need to infect the other end with malware first.

You could mount an attack from almost anywhere on the internet, and keep prodding the server at the other end over and over again, thouands or even millions of times, in the hope of stealing confidential data from other users' connections.

Such as passwords, Canadian Social Insurance Numbers, and perhaps even the private keys of the server itself.

Heartbleed relied on buggy code that copied data from an input buffer without checking its size, so you could send the server 12 bytes, say, but ask it to send you back 65535, consisting of your 12 bytes and whatever happened to follow your input buffer in RAM.

How did the bug escape notice?

Disturbingly, the bug had been in the OpenSSL code for two years, which raises the question, "Even if humans missed it in static analysis, how come run-time verification tools and buffer overflow checkers never triggered in all that time?"

One reason, as OpenBSD explained back in May 2014, was that OpenSSL's memory handling is written so as to make the product's behaviour opaque to external bug checkers.

As Bob Beck of OpenBSD quipped, OpenSSL's memory management acts as a sort of "exploit mitigation countermeasure."

By asking the operating system to give it a big chunk of memory up front, and then "sub-letting" that memory itself inside the code, OpenSSL aims to boost efficiency slightly, but at considerable cost to safety.

So even if you run it on an operating system like OpenBSD, configured for strict checks on memory usage, you'll see what looks like clean behaviour along the lines of "give me a giant buffer at the start" followed by "here it is returned in good order at the end."

Even under a bug-finding tool like Valgrind, which deliberately reduces efficiency in return for scrupulously auditing every chunk of memory allocated, bugs and anomalies are covered up.

In a way, OpenSSL's memory management is a bit like getting a monthly bank statement that lists only your closing balance.

If individual transactions are suppressed, you can't tell what the bank has actually been doing with your money, even though you might have the right amount left over.

Have your creditors really been paid, or have your outgoings been remitted somewhere else? Have large and unexplained deposits suspiciously come and gone without you being aware?

Smaller is better

So, amongst other improvements, the LibreSSL coders have been increasing the quality of the OpenSSL code by decreasing its size.

They've thrown out the extra layer of memory management so that bugs are much more likely to show up sooner.

They're re-organised the code into a consistent style so that it's easier to read and review.

They've banished large quantities of complex and error-prone code hacks that were there only so that OpenSSL could still work (if anyone ever bothered to test it) on platforms including DOS and 16-bit Windows.

Despite that, they have produced, or have tried very hard to produce, a product that is a drop-in replacement for OpenSSL that operates in a compatible way (minus some of the bugs and much of the opacity, of course).

And they've just released their first version that isn't for OpenBSD only.

The hope is that others will take it, try it, and report back what they find,now that a lot of the impenetrability of OpenSSL has been cut away.

It's supposed to compile on "any reasonably modern version of Linux, Solaris, or OS X with a sane compiler and C library."

It worked for me on OS X.

Let me qualify that: it built cleanly with the Clang compiler and passed its own self-tests, which is hardly "working," but it's a good start for a Saturday evening!

If you're a coder interested in security, why not try it yourself?

, , , , , , ,

You might like

3 Responses to LibreSSL ships first portable version, now up to 48% less huge!

  1. VL-S · 446 days ago

    If successful marketing of real estate is location, location, location the catch phrase of successful coding could be reduction, reduction, reduction.

    I inherited a 1-meg embedded system from which I was required to fork and apply to some similar new hardware. At first I attempted to adapt the old just to get something up and running to show the customer. As I went on I discovered routines that were poorly coded or never used,

    Being as anal retentive as I was it was impossible to leave such a mess particularly since my name was going to be associated with the new system.

    Over the course of the project I tossed away some and rewrote most of what remained to produce a product that was one-tenth the size, compiled and loaded faster and was easier to maintain.

    I view coding not as a job but an art form. Could it be that the LibreSSL coders have the same passion?

    • jimcsecurity · 444 days ago

      I agree with VL-S, less code is always a good thing: less maintenance (and easier to maintain when accurately documented and commented), fewer bugs and a smaller attack surface.

      It’s a pity that the PRNG of LibreSSL has been found to be vulnerable but it is only a first release and I think that they are off to a great start (since I am sure the PRNG will be fixed soon). It’s unclear if LibreSSL provides any code to OpenSSL (BoringSSL from Google provides fixed to OpenSSL).

      It will be interesting to see if Google’s Project Zero will benefit LibreSSL. In addition, it be interesting to see how OpenSSL evolves since it now has more developers and announced a Project Roadmap at the end of June as to how they will improve OpenSSL.

      This is great news for everyone since our SSL connections will be safer due to the efforts of LibreSSL and OpenSSL.

      • jimcsecurity · 444 days ago

        I have since learned that the issue with the PRNG mentioned above was actually resolved by LibreSSL late last night (15th July). Thanks.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

About the author

Paul Ducklin is a passionate security proselytiser. (That's like an evangelist, but more so!) He lives and breathes computer security, and would be happy for you to do so, too. Paul won the inaugural AusCERT Director's Award for Individual Excellence in Computer Security in 2009. Follow him on Twitter: @duckblog