Checkmarx Named a Leader in Gartner Magic Quadrant for Application Security Testing

OpenSSL Vulnerabilities: Takeaways from the Latest Patch

The OpenSSL project this week released a series of patches to combat six vulnerabilities that have been discovered as of late, including two high-severity flaws that would give attackers the ability to decrypt HTTPS traffic, execute malicious code on vulnerable servers, and possibly even cause servers to crash. Ironically, one of the flaws was actually inadvertently implemented as part of the fix for the Lucky 13 flaw that was discovered in 2013.


While not stirring up the same panic as the Heartbleed bug or the more recent DROWN attack, any vulnerability in OpenSSL should cause a bit of a ruckus, if only for the fact that two-thirds of the internet employs the library. So if you’re using OpenSSL and you haven’t patched up yet, it’s time. Stop reading, download the updates – and then come back to read why you need to.


Here’s What You Need to Know About the Latest OpenSSL Vulnerabilities:

  • CVE-2016-2107 is the first high-severity vulnerability, that would allow Man-in-the-Middle attacks, enabling decryption of passwords and other sensitive data using certain ciphers. This was the flaw that was introduced during the patch of the Lucky 13 flaw mentioned earlier.


  • CVE-2016-2108 is the second high-severity vulnerability patched in OpenSSL. This flaw is actually a combination of two low-severity bugs with no security impact – but together could enable an exploitable memory corruption vulnerability, crashing OpenSSL and possibly allowing malicious code to be executed.


  • The other four vulnerabilities are low severity bugs. Two of them, CVE-2016-2105 and CVE-2016-2106, could allow heap corruption and enable malicious code to be executed, though chances are very small for success. CVE-2016-2109, a flew in the ASN.1 BIO, would allow an attacker to allocate large amounts of memory to potentially exhaust the memory and crash the system. Finally, CVE-2016-2176 could allow an attacker to collect data in EBCDIC systems – but nothing sensitive or useful.


Read the full security advisory here.


What Is OpenSSL and What Is It Used For?

If you’re not familiar with OpenSSL and you design, build or secure applications, it’s time to learn. Chances are, OpenSSL is implemented is one or more of your apps. OpenSSL is an open-source cryptographic library that implements the SSL/TLS protocols. The library is used to secure communications over email, web apps, VPN, and online as well as mobile communication and messaging applications.


Per the project’s wiki, OpenSSL is a tool that provides a library, called libssl, supporting SSL (Secure Sockets Layer) and TLS (Transport Layer Security) protocols for client and server applications, a comprehensive cryptographic library, libcrypto, and a command line app that enables both testing of the SSL/TLS protocols as well as the creation and handling of certificates.


In short, OpenSSL enables millions of applications – and hundreds of millions, if not billions of people – to communicate securely. It’s widely popular, yet underfunded and low on consistent manpower. Call it the curse of open source projects. Here are some takeaways from this latest round of patches, and the more high-level takeaways on how we can improve on open source.


A Few Takeaways from OpenSSL & Open Source Components in Your Apps:

  • Careful oversight is required when it comes to open source projects

Open source has exploded in recent years due to several factors, including the higher speed of development and pressure to deploy apps faster, the higher quality of open source projects maintained by large communities, the independence from proprietary vendors, and perhaps the biggest reason: the savings gained by using already-built and well-maintained components.


Forrester analyst Jeffrey Hammond explained it well in Computerworld: “Companies get the ‘Lego blocks’ for free, so they can spend their time and resources building what they want in particular.”


When developers can use open source libraries for more standard parts of an app and use their manpower building the more intricate or customized areas, the organization wins by saving time and money, and the developers win by being empowered to build more critical areas of the app.


Yet, with open source, there is a caveat – there is really no such thing as a free lunch. This has a few implications, and we’ll discuss the need for both financial and development support for open source projects like OpenSSL. But for this point, it relates to the fact that open source comes with strings attached – security flaws open to the public for scrutiny…an attack. And the strings can be pulled by malicious attackers if your open source components are not properly secured.


It may not even be a flaw in the open source library itself; there may be security issues with the way a component interacts with your in-house code, or with how the component was implemented.


That’s why security testing is essential with open source, just like with your in-house code. With a Secure SDLC in place, both threat modeling and security testing, especially source code analysis, can be deployed to ensure that all your code is secure and that the possible threats to your app are documented well before the app is deployed for general use.  


  • Monitoring and managing open source components needs to be a critical component of any application security program

WhiteSource Open Source Research
Courtesy: WhiteSource – click for full version

We’re still only two years past the Heartbleed fiasco, dubbed by ZDNet as ‘Open Source’s Worst Hour’, and while OpenSSL vulnerabilities went through a good cleaning post-Heartbleed, the importance of continuous monitoring of the open source components used in your apps can’t be overstated.


A WhiteSource study on organizations using open source projects found that in 2014, of 645 thousand projects researched, 33.8% were using open source components with security vulnerabilities – even though a full 95.7% of the vulnerable libraries used has newer versions that had mitigated the vulnerabilities.


The security of open source components – like any other piece of code – can’t be taken for granted; we need to learn from history. With organizations now relying on at least one open source component, managing the components you used should be done right alongside your in-house code.


<<Want help managing and securing your open source components? Check out Checkmarx Open Source Analysis (OSA) here.>>


  • Open source, now more than ever, needs our support

The OpenSSL vulnerabilities announced this week were nothing unexpected. Flaws in the OpenSSL project are regularly announced and new updates are part of the norm. It’s not that OpenSSL is bad or shouldn’t be used; the opposite in fact, is true. OpenSSL has made encrypted communication a standard component of applications – an absolutely positive outcome.


Yet OpenSSL, like any open source project, is not a fortress. It has holes. It’s not perfect. There’s still work to be done in making it as secure as possible. And if your app is one of the hundreds of millions of applications using OpenSSL, you can help make it better, either by donating your time by reporting vulnerabilities your organization discovers or working in the community, or money – or getting your organization to do so.


Open source projects like OpenSSL are only as strong as the team of paid and voluntary developers working on it. If OpenSSL or another project has been fundamental in your apps, consider giving back. The more help from the community, the faster issues can be fixed – and the more secure projects that are part of the internet’s backbone can be.



Jump to Category