CVE-2015-0235: A GHOST in the Machine

On Tuesday January 27, 2015, security researchers from Qualys published information concerning a 0-day vulnerability in the GNU C library. The vulnerability, known as “GHOST” (a.k.a. CVE-2015-0235), is a buffer overflow in the __nss_hostname_digits_dots() function. As a proof-of-concept, Qualys has detailed a remote exploit for the Exim mail server that bypasses all existing protections, and results in arbitrary command execution. Qualys intends to release the exploit as a Metasploit module.

CVE-2015-0235 affects the functions gethostbyname() and gethostbyname2() –functions originally used to resolve a hostname to an IP address. However, these functions have been deprecated for approximately fifteen years, largely because of their lack of support for IPv6. The superseding function is getaddrinfo() which does support IPv6 and is not affected by this buffer overflow. Programs that still utilize the deprecated gethostbyname() and gethostbyname2() functions may potentially be affected by GHOST.

GHOST Not as Scary as it Seems

There are a number of factors identified by Qualys which mollify the severity of this bug. First, in order for the vulnerability to be successfully exploited the application would need to accept hostnames as input, and resolve them using one of the deprecated gethostbyname() functions. Additionally, there are restrictions on the hostname which can be used; The first character in the hostname must be a digit, the last character cannot be a dot (.), and the entire hostname may consist only of digits and dots(.).

Relatively few real-world applications will even accept this type of data as input; The examples of vulnerable applications cited by Qualys include the Exim mail server, procmail, pppd and others. Due to the nature of the vulnerability, generic detection for this vulnerability is not possible at this time. Detection must be deployed on an application-by-application basis. Talos continues to research additional programs that utilize the obsolete gethostbyname() functions, publishing supplemental rule coverage as necessary.

A patch remediating this vulnerability has been available since May 21, 2013. However, the security implications of the bug were not immediately recognized at the time the patch was developed and incorporated into glibc. Red Hat, Debian, and many other mainstream Linux distributions have released patches for glibc that mitigate this vulnerability. Linux users and administrators are strongly encouraged to patch affected systems to mitigate the potential risk.

Conclusion

Although this is a severe vulnerability that allows for a remote code execution, the threat of exploitation is relatively low due to the constraints required to get to the vulnerable strcpy command: Any program an attacker would exploit must utilize one of the deprecated gethostbyname() functions, and the malformed hostname passed to the function is required to consist exclusively of digits and only three dots or less.

The most likely outcome in a real-world scenario would be a segmentation fault, not code execution. Regardless, because of the possibility of exploitation, snort signatures have been created to detect any attempts to exploit overflows to the POC application (Exim mail server). Currently, Talos researchers have not seen the exploit in the wild but with the publication of a Metasploit module imminent, we expect that situation to change.

Protecting Users

The Network Security protection of IPS and NGFW have rules to detect malicious network activity by threat actors attempting to exploit known vulnerable applications.

AMP, CWS, ESA, and WSA are not applicable for detecting attempts to exploit this vulnerability.

So I am trying to get an idea just how serious this is on Nexus Switches and how this affects this platform. How would they exploit this bug on a Nexus box. We dont' use any kind of DNS resolution on these switches. We just got done patching another hole and don't want to have to go back and do it again if this is a low probability threat .

Some of the individuals posting to this site, including the moderators, work for Cisco Systems. Opinions expressed here and in any corresponding comments are the personal opinions of the original authors, not of Cisco. The content is provided for informational purposes only and is not meant to be an endorsement or representation by Cisco or any other party. This site is available to the public. No information you consider confidential should be posted to this site. By posting you agree to be solely responsible for the content of all information you contribute, link to, or otherwise upload to the Website and release Cisco from any liability related to your use of the Website. You also grant to Cisco a worldwide, perpetual, irrevocable, royalty-free and fully-paid, transferable (including rights to sublicense) right to exercise all copyright, publicity, and moral rights with respect to any original content you provide. The comments are moderated. Comments will appear as soon as they are approved by the moderator.