Call us at 507.319.5206 or This email address is being protected from spambots. You need JavaScript enabled to view it.
Follow us on LinkedIn and Twitter

Beyond Heartbleed: Why OpenSSL is Still “The Most Dangerous Code in the World”

Remember the Heartbleed bug of a few years ago? Once you fixed it, you thought you were in great shape, right? Well guess again.

Heartbleed was just a symptom of much deeper issues with OpenSSL. Perhaps the most dangerous are serious flaws in the API set design and implementation that can, among other things, actually return false positives when validating certificates!

A recent project reminded me that far too many organizations who depend on OpenSSL are still not doing what they need to do to protect themselves.

So, what can you do?

How to Protect Against OpenSSL Vulnerabilities

  1. If you work in an IT shop and use products built on top of OpenSSL, the most important thing you can do is keep track of the CERT advisories for OpenSSL. Find out which version of OpenSSL your provider used to build their product and pressure them to provide timely updates that include patches for critical (at least!) OpenSSL bugs.
  2. If you have in-house code built on top of OpenSSL, you also need to keep track of the CERT advisories for OpenSSL and include new patches as soon as possible. In addition to CERT, OpenSSL vulnerabilities can be found on the OpenSSL site here.
  3. If you are considering a development project built on top of OpenSSL, take a look at LibreSSL instead. It may have what you need, and it won’t give you a false sense of security.

The Technical Issues with OpenSSL

An early exposé on OpenSSL was a paper called The Most Dangerous Code in the World. It was originally published in the Proceedings of the 2012 ACM conference on computer and communications security, even before the Heartbleed bug was discovered.

This LibreSSL presentation by Bob Beck to the Calgary UNIX User’s Group on May 29, 2014 is especially instructive about the problems in OpenSSL that go beyond the Heartbleed bug. It’s long, but it will make your jaw drop.

Among the problems Bob discusses — and this is where you may be affected — are a poorly designed and implemented API set. Due to the poor design, it is difficult to use those APIs correctly. Sure, you can get code to work, but it may not behave the way you expect.

For example, verifying a peer certificate may actually perform the verification, but it can return a successful result whether or not the certificate was valid (depending on whether you pass a ‘1’ or ‘TRUE’ for one of the options). So even if you are using products written on top of OpenSSL, your comfort level is probably much higher than it should be.

There are other problems with OpenSSL.

  • It was implemented to work in just about every environment that ever was. Among other things, this means it provides its own memory management rather than providing on operating system provide memory – a source of many OpenSSL CERT advisories.
  • There are numerous conditional compilation statements that make reading the largely undocumented code nearly impossible.
  • Even if they do conduct routine and rigorous code reviews (which the history of bugs and patches seems to indicate doesn’t happen), they would be difficult to do because of the lack of documentation and the overly complex nature of the code.

I recently downloaded OpenSSL version 1.0.2f (released March 1, 2016) and ran a well-known open source static code analyzer, CPPCHECK, on it.  I was stunned with the issues it found.

From a complexity point of view, there are at least 51 different ways to build OpenSSL depending on which conditional compilation options you choose. It found three occurrences of an array index being used before checking if the index was within the bounds of the array. There were four cases of dead (unreachable) code. The analyzer found 55 occurrences of mismatches between the format string and the data passed, or the number of format strings and the number of variables passed. Format strings in print statements can be used by attackers to induce buffer overflows and to access otherwise unreachable memory.  It found four occurrences of variables being used before they were initialized; seven occurrences of conditional expressions that will always be false due to the ‘else if’ condition matching a previous condition. Five occurrences of unsigned variables being checked for values less than zero. And so on.

Many of the items flagged by the code analyzer may not be security issues; however, I expected an open source project as widely used in such important functions as OpenSSL would have fared much better than it did. For example, code that is properly reviewed should not include unreachable code.

Manually reviewing the code – at least for the 8-10 parts I looked at – was a nightmare. I couldn’t tell if it was “bad” code, but the parts I looked at were so poorly written that it was extremely difficult to follow the logic or to even understand what it might be doing. Little or no internal documentation and no external documentation on the architecture and design – at least that I could find — makes it even more difficult for anyone to review the code.

The Bottom Line

If you’re using OpenSSL or have a third-party product that was built over OpenSSL, you absolutely need to remain diligent about tracking CERT advisories and making sure the proper patches are applied.

If you are considering a development project built on top of OpenSSL, take a serious look at LibreSSL. It may have what you need and it won’t give you a false sense of security.


This entry was posted in IBM i Security and tagged , , . Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *


You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>