On Tuesday, Jan. 27, a zero-day vulnerability (CVE-2015-0235) was disclosed in the Linux operating system that allows malicious code to be executed on servers that use the GNU C Library (glibc) functionality. Linux programs that contain glibc are also affected. The specific call, gethostbyname(), can be triggered by any type of Domain Name System (DNS) resolution within the code, although the primary effect is on systems that accept host names from clients and attempt to resolve them through DNS. In reference to the GetHOST functionality, the vulnerability has been nicknamed “Ghost.”

Technical Description

According to Red Hat Bugzilla, a heap-based buffer overflow was found in glibc’s __nss_hostname_digits_dots() function, which is used by the gethostbyname() and gethostbyname2() glibc function calls. A remote attacker able to make an application call to either of these functions could use this flaw to execute arbitrary code with the permissions of the user running the application.

There are at least three use cases. “Modern” applications likely use getaddrinfo() instead of gethostbyname(). Slightly less modern applications usually call inet_aton() first and only call gethostbyname() after inet_aton() fails. Both of these types of applications are more likely to be safe. The ones most likely to be vulnerable are older applications that use gethostbyname() and are used “itinerantly” or applications that are maintained “not much at all.”

Affected Servers and Products

Affected versions include glibc-2.2, released on Nov. 10, 2000. Although a patch for this zero-day vulnerability was already issued on May 21, 2013 (between the releases of glibc-2.17 and glibc-2.18), many systems in operation remain unpatched because it was not recognized as a security threat at the time. Newer systems likely shipped with the vulnerability fixed, but this vulnerability remains a threat to older systems and applications, especially in light of the shift from gethostbyname() to getaddrinfo() in applications.

The glibc libraries are used by a wide range of services, and the pervasiveness of the glibc library is reminiscent of the Shellshock zero-day vulnerability. Ghost is further complicated by the nature of the affected services. Any protocol that allows or requires the client to specify a host to the server to be resolved via DNS is at risk. This includes both the obvious Simple Mail Transfer Protocol HELO/EHLO commands and more subtle protocols where a server will accept a host name from a client to resolve later or pass it on to other servers that would eventually attempt to resolve them via DNS.

The nature of glibc and its use means that applying such a patch requires a reboot of the entire affected server, which can hinder many organizations from applying necessary patches due to the disruptive nature of the fix. However, it is more desirable to reboot a server than to have the network compromised by a malicious actor.

Zero-Day Vulnerability Exploitation

The vulnerability can be exploited both locally and remotely by all the gethostname*() functions, but this is difficult due to several factors. Only 4 to 8 bytes can be overwritten, and the values written are limited to ASCII periods, digits and the terminating NULL character.

In one attack vector, a buffer overflow can be triggered by using a host name argument that appears valid to glibc yet is just off enough to trigger the overflow. This attack could ultimately let the attacker gain complete control over the compromised system by supplying the exploited server with malicious code to execute. All of this can happen without the attacker having any prior knowledge of system credentials, although each case presents its own challenges for exploitation.

Qualys, which discovered the bug, developed a proof-of-concept exploit that was able to bypass all existing protections. Although the Qualys bypass addressed a handful of specific and common applications, it appears at this point that exploitation attempts must be tightly tailored to the memory layout of the application under attack.

Recommendations for Clients

Although there may be operational impact, it is important to apply vendor patches. Administrators should be prepared for the inevitable reboots required on servers. Many vendors, such as Red Hat, Debian, Ubuntu and Novell, have released patches that include the original fix from 2013. In addition, clients are encouraged to:

• Leverage an endpoint solution to automatically deploy the patch to remediate noncompliant systems.
• Maintain a current and accurate asset inventory and enforce continuous security configuration compliance through real-time monitoring and reporting of all endpoints. A noncompliant endpoint is automatically quarantined to safeguard against further vulnerabilities until remediation is complete.
• Create and practice a broad incident response plan. All activities related to vulnerability disclosures and active attacks must be guided by processes involving all levels of your organization and guided by clear procedures for a variety of situations. Test the procedures often to make sure you are not working out the kinks when an actual emergency arises.
• Implement mitigating controls. Firewalls, intrusion prevention systems and endpoint protection all can help protect against new threats during the period between the vulnerability disclosure and when you’re able to apply vendor patches.