GHOST in the Machine – Is CVE-2015-0235 another Heartbleed?

Blog Post created by jenellis Employee on Jan 27, 2015

194tvn6u6kw0gjpg.jpgCVE-2015-0235 is a remote code execution vulnerability affecting Linux systems using older versions of the GNU C Library (glibc versions less than 2.18). The bug was discovered by researchers at Qualys and named GHOST in reference to the _gethostbyname function (and possibly because it makes for some nice puns).


To be clear, this is NOT the end of the Internet as we know, nor is it further evidence (after Stormaggedon) that the end of the world is nigh. It’s also not another Heartbleed. But it is potentially nasty and you should patch and reboot your affected systems immediately.


What's affected?

Linux-based appliances from a variety of vendors are going to be impacted, though as with most library-level vulnerabilities, the attack surface is still largely unknown. If you use Linux-based appliances, check with your vendor to determine whether an update is available and needs to be applied.


glibc is a core component of Linux used to implement C libraries. The vulnerability impacts most Linux distributions released between November 10, 2000 and mid-2013. This means that, similarly to Heartbleed, it affects a wide range of applications that happen to call the vulnerable API.


The bug was fixed in 2013, but wasn't flagged as a security issue at the time (or since until now), so vendors using older branches of glibc didn't update the library. We recommend that you apply the latest patches available from your vendor and reboot the patched machine. Applying the update without a reboot may leave vulnerable services exposed to the network.


How bad is it?

Successful exploitation of this vulnerability can result in remote code execution, so it has the potential to be pretty bad. This issue can also be exploited locally in some cases, allowing an unprivileged user to gain additional access. In contrast to a vulnerability like Heartbleed, this issue is not always exploitable. In fact, in a general sense, this is not an easy bug to exploit.


Only one easily-exploitable case has been identified so far, though that may change as additional information comes to light. The one already identified is the Exim mail server. An attacker could abuse this vulnerability to execute arbitrary commands on an unpatched server.


How can you test for it?

This issue is difficult to test for, as the full attack surface is not yet known. As mentioned, the Exim mail server is one example of a vulnerable service and it is possible to test for the issue remotely, without authentication. In general, we recommend using a credentialed vulnerability scan to identify unpatched systems.


Qualys says that they plan to release a Metasploit module targeting the Exim mail server – thank you – however, please note that this exploit depends on a non-default configuration being selected.


The Nexpose update (5.12.0) scheduled for release tomorrow (Wednesday, Jan 28) will include a check for this vulnerability in relevant RHEL, CentOS, Ubuntu, Debian and SUSE distributions.


What should you do about it?

Patch immediately *and* reboot. Without a reboot, services using the old library will not be restarted.


Ubuntu versions newer than 12.04 have already been upgraded to a non-vulnerable glibc library. Older Ubuntu versions (as well other linux distributions) are still using older versions of glibc and are either waiting on a patch or a patch is already available.


Are Rapid7 solutions impacted by this?

Our native code does not use the vulnerable function call, so the solutions themselves are not affected.  However, if you are running Nexpose on an Ubuntu 12.04-based appliance, it is vulnerable, and we are investigating whether it can be exploited remotely and will provide an update. Again, we recommend patching immediately, and it’s always sensible to ensure systems are not accessible from the public-facing internet unless they have to be.


UserInsight used some of the impacted libraries.  Again, we know of no way that this could be remotely exploited but we are redeploying immediately based on a patched version of glibc.


If you have any questions about this bug, please let us know.


~ @infosecjen