glibc Vulnerability CVE-2015-7547: Why You Were Blindsided

Why You Were Blindsided by glibc Vulnerability CVE-2015-7547

And how you can protect yourself better next time.

Here we go again. Google’s recent security blog post detailing their discovery of the glibc vulnerability (CVE-2015-7547) has kicked-up quite a stir. Security experts are advising development and IT teams to take the risk seriously and patch their applications and Linux operating systems as quickly as possible. We agree, but as teams scramble to find and patch all instances of the glibc vulnerability in their applications, we think it is also important for teams to take a step back and see what lessons can be learned, so that they can minimize their risk going forward.

Here are the key takeaways we see.

No open source code is too old or widely used to be vulnerable

I won’t dig into the technical details here. Good technical descriptions of the glibc vulnerability and exploit risks are documented in the Google and sourceware.org posts. Essentially, this particular bug would enable a hacker to compromise apps and potentially gain control of systems that access a hacker-controlled DNS (Domain Name Services – servers that are accessed to translate domain names to actual machine IP addresses) host, either directly or through a man-in-the-middle attack.

Programming Language Use in Open Source Project During Last 12 monthsWhat makes this glibc vulnerability so insidious is the fact that it exists in glib, the standard implementation library for the C and C++ programming languages, and one of the oldest open source libraries in existence; dating back to the early 1990s. Glibc is pervasive. C is the primary language used to build the Linux operating system, and according to our data, C and C++ continue to be two of the primary languages used within other open source projects.

If ever there was an open source project that could be considered mature and stable, with a million eyes on it, it would certainly be glibc. However, you cannot simply focus your application security efforts on only the newest code, assuming that libraries like glibc aren’t at risk. Clearly they are.

Lesson #1, you need to keep an eye on ALL the code, old and new, going into your applications.

Vulnerabilities continue to go undetected by most testing tools

It’s also worth noting that although the glibc vulnerability (CVE-2015-7547) gained visibility this week, the glibc bug dates back to version 2.9, which was released November 2008. Here’s a quick test. Raise your hand if your static or dynamic application security testing tool found this bug.

Hmmm…  I’m not seeing any hands.

Why not? This code has no doubt been tested thousands of times since 2008. Like so many open source vulnerabilities, this one wasn’t found by tools, it was found by researchers. Sometimes they are deliberately trying to find vulnerabilities. Sometimes they stumble on them while testing something completely unrelated, which is what happened this time at Google. This has also been true of most of the other known open source vulnerabilities including the big ones like Heartbleed, GHOST, and Shellshock.

Lesson #2, don’t assume your testing tools will find vulnerabilities deep in the open source you use.

NVD doesn’t always give you the first warning

The National Vulnerability Database (NVD) is, in theory, the de facto catalog of all known vulnerabilities affecting commercial and open source software. Given that this vulnerability has a Common Vulnerabilities and Exposures (CVE) number dating back to September of 2015 assigned to it, you might assume that it is already documented in the NVD. But as of today, no such record exists. If you are only monitoring the NVD for newly reported vulnerabilities, you would still have no “official” alert of this issue.

This is one reason why we leverage multiple vulnerability databases, including VulnDB, in Black Duck Hub. While this issue is still under the radar in NVD, Hub customers using VulnDB did get proactive alerts and analysis as shown below.

Proactive alerts from the Black Duck Hub for the glibc vulnerability

This is not the first time. Our analysis has shown that on average VulnDB provides our customers with alerts three weeks earlier than NVD as well as information on many vulnerabilities not reported in NVD.

Lesson #3, don’t rely on a single source for your vulnerability alerts.

It’s a race between you and would-be hackers

If you aren’t already, you should get busy patching glibc vulnerabilities in your apps and Linux installations. Now that the vulnerability is exposed, you can be sure hackers are busy trying to find a way to exploit it. The good news is that fixes are already available from the major Linux distributions like Red Hat and Ubuntu, as well as for the GNU C library itself. You have your work cut out for you though, and it may be a lengthy process, especially for applications that are installed on users’ desktop or mobile devices.

So while you are doing that patching, you should give some thought to these lessons and how you can get ahead of the game for the next inevitable open source vulnerability report. We think that Black Duck Hub, with its automated scanning, mapping to multiple vulnerability databases, and continuous vulnerability monitoring and alerting, can help you do that. Why not give it a try?

Find out what's hidden in your code - try Security Checker today.

0 Comments
Sorry we missed you! We close comments for older posts, but we still want to hear from you. Tweet @black_duck_sw to continue the discussion.
0 Comments

MORE BY THIS AUTHOR

Introducing Black Duck CoPilot

| Jun 13, 2017

Today we’re happy to announce the release of Black Duck CoPilot (https://copilot.blackducksoftware.com/), a new cloud service that helps open source project teams catalog and report on their project’s dependencies and vulnerabilities. What is CoPilot and What Does It Do? Black Duck CoPilot is a

| MORE >

Is Software Composition Analysis Compatible with Agile DevOps?

| Mar 13, 2017

You can integrate SCA with your DevOps environment if you choose your tools wisely. Last month Forrester Research published their first-ever Wave for Software Composition Analysis (SCA). Wave’s provide enterprise IT and development teams with Forrester’s assessment of the state of the vendor

| MORE >

Black Duck Hub 3.5: Improved BOM Management & More

| Feb 7, 2017

New Hub Features Make BOM Management and Code Locations Easier This past week we released version 3.5 of Black Duck Hub. This release focuses on some subtle but useful user experience enhancements that make it easier for teams to manage larger bills of material (BOMs) and scanned code locations.

| MORE >