Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Vulnerabilities / Threats

3/2/2017
10:30 AM
Jeff Luszcz
Jeff Luszcz
Commentary
Connect Directly
Twitter
LinkedIn
RSS
E-Mail vvv
50%
50%

Three Years after Heartbleed, How Vulnerable Are You?

You may have a problem lurking in your open source components and not know it. Start making a list...

Three years ago, the Heartbleed vulnerability in the OpenSSL cryptographic library sent the software industry and companies around the world into a panic. Software developers didn't know enough about the open source components used in their own products to understand whether their software was vulnerable — and customers using that software didn't know either.

Unfortunately, the majority of today's software companies aren't any less vulnerable today than they were three years ago. To prevent future Heartbleeds, companies must put in place processes and automation to scan, track, and manage the open source components they use in their products. Doing so will let them responsibly understand where the open source components reside within their software products, which of these components are vulnerable, and which customers are exposed. 

Today's Reality
Ten to 20 years ago, a VP of engineering could turn around, look at the bookshelf, and see the product boxes of the libraries the company licensed. Maybe there were a few digital downloads, or some code from a famous book. Slowly at first, then seemingly overnight, the development model changed from mostly homegrown software with a few commercial libraries to projects that are at least 50% open source, all digitally delivered, and not always in well-defined locations in the source tree. To answer the question "Are we affected by this latest vulnerability?" requires a current listing of dependencies or bill of materials (BOM).

Although most companies believe that such a list is being managed, the vast majority of software companies would be hard pressed to produce a list like that, even post-Heartbleed. Research shows that typical software companies can't create such a listing, and if they can, the average percentage of known components is only 4%! What this means is that for every known component, there are 24 other unknown and unmanaged components that are being used and delivered to customers.

A Quick Review
I recommend that you see if you can produce a current BOM and determine when it was last updated. If this list was created only using self-reporting by developers, it's almost certainly only a small percentage of reality. Perform some sampling of the codebase to check if the version numbers reported are still current, and do a quick review of library names; a quick search on copyright strings and licenses; and a review of file extensions that are likely third party (.JAR or .DLL, for instance). Even a quick review will uncover large amounts of previously unknown third-party software.

Doing a search for the string "OpenSSL" can be even more eye-opening. It's pretty much guaranteed you'll find multiple copies of previously unknown instances of OpenSSL in open source components and embedded in commercial components. Both source and binary inclusions will be found.

These self-tests can quickly show that either your BOM is incomplete or out of date. Although this isn't a happy thing to find out, at least you'll have lots of company.

Use Cases
There are a few main use cases where you will find open source components that may be affected by published vulnerabilities. The most common will have been brought in as top-level components, often in clearly named files or directories. The next case to be found will be subcomponents of these top-level components. This type of open source software use is harder to discover and is often overlooked. Versions of these components that have been compiled and linked into other larger packages are almost invisible to the typical developer when trying to create a complete list of dependences. Lastly, codebase owners will want to review the remaining source files to find cut-and-pastes, refactorings, or rearrangements of a larger open source package. This last category can be almost impossible to account for by eyeballing the codebase alone.

Once a current BOM is created, it should be compared against components with known vulnerabilities. Expect multiple vulnerable components to be found, especially on the first review cycle. Some of these may be easily exploitable, while others may not have such a clear path to exploit. It's common to triage these results. Steps to fix this problem include upgrading to the latest version, patching, blocking access, and, in some cases, removing the component and product features affected.

You may find that a vulnerability was introduced because of a subcomponent of a larger component that was delivered via your software supply chain. If you're lucky, you may find that your open source and commercial suppliers have already patched the affected component and it's ready for download. It's also common to find out that they are not aware, or not ready to remediate the issue. 

Defect Logging Process
Familiarizing yourself with the defect logging process for your open source and commercial components is an important part of participating in the vulnerability life cycle.

Once a new version of your product is delivered, the process of keeping a valid current BOM, and checking this list against known vulnerabilities, should continue as long as the product is developed and used. This should be done for all versions used by your user community. Although your development team may have moved to the latest version, you may have significant numbers of users happily using much older versions of your software.

Until the software industry puts into place processes similar to the ones detailed above, it will continue to be unprepared to quickly respond to new Heartbleed-style vulnerabilities.

Related Content:

Jeff Luszcz is the Vice President of Product Management at Flexera Software, the leading provider of next-generation software licensing, compliance, security, and installation solutions for application producers and enterprises. Prior to Flexera, Jeff was the Founder and CTO ... View Full Bio
 

Recommended Reading:

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
COVID-19: Latest Security News & Commentary
Dark Reading Staff 7/6/2020
Russian Cyber Gang 'Cosmic Lynx' Focuses on Email Fraud
Kelly Sheridan, Staff Editor, Dark Reading,  7/7/2020
Why Cybersecurity's Silence Matters to Black Lives
Tiffany Ricks, CEO, HacWare,  7/8/2020
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
Special Report: Computing's New Normal, a Dark Reading Perspective
This special report examines how IT security organizations have adapted to the "new normal" of computing and what the long-term effects will be. Read it and get a unique set of perspectives on issues ranging from new threats & vulnerabilities as a result of remote working to how enterprise security strategy will be affected long term.
Flash Poll
The Threat from the Internetand What Your Organization Can Do About It
The Threat from the Internetand What Your Organization Can Do About It
This report describes some of the latest attacks and threats emanating from the Internet, as well as advice and tips on how your organization can mitigate those threats before they affect your business. Download it today!
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2020-5974
PUBLISHED: 2020-07-08
NVIDIA JetPack SDK, version 4.2 and 4.3, contains a vulnerability in its installation scripts in which permissions are incorrectly set on certain directories, which can lead to escalation of privileges.
CVE-2020-15072
PUBLISHED: 2020-07-08
An issue was discovered in phpList through 3.5.4. An error-based SQL Injection vulnerability exists via the Import Administrators section.
CVE-2020-15073
PUBLISHED: 2020-07-08
An issue was discovered in phpList through 3.5.4. An XSS vulnerability occurs within the Import Administrators section via upload of an edited text document. This also affects the Subscriber Lists section.
CVE-2020-2034
PUBLISHED: 2020-07-08
An OS Command Injection vulnerability in the PAN-OS GlobalProtect portal allows an unauthenticated network based attacker to execute arbitrary OS commands with root privileges. An attacker requires some knowledge of the firewall to exploit this issue. This issue can not be exploited if GlobalProtect...
CVE-2019-19415
PUBLISHED: 2020-07-08
The SIP module of some Huawei products have a denial of service (DoS) vulnerability. A remote attacker could exploit these three vulnerabilities by sending the specially crafted messages to the affected device. Due to the insufficient verification of the packets, successful exploit could allow the a...