No need to panic over damp squib Linux glibc flaw


Earlier this week, Google Staff Security Engineer Fermin J. Serna and Technical Program Manager Kevin Stadmeyer posted details of a Linux glibc (GNU C Library) stack-based buffer overflow vulnerability (CVE-2015-7547). The pair explained how they were able to craft a fully working exploit just to make matters worse.

If you have been reading some of the headlines that have appeared since this disclosure, you might be forgiven for thinking that this is a major security event with devastating consequences.

Here at IT Security Thing we have seen it described as putting “Every Linux Machine in Danger” and being both “catastrophic” and a “Linux Superbug” for example.

For sure this is a flaw that has been around for a while, in every version of glibc since 2.9, which was released way back in 2008. It really does, therefore, have the potential to impact upon thousands of Linux devices, no denying that.

Here’s how Serna and Stadmeyer describe it: “The glibc DNS client side resolver is vulnerable to a stack-based buffer overflow when the getaddrinfo() library function is used. Software using this function may be exploited with attacker-controlled domain names, attacker-controlled DNS servers, or through a man-in-the-middle attack.”

Now the Google research also explains there are some mitigations to help prevent exploitation if an immediate patch, which has already been released, is not possible for your instance of glibc.

What has been released is a non-weaponized proof of concept in two parts; the server code which triggers the vulnerability, and if it’s there it will crash the client code.  

“The vulnerability relies on an oversized (2048+ bytes) UDP or TCP response, which is followed by another response that will overwrite the stack,” Serna and Stadmeyer explain, “our suggested mitigation is to limit the response (i.e., via DNSMasq or similar programs) sizes accepted by the DNS resolver locally as well as to ensure that DNS queries are sent only to DNS servers which limit the response size for UDP responses with the truncation bit set.”

Which all sounds very nasty, despite the mitigation efforts and the availability of a patch. So why would anyone take issue here?

Well, what is open to debate, and there has been plenty of it within the IT security community already, is whether it’s actually that dangerous in the real world at all.

Even Google itself admits that while remote code execution is possible it’s not exactly straightforward. “It requires bypassing the security mitigations present on the system, such as ASLR,” the researchers say, adding, “we will not release our exploit code.”

What has been released is a non-weaponized proof of concept in two parts; the server code which triggers the vulnerability, and if it’s there it will crash the client code.

Whether you would risk running this in a production environment rather depends upon your love of risk I guess, but it’s not something to be recommended. Applying the patches as soon as they become available, would seem to be the most obvious advice.

Craig Young, a security researcher at Tripwire, agrees that the flaw is an interesting one but doesn’t expect to see any widespread exploitation for code execution.

“While many have espoused ASLR (address space layout randomization) as making this vulnerability difficult to exploit, I actually take a different stance,” Craig says, “ASLR is a security feature designed to prevent attackers from knowing in advance where critical blocks of code exist in the memory of a targeted system.”

Of course, this assumes that your system has system wide ASLR enforcement in place, which is statistically unlikely in our books, and seeing as glibc is so widely used it’s not something we would rely upon for defence.

“The bigger barrier to execution,” Craig continues, “is that in most cases the attacker needs to get parallel name resolution (IPv4/IPv6) to an attacker controlled name server either directly or through a recursive lookup.”

So what about a recursive lookup, considering most attackers won’t have control over popular DNS servers? “The problem with this scenario,” Craig insists, “is that payloads needed for exploiting this for code execution are probably not going to be well-formed responses and will likely get dropped en route.”