Hundreds of thousands of devices, apps and services could be at risk from a major computer security bug, with many experts likening the vulnerability to 2014’s Shellshock.
Engineers at Google discovered the vulnerability, acknowledging the find on the company’s Online Security Blog yesterday, February 16 2016.
The blog revealed that a flaw in some commonly-used code – glibc – could be exploited to allow remote access to a range of devices, such as computers, routers and other connected devices.
Glibc is an open-source library of code which is widely used in internet-connected devices. The main concern surrounding the discovery of this bug is in how it works with DNS, or domain name systems.
With a domain look-up, a device converts a domain and finds its IP address so that the device can access the website or service. The newly discovered vulnerability is found in the domain look-up code in glibc, which could potentially allow hackers to input malicious code in the memory’s device in order to control the device over the internet.
As Mark Loveless, Senior Security Researcher at Duo Security explained to CBR, the fact that this flaw impacts DNS means that many applications, specifically Linux, could potentially be at risk from hacking.
"The main impact as it stands right now appears to be when a Linux system makes a query to a DNS server, and gets back a large response. The part that makes this interesting is that DNS is a core infrastructure component, which means that a lot of subsystems and applications could potentially be impacted.
"The main things listed initially were ssh, curl, wget, and similar command-line Linux utilities, but it is possible that other processes could also use the library calls in the exact way needed for exploit.
"In theory, there could be other non-Windows systems that use glibc that could be impacted – including other Unix-based operating systems, or even operating systems for mobile devices or tablets."
Google has managed to exploit this flaw through, as they say on their security blog, ‘intense hacking sessions’ – but are remaining responsible and not releasing the exploit to the public. It was found, however, that the team which maintain the glibc library knew about the bug from July 2015, though they chose to flag it as a low priority.
Google engineers have worked alongside Florian Weimer and Carlos O’Donell of Red Hat to issue a patch, with this teamwork and quick patch release welcomed by experts, with Paul Farringdon, Senior Solution Architect at Veracode, saying:
"It is great to see that Google and Red Hat have worked together – and so quickly – to provide a patch for this vulnerability. Now it is essential that this patch is pushed out extensively to ensure that all consumer devices are adequately protected from the flaw.
"All mobile phone operators currently running Android must take immediate action to push it out across all their handsets, and also to work to communicate the seriousness of this flaw to all their customers to ensure that they download the necessary updates."
Manufacturers are now being urged to test their systems using the proof-of-concept attack developed by Google, with Veracode’s Paul Farringdon warning companies that a quick response time to these kinds of vulnerabilities is crucial, alongside scanning for unknown vulnerabilities.
"This type of finding underlines the need for organisations to be able to pinpoint known vulnerable components in their software as soon as the new exploit hits the news wires. Realistically organisations don’t necessarily have time or budget to reactively scan hundreds of applications for a single high severity issue. Understanding the composition of the software, and the use of third-party components ahead of announcements like this is absolutely crucial.
"This requires organisations to recognise there will be no end to these types of discoveries in the future. Put another way, don’t just scan for vulnerabilities that have already been announced, but itemise everything that goes into each application so that as soon as a bad building block is identified, this can be easily replaced."
This article is from the CBROnline archive: some formatting and images may not be present.