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.
What 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.
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?