On Tuesday, February 16th, Google researchers issued a vulnerability disclosure for glibc (CVE-2015-7547). Though the media has dubbed this an “extremely severe bug,” it seems the majority of news articles and responses to this disclosure have been both measured and appropriate.
This is surprising since the media typically hypes branded vulnerabilities, compelling companies to react quickly and without strategy, rather than to respond. But, these reactions can be time-consuming and costly. Despite the fact that the vulnerability may be achieving mainstream awareness, enterprises need to balance responses against risk.
So, what is the glibc vulnerability, and how should you respond?
What is the vulnerability?
According to an article by Ars Technica, glibc is found in an open source component that powers thousands of stand-alone applications as well as distributions of Linux. The function known as “getaddrinfo() performs domain-name lookups and contains a buffer overflow bug that can allow attackers to remotely execute malicious code.
How severe is it?
Though the potential impact of malicious code exploiting the glibc (CVE-2015-7547) vulnerability is great, such an exploit is not straightforward or trivial to produce. Cybercriminals would have to customize their exploits for each version of the library as well as for each operating system. At this point, no known exploit exists in the wild. While it is possible one will become available in the future, the risk is low.
What should you do?
Because the potential impact is high, but the likelihood of a mass exploit is low, Veracode recommends patching during your next patch cycle.
Why does this matter?
The glibc vulnerability once again demonstrates the risk of component libraries and the need to have visibility into component usage.
I’m not implying that companies should cease the use of open source components. The use of components is commonplace, and even a best practice. Software is no longer developed but constructed from a combination of internally developed code and open source components and libraries. This practice allows development teams to innovate faster, by taking advantage of functional code that has already been created. But, this advantage comes with a dark side – in some cases, a widely used component can have a vulnerability. Once this is discovered, the component becomes a logical attack point for cybercriminals, as creating a single exploit has the potential to breach multiple companies.
Like Heartbleed and Shellshock before it, the glibc vulnerability reinforces the fact that the use of components in the application development lifecycle introduces risk. This will not be the last open source component vulnerability we see, and the next one may be more severe in terms of mass exploitability.
As a result, it is crucial for organizations to have complete visibility into all of the components their development teams are using, as well as the versions being used. Only then can security teams ensure they can quickly patch and/or update the component version when a new vulnerability is disclosed. Otherwise, they run the risk of leaving a known vulnerability in their environment and creating a situation like what happened with one healthcare organization when Heartbleed was disclosed. Although the organization was aware of the OpenSSL vulnerability, it was not able to find and update all versions of the component before hackers were able to breach it through the Heartbleed vulnerability.
By proactively creating a comprehensive inventory of the components and the current versions in your environment, you will be able to quickly respond to the next vulnerability disclosure in an open source component. Otherwise, you are left trying to work faster than the criminals, and man, are they motivated.
To learn more about this vulnerability, attend the SANS webinar “GHOST 2.0: What do you need to know about the glibc getaddrinfo vulnerability.” Register here: https://www.sans.org/webcasts/ghost-20-about-glibc-getaddrinfo-vulnerability-101875