pixel_dreams - Fotolia
Security experts are advising companies to patch immediately to eliminate the risk of remote code execution through exploits of the newly-discovered glibc vulnerability.
Although the Google engineers who discovered the vulnerability say exploiting it is difficult, they have also proved it could be done, and security experts say it is best not to take the risk.
According to Google engineers, the domain look-up code in glibc contains a bug that could allow hackers to implant code within a device’s memory to enable remote code execution attacks.
Similarly, because the use of the glibc open-source standard C library is widely used in Unix-based systems, including Linux servers, hundreds of thousands of devices, applications and services could be at risk if attackers find a way to exploit this newly-discovered flaw.
The glibc flaw could also enable a hacker to compromise apps and gain control of systems that access a hacker-controlled domain name system (DNS) used to translate domain names to actual machine IP addresses, either directly or through a man-in-the-middle attack, according to Patrick Carey of Black Duck, which helps organisations to secure and manage open-source software.
Now that the bug has been reported publicly, Carey said the race is on between development teams and those who would try to exploit the vulnerability.
“As soon as your operating system distro has a patch, get it,” said Paul Ducklin, senior technologist at Sophos.
Red Hat is reportedly one of the first Linux distributions to release a patch for the flaw in glibc 2.9 and later in collaboration with Google. Other Linux distros are expected to follow.
Because many versions of Linux use glibc as a core component of the operating system for programs to reference, a bug in glibc therefore affects almost every program on your system, he said.
“But the good news is that by patching the central copy, you magically ‘fix’ every application that depends upon it.”
Carey said development teams also need to determine which of their applications are at risk, which is a difficult task given how deeply glibc integrates into applications.
“Then they must patch those applications and make the updates available to their users, which can be a lengthy process, especially for applications that are installed on users’ desktop or mobile devices, leaving them exposed for some time,” he said.
Fortunately, said Ducklin, a lot of internet of things (IoT) devices do not use glibc because it is rather large and instead use more compact implementations of this core library, such as Google’s bionic, used by Android, which is not affected by this bug.
However, he said finding out whether your IoT devices are affected is not easy because it is difficult to access the inner workings of the devices. This means IoT device owners are reliant on suppliers to find out if they are vulnerable to the glibc bug.
David Flower, managing director for Europe at security firm Carbon Black, said Linux users have long believed that their systems are secure by design and are invulnerable to attack.
“However, the string of high-profile Linux malware – from last year’s Mumblehard, which had gone undetected for five years, to 2012’s Snakso, which gave hackers remote access to servers – has proven this belief to be false, and Google’s discovery of glibc has delivered another significant blow to this misconception, highlighting that a basic flaw has been present within the code itself,” he said.
Patch as soon as possible
Flower said while there are no known exploits of the flaw by attackers, organisations are advised to patch as soon as possible now that the flaw has been reported publicly.
“The problem is that weaknesses such as glibc enable hackers to sidestep basic security measures such as anti-virus software and more sophisticated network security solutions,” he said, adding that this is the reason advanced endpoint security has become so important.
“Businesses need the ability to monitor all activity taking place on user devices so they can detect, prevent and respond to any malicious behaviour that indicates a hacker has gained remote access to their systems, and shut them out before they can do any harm,” he said.
Thomas Fischer, principal threat researcher at Digital Guardian, said the public disclosure of the flaw raises a number of issues with managing security vulnerabilities, such as the use of common application program interfaces (APIs) and the speed at which suppliers can implement fixes to open-source products.
Impact more on routers
He believes the impact of this bug is likely to be felt more on routers than servers and endpoints, because these typically contain more robust memory protection and separation techniques to control what a CPU executes.
“However, protections of this nature are not implemented in integrated devices like routers due to their expensive nature, both in costs and hardware requirements. As a result, it is much easier to create the buffer overflow needed to insert malicious code to open a backdoor or disable the device altogether,” he said.
For this reason, Fischer also recommends that in the short term, organisations should apply patches as soon as they are available.
Longer term, the focus should be on implementing processes that will allow all future patches to be installed in a timely, secure and efficient manner, he said.
As well as patching, Fischer said there are several mitigations that can be used, such as pointing your devices to an internal DNS server and limiting the TCP response sizes, avoiding the use of AAAA queries, and limiting the use of protocols such as EDNS0 and DNSSEC.