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.

More from Software Vulnerabilities

X-Force releases detection & response framework for managed file transfer software

5 min read - How AI can help defenders scale detection guidance for enterprise software tools If we look back at mass exploitation events that shook the security industry like Log4j, Atlassian, and Microsoft Exchange when these solutions were actively being exploited by attackers, the exploits may have been associated with a different CVE, but the detection and response guidance being released by the various security vendors had many similarities (e.g., Log4shell vs. Log4j2 vs. MOVEit vs. Spring4Shell vs. Microsoft Exchange vs. ProxyShell vs.…

MSMQ QueueJumper (RCE Vulnerability): An in-depth technical analysis

13 min read - The security updates released by Microsoft on April 11, 2023, addressed over 90 individual vulnerabilities. Of particular note was CVE-2023-21554, dubbed QueueJumper, a remote code execution vulnerability affecting the Microsoft Message Queueing (MSMQ) service. MSMQ is an optional Windows component that enables applications to exchange messages via message queues that are reachable both locally and remotely. This analysis was performed in collaboration with the Randori and X-Force Adversary Services teams, by Valentina Palmiotti, Fabius Watson, and Aaron Portnoy. Research motivations…

X-Force prevents zero day from going anywhere

8 min read - This blog was made possible through contributions from Fred Chidsey and Joseph Lozowski. The 2023 X-Force Threat Intelligence Index shows that vulnerability discovery has rapidly increased year-over-year and according to X-Force’s cumulative vulnerability and exploit database, only 3% of vulnerabilities are associated with a zero day. X-Force often observes zero-day exploitation on Internet-facing systems as a vector for initial access however, X-Force has also observed zero-day attacks leveraged by attackers to accomplish their goals and objectives after initial access was…

Topic updates

Get email updates and stay ahead of the latest threats to the security landscape, thought leadership and research.
Subscribe today