In the early hours of 28^th January GMT+0 2015, news started to go mainstream about vulnerability in the open source glibc library. The issue has been given the vulnerability marketing term “Ghost” (the name derives from the fact that the vulnerability arises because of an exploitable bug in the gethostbyname() function).

The buffer overflow vulnerability has been given the CVE reference CVE-2015-0235.

glibc is not a program as such. It’s a library that is shared among one or more programs. It is most commonly found on systems running some form of Linux as an operating system.

Redhat mention on their site that DNS resolution uses the gethostbyname() function and this condition has supposedly been shown to be vulnerable. This makes the Ghost issue much more critical than many are claiming.

As with most things in security, the answer to the question “is it dangerous for me” is “it depends” – sorry – there is no simple binary yes or no here. Non-vulnerable versions of glibc have been available for some time now, so if the installation of the patch (read the last section on “Mitigation” for details) is non-disruptive, then just upgrade.

Most advisories are recommending the immediate installation of a patch, but read on…

Impact

glibc is a core component of Linux. The vulnerability impacts most Linux distributions released circa 2000 to mid-2013. This means that, similar to Heartbleed, it affects a wide range of applications that happen to call the vulnerable function.

Giving credit to the open source dev team, the bug was fixed in 2013 but some vendors continued to use older branches of glibc.

If the issue is successfully exploited, unauthorised commands can be executed locally or remotely.

To be clear: this bug is remotely exploitable. So far at least one attack vector has been identified and tested successfully. Exim mail server uses the glibc library and it was found to be remotely exploitable thru a listening SMTP service. But again – its not as simple as “I run Exim therefore I am vulnerable”. The default configuration of Exim is not vulnerable.

Just as with Shellshock, a handful of attack vectors were identified immediately and more began to surface over the following weeks. The number of “channels”, or “attack vectors” by which the vulnerability may be exploited determines the likelihood that an attack may be attempted against an organisation.

Also, just as with Shellshock, it cannot be said with any decisiveness whether or not the exploit of the issue gains immediate root access. It is not chiselled in stone that mail servers need to run with root privileges, but if the mail server process is running as root, then root will be gained by a successful exploit. It is safer to assume that immediate root access would be gained.

More recent versions of Exim mail server on Ubuntu 14 run under the privileges of the “Debian-exim” user, which is not associated with a command shell, but also default Ubuntu installations will be easy for moderately skilled attackers to compromise completely.

So there is a possibility that remote, unauthenticated access can be gained with root privileges.

Just as with Shellshock, we can expect there to be automated BOT – initiated scanners that look for signs of exploitable services on the public Internet and attempt to gain local access if a suitable candidate is found.

At the time of writing, Rapid 7 have said they are working on a Metasploit test for the condition, which as well as allowing organisations to test for their vulnerability to Ghost, also of course permits lower skilled attackers to exploit the issue.

Another example of an exploitable channel is Rapid 7’s own tool Nexpose, which if running on an Ubuntu 12 appliance, will be vulnerable. However this will not be remotely exploitable.

Redhat mention on their site that DNS resolution also uses the gethostbyname() function and “to exploit this vulnerability, an attacker must trigger a buffer overflow by supplying an invalid hostname argument to an application that performs a DNS resolution”. If this is true, then the seriousness of Ghost increases exponentially because DNS is a commonly “exposed” service thru Internet-facing firewalls.

A lot of software on Linux systems uses glibc. From this point of view, its likely there could be a lot more attack vectors appearing with Ghost as compared with Shellshock. Shellshock was a BASH vulnerability and BASH is present on most Linux systems. However, the accessibility of BASH from a remote viewpoint is likely to be less than that of Ghost.

Risk Evaluation

There is “how can it be fixed?” but first there is “what should we do about it?” – a factor that depends on business risk.

When the information security community declares the existence of new vulnerability, the risks to organisations cannot categorically be given even base indicators of “high”, “medium”, or “low”, mainly because different organisations, even in the same industry sector, can have radically differing exposure to the vulnerability. Factors such as network segmentation can have mitigating effects on vulnerability, whereas the commonplace DMZ plus flat RFC 1918 private space usually vastly increases the potential financial impact of an attack.

Take a situation where a vulnerable Exim mail service listens exposed to the public Internet, and exists in a DMZ with a flat, un-segmented architecture, the risk here is considerable. Generally with most networks, one host falls on a network, and then others can fall rapidly after this.

Each organisation will be different in terms of risk. We cannot even draw similarities between organisations in the same industry sector. Take a bank for example: if a bank exposes a vulnerable service to the Internet, and has a flat network as described above, it can be a matter of minutes before a critical database is compromised.

As always the cost of patching should be evaluated against the cost of not patching. In the case of Ghost, the former will be a lot cheaper in many cases. Remember that increasing numbers of attack vectors will become apparent with time. A lot of software uses glibc!! Try uninstalling glibc on a Linux system using a package manager such as Aptitude, and this fact becomes immediately apparent.

Mitigation

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.

Note that several services may be using glibc so patching should not take place until all dependencies are known and impacts evaluated.

The machine will need a reboot after the upgrade of glibc.