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
Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
Register for Dark Reading Newsletters
Dark Reading Live EVENTS
INsecurity - For the Defenders of Enterprise Security
A Dark Reading Conference
While red team conferences focus primarily on new vulnerabilities and security researchers, INsecurity puts security execution, protection, and operations center stage. The primary speakers will be CISOs and leaders in security defense; the blue team will be the focus.
White Papers
Video
Cartoon Contest
Write a Caption, Win a Starbucks Card! Click Here
Latest Comment: No, you were supposed to display UNICODE characters!
Current Issue
Security Vulnerabilities: The Next Wave
Just when you thought it was safe, researchers have unveiled a new round of IT security flaws. Is your enterprise ready?
Flash Poll
[Strategic Security Report] Assessing Cybersecurity Risk
[Strategic Security Report] Assessing Cybersecurity Risk
As cyber attackers become more sophisticated and enterprise defenses become more complex, many enterprises are faced with a complicated question: what is the risk of an IT security breach? This report delivers insight on how today's enterprises evaluate the risks they face. This report also offers a look at security professionals' concerns about a wide variety of threats, including cloud security, mobile security, and the Internet of Things.
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2017-0290
Published: 2017-05-09
NScript in mpengine in Microsoft Malware Protection Engine with Engine Version before 1.1.13704.0, as used in Windows Defender and other products, allows remote attackers to execute arbitrary code or cause a denial of service (type confusion and application crash) via crafted JavaScript code within ...

CVE-2016-10369
Published: 2017-05-08
unixsocket.c in lxterminal through 0.3.0 insecurely uses /tmp for a socket file, allowing a local user to cause a denial of service (preventing terminal launch), or possibly have other impact (bypassing terminal access control).

CVE-2016-8202
Published: 2017-05-08
A privilege escalation vulnerability in Brocade Fibre Channel SAN products running Brocade Fabric OS (FOS) releases earlier than v7.4.1d and v8.0.1b could allow an authenticated attacker to elevate the privileges of user accounts accessing the system via command line interface. With affected version...

CVE-2016-8209
Published: 2017-05-08
Improper checks for unusual or exceptional conditions in Brocade NetIron 05.8.00 and later releases up to and including 06.1.00, when the Management Module is continuously scanned on port 22, may allow attackers to cause a denial of service (crash and reload) of the management module.

CVE-2017-0890
Published: 2017-05-08
Nextcloud Server before 11.0.3 is vulnerable to an inadequate escaping leading to a XSS vulnerability in the search module. To be exploitable a user has to write or paste malicious content into the search dialogue.