Old computing code puts millions at risk as glibc vulnerability exposed

Anyone running glibc 2.9 or above should upgrade to a later version or apply a vendor patch now as malware authors will be looking at this bug closely given its remote code execution capabilities says Carl Leonard.

Carl Leonard, principal security analyst at Forcepoint
Carl Leonard, principal security analyst at Forcepoint

The security threat landscape has expanded dramatically over the last couple of years, with a string of high-profile vulnerabilities potentially leaving consumers and businesses exposed to cyber-criminals. Possibly the most notorious of these revelations was Heartbleed which, it was revealed in April 2014, was seeing decades-old code leaving computers and devices worldwide vulnerable to attack. The threat landscape then grew into the network infrastructure as cyber-criminals found routes to exploit hidden vulnerabilities buried deep within the code base of aging protocols like Bash, Open SSL and SSL v3.

The high-profile nature of these weaknesses in software and computing infrastructure has raised public awareness of the rapidly evolving tactics and techniques of cyber-criminals with media-friendly monikers like Shellshock and Poodle.

Unfortunately, it's not enough to simply be aware of a current threat. Businesses must be vigilant against potential security weaknesses by ensuring their software  is fully up to date or it could leave users and businesses vulnerable to attack – glibc.

The glibc vulnerability

‘glibc,' or GNU C Library to give it its full title, is a collection of open source code that is a core component of GNU systems and the Linux kernel. A bug within glibc was introduced nearly eight years ago in glibc 2.9 but was first reported last July, suggesting an issue in the code behaviour.

Researchers at Google and RedHat have investigated the report and discovered a possibility that it could lead to Remote Code Execution, whereby an attacker can gain access to a user's device and make changes regardless of where the device is geographically.

The risk

While the attack does not target DNS servers directly, it does focus on a vulnerability in glibc that is used extensively – including DNS servers such as BIND. This means an attacker could host a website that triggers the vulnerability if the DNS server is asked to resolve to that hostname.

This means an attacker could host a malicious domain that, when resolved by the DNS server, could trigger a segmentation fault that would crash the DNS Server. It therefore seems likely that malware authors will be looking at this bug closely with a view to building a fully functioning Proof of Concept.

The last time a Remote Code Execution in glibc became public knowledge was back in July 2015, in the form of the GHOST vulnerability which affected glibc version 2.18 and earlier. In this situation the RCE is possible, but much harder to execute.

Prepare to patch

Anyone running glibc 2.9 or above should upgrade to a later version or apply a vendor patch. The latest version of glibc, released in August 2015, is glibc 2.22, but that is highly likely to change soon. A check can be carried out by running a simple command on the operating system. For example, on any Ubuntu system typing <sudo apt show libc6> will print the details about glibc on the system.

Vendors are building and releasing their own patches and it is vital end-users and businesses apply these as soon as they become available. A patch has been made available by the glibc project at https://sourceware.org/ml/libc-alpha/2016-02/msg00416.html. This provides multiple mitigations, including ones that do not fully work but are worth knowing about.

Researchers at Google have released a Proof of Concept script that enables anyone to check if their systems are vulnerable or if any mitigations were successful, available here.

A new Heartbleed?

Glibc has all the tell-tale signs of being a potentially serious threat. When information like this comes into the public domain, malware authors will seek to capitalise on any infrastructure weaknesses. 

Remote code execution capabilities are a malware author's dream scenario – as they can operate at will on the compromised machine and network environment. It is therefore crucial for affected businesses to apply any vendor patches or consider mitigation. Now is the time to review this issue in light of their risk assessment process, as malware authors will strike while the iron is hot.

The expertise and sophistication of cyber-criminals is ever on the increase, so businesses have to keep pace and ensure they make it as difficult as possible for hackers to access their systems.

Contributed by Carl Leonard, principal security analyst at Forcepoint

Sign up to our newsletters