A bug is haunting Linux systems.
The Ghost vulnerability recently revealed by researchers at Qualys has triggered comparisons to Shellshock, but some experts say that both the impact and how organizations should approach patching it is different.
“Applying a patch to bash and rolling out a newer version to me seems a lot easier,” said Jon Passki, lead security researcher at Coverity. “None of its dependencies are touched, so the fix can be very specific. As a sysadmin or someone in security operations, I’d rather have Shellshock than Ghost.”
Ghost is a buffer overflow issue in the Linux glibc library. If the bug is exploited, it could enable an attacker to take control of a targeted system.
“Glibc (libc) is a core library for many packages and for the host operating system,” Passki continued. “For example, Ubuntu’s kernel is compiled using a specific version of libc. So you get into dependency tango between the kernel, its version of libc, and then other applications installed on the operating system. The short of it is upgrading from one version of glibc to another isn’t possible until the main operating system is upgraded. Then you get into third party packages. They often write and compile against certain versions of libc. Again, they’re in the same boat. For example, maybe there’s a bug in libc that prevents their application from working, so they’ll compile to an older version.”
“Libc might backport the fix because of all the aforementioned issues,” he added. “That would still require, in some cases, applications to be recompiled with the now patched backported libc…So there will be a lag in when those new versions are available.”
Patching glibc is a little different than a library like OpenSSL due to kernel and build tool dependencies, said HD Moore, chief research officer at Rapid7.
“To work around this, vendors often standardize on one version of glibc and then backport the security patches as needed,” he said. “This gethostbyname() issue was the result of an issue being identified and patched, but not marked as a security issue, and therefore not backported to older glibc versions. From a vendor perspective, patching glibc is a lot of work, as patches have to be backported for each version used by each supported release. From a user perspective, the standard update process applies – however in this case a reboot is also a good idea.”
According to Qualys, the first vulnerable version of the GNU C Library affected by this is glibc-2.2, which was released on Nov. 10, 2000. There are a number of factors that mitigate the bug however; for example, the issue was actually fixed on May 21, 2013, between the releases of glibc-2.17 and glibc-2.18. However, most stable and long-term-support distributions were left exposed including Debian 7 (wheezy), Red Hat Enterprise Linux 6 and 7, CentOS 6 and 7 and Ubuntu 12.04.
The release of a fix in 2013 means that many newer Linux operating systems were never at risk, mitigating the threat, blogged Trend Micro’s Pawan Kinger.
“Secondly, not all applications are at equal risk,” Kinger added. “Exploitation is very difficult as an attacker only has a small amount of initial exploit code that can be used: 4 or 8 bytes (depending on whether the system is a 32- or 64-bit system). Additional code must be written to an address referenced by a pointer which the attacker can modify. As a result, many apps are not at risk. So far, we are not aware of any potential web attack vectors, which reduces the attack surface considerably.”
The GHOST.c utility included in the original advisory can quickly tell you whether or not the local glibc has been patched, said Moore.
“Another way to tell would be to consult a list of patched package versions, such as the one published by Matasano,” Moore added. “If the system has not been rebooted in the last few days, that is also a great indication that the patch may not have been applied, or if it was applied, it was not yet effective due to the need for a full restart of all affected services. In practice, system uptime is going to be a good indicator to determine which machines may have been skipped.”
According to Passki, Linux deployments using Exim as a mail server should be immediately upgraded, as should Linux deployments with untrusted users on them. There are vulnerable setuid / setguid utilities that can lead to local account escalation, he added. Otherwise, this issue should be treated as any other high priority patch by an enterprise.
“This leaves the statically linked library residue,” he said. “That’s a harder problem. Organizations should know already what proprietary software they’re running. If not, this would be step one. Then, for each of these products, especially products that connect to the network, they should ask the vendor if they’re statically linked to glibc, if so what version, and if it’s a vulnerable version, what’s the vendor’s remediation time frame.”
“Now, not all vulnerable software will be or can be exploited, so the sky is not falling,” he added. “Some vendors software is deployed in a low risk way, even if it’s vulnerable. So the patching and remediation of these should mirror the risk tolerance of an organization…Regardless, vendors should be able to communicate the risk to the enterprise organizations affected.”
