As reported by the BBC, a major computer security vulnerability has been discovered – with experts cautiously warning it could potentially affect hundreds of thousands of devices, apps and services. It is now up to manufacturers, and the community behind the Linux operating system, to issue the patch to affected software and devices as soon as possible. Security experts from Lieberman Software, ESET, Veracode, and Duo Security have the following comments on it.
[su_note note_color=”#ffffcc” text_color=”#00000″]Paul Farringdon, Senior Solution Architect, Veracode:
“It is highly concerning that potentially millions of connected consumer devices have been left vulnerable to attack through this glibc bug. Since the birth of the smartphone and the Internet of Things, security experts have been warning of the threat of vulnerabilities in apps and connected devices, with which consumers often take a more lax approach to cybersecurity.
“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.
“Web application attacks remain one of the most frequent patterns in confirmed breaches and account for up to 35% of breaches in some industries according to the 2015 Verizon Data Breach Investigations Report. Time will tell whether we’ve dodged a potentially catastrophic bullet – but hopefully this case will heighten people’s awareness of the cyber threat to applications and consumer devices.
“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.”[/su_note]
[su_note note_color=”#ffffcc” text_color=”#00000″]Mark Loveless, Senior Security Researcher at, Duo Security:
“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.”[/su_note]
[su_note note_color=”#ffffcc” text_color=”#00000″]Jonathan Sander, VP of Product Strategy of, Lieberman Software:
“This glibc bug is reminiscent of the OpenSSL vulnerability, Heartbleed. If Linux is a car, then glibc is a bolt found in nearly every part of the car. We face the same challenge we did with Heartbleed: you can’t issue a recall on the entire Internet to fix these parts quickly enough. Luckily, this glibc bug seems a bit harder to exploit, and researches have already published long lists of work around methods to protect you while a fix is forthcoming.
The most interesting bit about it may be the comment it makes about the open source community’s ability to secure its code. The bug was introduced in 2008 and apparently had been in every version since that time. It was only found by a Google researcher by accident at this point, but when he reported it he found out the team that maintains glibc knew about it since July. While it’s not uncommon for complex bugs like this to go undiscovered for a long time, it is a bigger question why it would be left there for 7 months after discovery.”[/su_note]
[su_note note_color=”#ffffcc” text_color=”#00000″]Mark James, Security Specialist at IT Security Firm, ESET:
“Glibc is a vulnerability or flaw in code used by various pieces of internet connected hardware. If the flaw is exploited it could allow code to be run to enable remote access to the device, this could enable you to remove data, gain access or monitor sensitive information.
As with a lot of these types of vulnerability it’s hard to say how many it affects. The glibc library is widely used in internet facing devices, although alternatives are available it’s extremely difficult to determine exactly how many it potentially could affect. This could include not just devices but applications and web services.
Hackers could implant code into the device’s memory when domain look-ups are performed, this happens whenever domain conversion happens between the common name that we understand, say BBC, into an IP address that computers use to find that server holding the information. Once compromised remote code could be executed thus taking complete control of the device, once this happens realistically anything could happen at their command.
If it were to be successfully exploited, it could be as serious as any of the major bugs, Shellshock included. When vulnerabilities affect massive amounts of devices it has the potential of mass damage, but quite often in these cases the flaw is patched and no real damage is done, let’s hope it’s the latter.
Checking to see if you’re using the affected version and if so looking at alternatives could be your only solution currently until it is patched. But of course keeping all your applications and services up to date is a must these days, awareness and education is a very powerful tool in the fight against cybercrime.”[/su_note]
[su_note note_color=”#ffffcc” text_color=”#00000″]Chris Eng, VP Research, Veracode:
“Though the potential impact of malicious code exploiting the Glibc (CVE-2015-7547) vulnerability is great, exploiting it is not straightforward. An attacker may have to customise the exploit for each version of the library and for each operating system they wanted to go after.
Like Heartbleed and Shellshock before it, the Glibc vulnerability reinforces the reality that using components in the application development lifecycle introduces risk. The fact of the matter is that our software is constructed like Legos, relying on components rather than coding. This is why it’s important to have complete visibility into all of the components development team are using, as well as the versions being used to ensure they can quickly patch and/or update the component version when a new vulnerability is disclosed.”[/su_note]
[su_note note_color=”#ffffcc” text_color=”#00000″]Craig Young, Cybersecurity Researcher at Tripwire :
“This is quite an interesting bug, but my expectation is that we will not see widespread exploitation for code execution due to several factors. While many have espoused ASLR as making this vulnerability difficult to exploit, I actually take a different stance.”
ASLR or Address Space Layout Randomization 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. The fact of the matter though is that very few Linux systems have system wide ASLR enforcement and with a bug affecting such a widely used function; it is inevitable that many vulnerable products will not gain the ASLR protections. The bigger barrier to execution as I see it 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.”
“The more common attack scenario of course would be a recursive lookup since hopefully most attackers do not have control over popular DNS servers. The problem with this scenario however, 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. That being said, it is important that users and service operators deploy patches as soon as possible. If we do see cases of in the wild exploitation from this, I would expect that web sites or services which query user-controlled domain names might be top on the list of ideal targets.”[/su_note]
About the Author
The opinions expressed in this post belongs to the individual contributors and do not necessarily reflect the views of Information Security Buzz.
