A recent vulnerability disclosure from a group of Qualys researchers reaffirms that there is no rest for the weary and that the New Year will likely keep pace with the former as the first critical and highly publicized vulnerability of 2015 is unveiled. This vulnerability is being referred to as “Ghost” and technical news sources around the world are rushing to report on the impact. These reports have been consistently accompanied with ominous imagery of ghoulish figures and fear-inspiring phrases, but is this Ghost really as scary as the media has portrayed?

Overview – A “Ghost” of GNU Past

This vulnerability is a heap-based buffer overflow vulnerability that can be trigged when a malformed string is passed to the gethostbyname() or gethostbyname2() functions in the GNU C Library (glibc). These vulnerable functions have been present in the glibc library for nearly 15 years.

The origin of the vulnerability in each of these functions is a “hostname” variable. While the implicated code does perform some input validation on the string value stored in this variable, no bounds checking is performed. Due to this implementation flaw, an attacker can supply malformed input consisting of an excessive number of numerical digits and period characters to write to unintended portions of system memory. This type of memory access can potentially be leveraged to execute unauthenticated and unauthorized code on remote systems. The full technical details of this vulnerability can be found in the original disclosure thread from the OSS-Sec mailing list.

Impact – How Scary is Ghost?

The impact of this vulnerability, if exploited, is very high (as is always the case with remote code execution vulnerabilities). Additionally, many services on Linux systems leverage these vulnerable libraries, which would make them potential candidates for a variety of attack vectors.

However, the exploitability of this vulnerability requires highly specific circumstances that make actual exploitation in the wild extremely unlikely. This is due to multiple mitigating factors that were all addressed at length in the original disclosure. These mitigating factors were listed as follows:

  • A patch already exists (since May 21, 2013), and has been applied and tested since glibc-2.18, released on August 12, 2013;
  • The gethostbyname*() functions are obsolete; with the advent of IPv6, recent applications use getaddrinfo() instead;
  • Many programs, especially locally accessible SUID binaries, use gethostbyname() if, and only if, a preliminary call to inet_aton() fails. However, a subsequent call must also succeed (the “inet-aton” requirement) in order to reach the overflow: this is impossible, and such programs are therefore safe; and
  • Most of the other programs, especially remotely accessible servers, use gethostbyname() to perform forward-confirmed reverse DNS (FCrDNS, also known as full-circle reverse DNS) checks. These programs are generally safe because the hostname passed to gethostbyname() has normally been pre-validated by DNS software:
    • “A string of labels each containing up to 63 8-bit octets, separated by dots, and with a maximum total of 255 octets,” makes it impossible to satisfy the “1 KB” requirement; and
    • While glibc’s DNS resolver can produce hostnames of up to (almost) 1025 characters (in the case of bit-string labels and special or non-printable characters), this action introduces backslash characters (“\\”) and makes it impossible to satisfy the “digits-and-dots” requirement.

Despite the Qualys analysts’ disclosure of these highly restrictive conditions, the fear-mongering media has repeatedly omitted these details. Such periodicals consistently fixate upon the theoretical impact of this vulnerability but neglect to report on the real-world implications.

In the past year, the security industry has witnessed an emerging trend of vulnerability disclosures that come packaged with clever names and graphical imagery (Heartbleed, ShellShock, POODLE, etc.). This trend simply seems to be the result of an effort to drive media exposure. Although this practice does increase the public’s attention to information security concerns, it also increases the frequency of widespread reports that lack complete and/or accurate technical details from news sources that are solely concerned with exaggerating the facts for profit.

Consequently, there has also been a consistent increase in the spread of misinformation, flawed assumptions, technical inaccuracies, and unwarranted hysteria. Such trends have resulted in serious real-world issues, like ShellShock and Heartbleed, being lumped together with pedantic and highly theoretical proof-of-concepts, like POODLE and GHOST. Rather than getting caught up in the media frenzy, it is important that industry professionals stop to consider the actual technical details and corresponding real-world impact of a vulnerability to ensure that a measured and appropriate response is provided.

The Final Verdict

No matter how obscure the circumstances must be for exploitation to be possible, the underlying code associated with these functions is still vulnerable and should be updated as a matter of best practice. The vulnerability is the consequence of sustained support for functions that have already been deprecated for some time. As such, remediation will eliminate the risks associated with Ghost (however unlikely), with little-to-no impact on existing services or applications.


Under normal circumstances, the vulnerable library would only be found on Linux systems and not Windows workstations or servers. This is because GNU libraries are native to Linux, and the glibc library specifically is standard on Linux distributions. Therefore, all Linux systems are potentially vulnerable.

The easiest way to determine if a given Linux system is vulnerable is to identify the version of glibc in use on the system. Unpatched versions of glibc, prior to glibc-2.18, are vulnerable and should be updated. In most cases, a simple terminal command can be used to identify the version that’s in use. Note: in each example below, the command is in blue, and the identified version is in red.

  • Use the following command with Ubuntu and Debian:
# ldd --version
ldd (Ubuntu EGLIBC 2.11.1-0ubuntu7.20) 2.11.1
  • Use the following command with CentOS and RedHat:
# rpm -q glibc 

Determining if the library contains the vulnerable functions requires consideration of both the running version and the patch / minor-version. This is due to the fact that numerous patched versions of the glibc library prior to glibc-2.18 are no longer vulnerable. If the returned version predates the versions listed below, then the system is vulnerable and should be patched:

  • Ubuntu 12.04 LTS: 2.15-0ubuntu10.10
  • Ubuntu 10.04 LTS: 2.11.1-0ubuntu7.20
  • Debian 7 LTS: 2.13-38+deb7u7
  • CentOS 6: glibc-2.12-1.149.el6_6.5
  • CentOS 7: glibc-2.17-55.el7_0.5
  • RHEL 5: glibc-2.5-123.el5_11.1
  • RHEL 6: glibc-2.12-1.149.el6_6.5
  • RHEL 7: glibc-2.17-55.el7_0.5

Unless unique circumstances dictate otherwise, GuidePoint recommends updating to the latest stable version, regardless of the current running version.


To update to the latest version of glibc (whether for mitigation or general hardening), a single update command should be run from the terminal, and then the system will need to be rebooted for the change to take affect.

  • Use the following command with Ubuntu and Debian:
# sudo apt-get update && sudo apt-get dist-upgrade 
# sudo reboot

Warning: Upgrading the distribution can result in significant changes, so be sure to plan according. 

  • Use the following command with CentOS and RedHat:
# sudo yum update glibc 
# sudo reboot

About GuidePoint Security

GuidePoint Security, LLC provides customized, innovative and valuable information security solutions and proven cyber security expertise that enable commercial and federal organizations to successfully achieve their security and business goals. By embracing new technologies, GuidePoint Security helps clients recognize the threats, understand the solutions, and mitigate the risks present in their evolving IT environments. Headquartered in Reston, Virginia, and with offices in Michigan, New Hampshire, Florida and North Carolina, GuidePoint Security is a small business, and classification can be found with the System for Award Management (SAM). Learn more at: