GHOST in the Shell – CVE2015-0235

Continuing the trend set by Heartbleed, Shellshock and POODLE comes another named vulnerability, welcoming us into the new year with the promise of remote code execution and buffer overflows against all the servers we’ve locked in cupboards and forgotten about.

Allow me to introduce to you CVE 2015-0235; ‘GHOST‘.

It’s not a real exploit without a cute logo


This newly-exploited weakness has been christened ‘GHOST’ in deference to the GetHOST function call in which the vulnerability exists; this lies within the linux-based glibc library, specifically a function heavily used to convert hostnames into IP addresses, gethostbyname(). This function improperly handles certain string processing operations, opening up potential for an overflow of the memory buffer. As the function by nature is employed in communication with the wider internet, there is potential for exploitation of any service or daemon that calls it from the glibc library.

This is a classic buffer overflow attack, and bypasses existing mechanisms designed to complicate such techniques, including NX, ASLR and PIE.

The earliest vulnerable version is identified as glibc-2.2, released on November 10, 2000. Versions subsequent to glibc-2.17 are not vulnerable; unfortunately this means a lot of Long Term Support releases for various core linux distributions remain exposed to the attack until they are patched including CentOS/7, Debian 7, RHEL 6/7 and Ubuntu 12.04.

It is worth stating clearly at this point that Proof-of-Concept code is available to attack the popular ‘Exim‘ mail service through this vulnerability (mitigation here), and reports are filtering in that attempts to exploit the hole are beginning to be seen in-the-wild. To quote from the official announcement:

Despite these limitations, arbitrary code execution can be achieved. As a proof of concept, we developed a full-fledged remote exploit against the Exim mail server, bypassing all existing protections (ASLR, PIE, and NX) on both 32-bit and 64-bit machines. We will publish our exploit as a Metasploit module in the near future.

Keen observers will note that the imminent publication of a Metasploit module significantly increases the risk posed by the exploit if left unpatched. Please read the OxCERT Security Bulletin OSB2015-014 for further information and remediation advice. Software vendors should be updating their repositories with a patch very shortly, if they have not already done so.

This of course applies only to services that are run on supported operating systems.

You ARE running a supported Operating System, right?

You ARE running a supported Operating System, right?

Am I vulnerable?

The full attack surface exposed by the exploit is currently not known, which complicates automated non-destructive testing. The Proof-of-Concept code listed in the original announcement could certainly confirm the presence of the vulnerability on your servers, but as it displays a tendency to SEGFAULT services it is launched against we would advise against this approach in a production environment.

A rough test for vulnerable C libraries on unpatched systems can be performed thus;

ldd --version

This should allow you to identify that your version is higher than 2.17 (not vulnerable) or between 2 and 2.17 (vulnerable). It is also possible to establish which applications depend upon glibc with the following command string:

lsof | grep libc | sort

Example output:

Guru meditation

Guru meditation

Note: Please be aware that once your system has received patches, the major version may be retained. In this case a recently-patched system might retain a ‘vulnerable’ version string in the test above, this is intended only as a quick test for operators who are certain their systems have not yet received the glibc patches from their vendor and are uncertain if they are running a vulnerable major version.

Known-vulnerable versions of linux include:

  • Arch Linux glibc version 2.18-1 and prior
  • Centos 5, 6 and 7
  • Debian Linux 7
  • Fedora 19 and prior
  • Linux Mint 13
  • OpenSUSE/SUSE Linux Enterprise 11 and prior
  • RHEL 5, 6 and 7
  • Ubuntu 10.04 and 12.04 LTS

Operators of vulnerable platforms are advised to remain vigilant to patches that refer to the glibc packages, and additionally to consider applying these patches ahead of any regularly scheduled maintenance.

Let us know how you get on

How does it work?

The GHOST vulnerability is exploited via the gethostbyname() glibc function, or more precisely __nss_hostname_digits_dots(). This code is invoked when a glibc-linked application wishes to resolve a DNS entry. As developers of connected applications can attest, this can be an extremely common event.

We're gonna exploit like it's 1999

We’re gonna exploit like it’s 1999

The attacker crafts an invalid hostname argument which is then supplied to the application; the application passes this argument to the vulnerable glibc function for processing, and it is here that the buffer overflow occurs. Once successfully exploited, the attack gains a limited yet arbitrary remote code execution privilege, in evasion of standard NX (No eXecute) bit protection and malloc hardening techniques. Similar exploitation can occur in a number of tools and services that make calls to this library.

As a service dependent upon these vulnerable calls, Exim can be attacked via a crafted HELO/EHLO exchange:

Bang, you're dead

Bang, you’re dead

For the brave and the curious, the PoC code is obtainable through links elsewhere in this post, it is distributed in C and is simple to compile against the vast majority of linux distributions. Please be aware that the code can frequently cause segmentation faults, as is to be expected from any exploit that can seize control of unallocated memory space.

May I again discourage the exploiting of production servers

Mitigation and Resolution

Currently there is a lack of conclusive research into which applications are exploitable and which are not. The bug itself was actually discovered and patched in 2013, but was not at that time recognised as a security risk. As such, not all vendors took the decision to include the patch into their newer major version updates; this significantly complicates the task of identifying affected systems by release and version numbers alone.  Contact appropriate software vendors if patches are not forthcoming through regular channels, and ensure that when patches are made available they are applied to all relevant systems as soon as possible.

Once a patch is applied, it is critical to restart all services that depend upon glibc

If your server cannot be fully rebooted at time of patch, a service restart will suffice until a full reboot can be scheduled.

As a general rule, any server operating a version of glibc greater than 2.17 can be considered safe. Enhanced risk applies to operators of Long-Term Support releases as their ‘stable’ release trees currently still include the vulnerable packages, and these releases are more commonly chosen  for ‘set and forget’ deployments where administrative interaction may be at a minimum for long periods. It is imperative that inventories are reviewed for the presence of these older versions.

Operators of unsupported platforms are at potentially greater risk still due to the current absence of back-ports for the relevant patch. as the bug was not seen to represent a critical security threat when it was discovered in 2013; this is a classic example of the risks inherent in maintaining services on unsupported platforms.

Mitigation advice remains as ever; be alert for glibc patches and apply as a matter of urgency, restart affected services, ensure that less visible machines are not overlooked.

Operators of Exim mail servers are advised to refer to the official Exim comments on the subject, which lists some helpful configuration changes that can mitigate the risk of the PoC HELO/EHLO attack vector.

Further Reading

Posted in Uncategorized | 2 Comments

2 Responses to “GHOST in the Shell – CVE2015-0235”

  1. Lucila C B says:

    Another link for SUSE users listed below.

    Dissapointed to see the open source vulnerabilites weren’t all gone and sorted with the end of the 2014.
    Very well explained, succint and helpful at the same time. Many thanks.

  2. Horst Jung says:

    Amazing post – good factual content with highly entertaining illustrations. Please write more of these, Paul!