A New Day, An Old Bug: Linux At Risk from ‘glibc' Vulnerability

The vulnerability was first introduced in the 2008 release of glibc 2.9. According to Google, the bug allows for remote code execution. ZDNet and other outlets have reported that this open-source bug affects "a large number of Linux distributions, software and devices," because Linux applications rely on this library.

Google and Red Hat have released a patch for the vulnerability, which can be found here.

Google says that software using the getaddrinfo() library function are at risk.

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.

The ZDNet article quotes Johannes Ullrich, CTO of the SANS Internet Story Center, as saying that this issue affects most Linux users: "Pretty much any Linux system uses glibc, and getaddrinfo is typically used to resolve IP addresses. Which means Linux servers as well as workstations, are vulnerable unless it runs an old version of glibc (pre 2.9)."

Patch & A Prayer

The April 2015 issue of Waters was dedicated to cybersecurity issues. One topic examined was the challenges of patching systems and servers.

For the article, the CIO of an asset management firm with approximately $150 billion under management, took Waters through the organization's patching routine.

The firm goes through, usually, five to eight updates per month for desktops, and those go "reasonably well," according to the executive. It's on the server side that the greatest challenges lie. As an example, the CIO says that most asset managers have, on average, more than 1,000 Windows-based servers in their data centers. Every month they receive 10-15 patches that cover relevant vulnerabilities, specific to the firm.

From the feature:

"The problem is that any one of those patches could break your application," he says. "You have a trading system, it's got a Windows server in your datacenter, and when you apply a patch for that vulnerability, it could potentially break your system. So you absolutely must test them on the server side, first. It's very challenging because there are so many of them."

That's 10 to 15 patches applied to 1,000-plus servers: 15,000-plus separate repetitions that need to be tested and monitored. The IT team applies the patches to its development and test servers once a month. There, they are tested to make sure that all the interconnected pieces in the system aren't affected.

"You'll always be a little bit behind," the CIO says. "Arguably, the day it comes out you should probably apply it, but there's a lag between testing and deployment. The good news is that your datacenter tends to be internal and walled off from the rest of the world; it's less exposed. You probably couldn't do that with a web-based application."

And all of that is just on the server side, before you get the network firewall and vendor connections.

"The struggle that we always have is the attention between the development staff and the patching activity," the CIO said. "Developers want to be left alone, they don't want any problems, and this is something that potentially interferes with what they're doing. There's a certain amount of pressure to either do it less often, to not do it at all, or delay it."