Patch Now: The Glibc Vulnerability is Worse Than Previously Thought
Patch the Glibc vulnerability. NOW!
Last week, security experts at Google and Red Hat have separately found a flaw in the glibc library, which is used in pretty much all Linux systems. The vulnerability CVE-2015-7547 resides in the getaddrinfo() function and can be used to gain remote code execution, said Wolfgang Kandek, chief technology officer at Qualys said on his blog.
When the vulnerability was announced, it seemed the ability to exploit the flaw required control the DNS server, which typically requires someone with high-level system access, according to Kandek in a phone interview. The threat was thought to be credible, but minimal.
But research being done since by Kaminsky, the security teams at Google and Red Hat, and others is showing that the bug can be exploited without controlling the DNS server, which makes the vulnerability much, much more dangerous.
Dan Kaminsky, a noted internet security expert, calls this flaw “unusually bad” and “a skeleton key of unknown strength.”
In layman’s terms, vulnerability CVE-2015-7547 describes a bug in the code underlying the protocol that connects domain names to IP addresses. So when you type google.com, you expect to go to google. The glibc package contains standard libraries which are used by multiple programs on the system.
“Essentially, through this flaw, attackers could remotely crash or even force the execution of malicious code on machines without the knowledge of the end user,” according to Red Hat’s security blog written by Gunnar Hellekson, Red Hat director of product management and Josh Bressers, Red Hat senior product manager for security. Red Hat rated the potential impact as Critical impact.
What’s a good system administrator to do?
The short recommendation said Kandek, is to “Patch the glibc library in use as soon as possible. This is critical and will only get worse in the next couple of weeks.”
He went further and recommend installing fixes provided by your Linux provider instead of patches or work-arounds that are available on the internet that might be easier to install (and not require a re-boot of the system). Those will not fix the underlying issue.
Red Hat has already provided a list of affected products and fixes for each. This is good news if you are a Red Hat customer. If you are not a Red Hat customer, then Kandek suggests you contact your Linux vendor ASAP. Detailed technical analysis and ongoing updates provided by glib maintainers available here.
Just How Serious is this Problem?
In this vulnerability, “a malicious DNS server provides an overlong, specially formatted answer to a normal address query, which overflows a statically allocated internal 2K buffer with data,” Kandek explained further. “The data is then executed within the getaddrinfo() function.”
Many Linux programs and utilities include glibc’s getaddrinfo() function to resolve DNS names.
“A back of the envelope analysis shows that it should be possible to write correctly formed DNS responses with attacker controlled payloads that will penetrate a DNS cache hierarchy and, therefore, allow attackers to exploit machines behind such caches,” Red Hat said in an advisory.
“It’s likely that all Linux servers and web frameworks such as Rails, PHP and Python are affected, as well as Android apps running glibc.”
Calling this vulnerability “easily the most difficult to scope bug I’ve ever worked on, despite it being in a domain I am intimately familiar with,” Kaminski delves into the history and structure of DNS, and discusses his experiments with the bug. “That’s JavaScript, Python, Java, and even Haskell blowing right up. Just because they’re “memory-safe” doesn’t mean their runtime libraries are, and glibc is the big one under Linux they all depend on.”
Red hat’s Hellekson and Bressers exposed the extent of the vulnerability in their FAQs:
- Does SELinux block this security flaw?
- Can a trusted recursive DNS resolver protect against this issue?
- Is it sufficient to upgrade Internet-facing DNS servers and recursive resolvers?
- TCP mode is not enabled in /etc/resolv.conf. Is the system still affected by this flaw?
- Is it possible to avoid combined A/AAAA DNS lookups?
- Is it possible to mitigate this attack via /etc/nsswitch.conf?
- Can this vulnerability be mitigated by having a system contact trusted DNS servers only?
- Are statically-linked binaries affected by this flaw?”
The short answer to all these questions is no.
Containers being hosted publicly or in the cloud may contain additional problems, according to Hellekson and Bressers. While Linux container vendors are rushing to offer scanning tools to find problems like the vulnerability, “when it comes to actual fixes, they may not have the expertise, capabilities or the ownership to actually fix the problem.”
They recommend contacting your container provider to get more information.
Kendek has additional advice for those applying fixes: “To track your patching progress frequent scans are crucial. Fast moving environments that make use of virtual machines in cloud environments such as Amazon EC2 should look at making use of our Cloud Agent. It provides vulnerability data automatically as soon new machines get booted up and keeps you on top of the changes happening.”
Why was this vulnerability just discovered now? Kendek explained in a phone interview that although the code itself is old and very stable, changes in the usage of IP standards exposed this vulnerability.
This security teams at Google and Red Hat discovered a random memory error when using Linux with certain machines. It turns out the vulnerability in the code is exposed when you do a specific type of concurrent IPv4 lookup and IPv6 lookup. This has been really rare and happens only under certain condition to create the overflow. Though, with the increase in IPV6 adoption, the instances of the vulnerability are increasing.
Go ye forth and patch.
Red Hat is a sponsor of The New Stack.
