Qualys published a blog highlighting a new vulnerability in the Linux GNU C Library (glibc). The GNU glibc CVE-2015-0235 Remote Heap Buffer Overflow Vulnerability (CVE-2015-0235) is a buffer overflow in the __nss_hostname_digits_dots() function used by gethostbyname() function calls and it allows arbitrary code execution from unauthenticated users. The vulnerability was first introduced in November 2000 and has been fixed in source code since May 2013. However, most stable and long-term-support distributions of Linux were left exposed until the major Linux distributors released a patch for the vulnerability on January 27, 2015.
FAQ
Q: Why is it called the GHOST vulnerability?
A: It is called the GHOST vulnerability because it can be triggered by calling the gethostbyname() functions.
Q: How significant is this vulnerability and why?
A: The vulnerability is rated as Critical by major Linux distributors. It allows remote attackers to take complete control of the compromised system without any prior knowledge of system credentials. The first vulnerable glibc version (2.2) was released in November 2000. Most stable and long-term-support distributions were left exposed until now because the vulnerability was not recognized as a security threat.
Q: How does GHOST compare to Heartbleed and ShellShock?
A: The GHOST vulnerability might look as severe as Heartbleed and Shellshock because it allows arbitrary code execution. However, GHOST is not as serious as it appears because a number of factors mitigate its impact. A major mitigating factor is that newer versions of Linux operating systems are not at risk because the bug was fixed in May 2013. Another major factor is that gethostbyname functions are now obsolete. Recent applications use the getaddrinfo function which supports IPv6. Finally, while any application that uses gethostbyname functions is theoretically at risk, some of the conditions required make it less likely that the vulnerability will be successfully exploited. Given these factors, the risk of actual exploitation is significantly less when compared to Heartbleed and ShellShock.
Q: Which versions of glibc are vulnerable?
A: glibc versions 2.2 through 2.17 (inclusive) are vulnerable. Versions 2.18 through 2.20 (inclusive) or under 2.1.3 (inclusive) are NOT vulnerable.
Q: Which OS platforms are being targeted or could be affected?
A: The following OS platforms may be affected:
- Ubuntu Ubuntu Linux 12.04 LTS i386
- Ubuntu Ubuntu Linux 12.04 LTS amd64
- Ubuntu Ubuntu Linux 10.04 sparc
- Ubuntu Ubuntu Linux 10.04 powerpc
- Ubuntu Ubuntu Linux 10.04 i386
- Ubuntu Ubuntu Linux 10.04 ARM
- Ubuntu Ubuntu Linux 10.04 amd64
- Red Hat Enterprise Linux Desktop 5 client
- Red Hat Enterprise Linux 5 Server
- GNU glibc 2.2
- S.u.S.E. Linux 7.1 x86
- S.u.S.E. Linux 7.1 sparc
- S.u.S.E. Linux 7.1 ppc
- S.u.S.E. Linux 7.1 alpha
- S.u.S.E. Linux 7.1
- Wirex Immunix OS 7+
- Debian Linux 6.0 sparc
- Debian Linux 6.0 s/390
- Debian Linux 6.0 powerpc
- Debian Linux 6.0 mips
- Debian Linux 6.0 ia-64
- Debian Linux 6.0 ia-32
- Debian Linux 6.0 arm
- Debian Linux 6.0 amd64
Q: Is this impacting consumers and enterprise customers?
A: Consumers and enterprise customers are affected by the vulnerability because it exists in the major Linux operating systems such as RedHat, Debian, and CentOS. Servers and devices running those unpatched operating systems are vulnerable.
Q: Is user interaction, other than normal web browsing, file opening, and email viewing required to be affected?
A: No. According to tests conducted by Qualys, the vulnerability was exploited by sending a specially crafted email to a mail server in order to get a remote shell to the Linux machine.
Q: Do Symantec and Norton products (Win/Mac/NMS) protect against this threat?
A: We are investigating IPS coverage to block attempts to exploit this vulnerability.
Q: Is this vulnerability being used in the wild?
A: There is no report of the vulnerability being exploited in the wild.
Q: Is there a patch available for this vulnerability?
A: The major Linux distributors posted patches and advisories on January 27, 2015. The References section contains the patches for this vulnerability from several different vendors. Symantec advises that the patches be applied as soon as possible. After the patches have been applied, reboot the system. If the system is not rebooted, services that require glibc will continue using the unpatched version of the library, leaving them vulnerable.
References: