What is GHOST?
GHOST is a serious vulnerability that has been discovered in the glibc library.
What is the glibc?
It’s the GNU C Library, a key part of the Linux operating system. If you don’t have glibc, your Linux system is not going to work.
So, what’s the vulnerability?
Researchers at Qualys discovered a buffer overflow vulnerability in the __nss_hostname_digits_dots() function of glibc, that can be triggered (locally or remotely) via the gethostbyname*() functions used to resolve hostnames.
Okay, you’re getting slightly nerdy… tell me what’s the danger?
An attacker could exploit the vulnerability to remotely execute malicious code on a vulnerable system, and gain complete control.
That sounds bad
It is. Qualys says it has developed a proof-of-concept attack in which sending a specially crafted email to a mail server can give them remote access to a Linux machine. They say that it bypasses all existing protection systems on both 32-bit and 64-bit systems.
How old is the vulnerability?
Versions of glibc as far back as glibc-2.2, released way back in 2000, are affected by the vulnerability.
Hmm. So, what versions and operating systems are at risk from the GHOST vulnerability?
Here’s what Qualys says in its blog post about the vulnerability:
The first vulnerable version of the GNU C Library affected by this is glibc-2.2, released on November 10, 2000. We identified a number of factors that mitigate the impact of this bug. In particular, we discovered that it was fixed on May 21, 2013 (between the releases of glibc-2.17 and glibc-2.18). Unfortunately, it was not recognized as a security threat; as a result, most stable and long-term-support distributions were left exposed including Debian 7 (wheezy), Red Hat Enterprise Linux 6 & 7, CentOS 6 & 7, Ubuntu 12.04, for example.
What needs to be done?
Fortunately, Qualys informed Linux distribution vendors in advance of going public, and patches are now available.
Will I have to reboot my servers to apply the patch?
Almost certainly, yes. Sorry.
Where can I find more information?
- Qualys Advisory: https://www.qualys.com/research/security-advisories/GHOST-CVE-2015-0235.txt
- RedHat: https://rhn.redhat.com/errata/RHSA-2015-0090.html
- Ubuntu: https://launchpad.net/ubuntu/+source/eglibc
- Debian: https://security-tracker.debian.org/tracker/CVE-2015-0235
- GNU C Library: http://www.gnu.org/software/libc/
- Mitre: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-0235
Have any bad guys exploited the GHOST vulnerability yet?
Not as far as we know. But now details of the vulnerability are emerging publicly, it may only be a matter of time.
Companies are busy patching themselves. For instance, WP Engine (which hosts this website) says it updated all of its servers last night. Thanks guys!
Why is it called GHOST?
First answer: Because every vulnerability these days needs a sexy name. After all, no-one normal would ever call it CVE-2015-0235.
Second answer: The vulnerability can be triggered by the GetHOST functions. Geddit?
I like the logo. It’s cute
Yes it is. You might find this technical analysis of the logo (not the vulnerability) amusing.
At least it didn't take a month before the patch was pushed out, like it does with closed source products and that is if you are lucky, otherwise it can take over a year before patched.
Ah, so that is what I pulled in. Usually I check changes but then I got distracted this time. And indeed: open source is typically patched very quickly because the developers are passionate about their work. It is different when it is your job.
However… Graham, a point of interest you might want to note (that might help administrators who don't want downtime):
"Will I have to reboot my servers to apply the patch?
Almost certainly, yes. Sorry."
Or do you? That is the beauty of shared libraries, isn't it? No, you don't have to reboot. First, two things: if you look at the advisory they have a test program to compile and run to determine this. But even then (to humour the situation I did it although I already knew the answer) you can always restart the services that use the library calls to ensure that the library (glibc) is loaded (worse case scenario). If you have anything compiled with static glibc, that is another issue entirely (but rebooting won't help you there, either – you'll have to recompile it completely!).
Background info for those interested (I do network programming for many years):
—
As the advisory points out, those functions are mostly obsolete (They are still used though). But then: obsoleted doesn't mean not used so that isn't a point of dismissing it (just that many services will use the newer api ). But there's some things to keep in mind (first will explain the new API albeit only why it exists) The new (not really new) API was designed for IPv6 to work with IPv4 (differences in the protocols mean IPv4-specific api would not suffice). To those who worry: it doesn't matter if you have an IPv6 stack or not – it is still used. Even though the old functions can be called, you're in better shape nowadays than not (also it isn't necessarily the case that calling the old functions is automatically a problem – there are conditions that need to be met).
As for my credibility here? I used to use the old BSD (which Linux uses but has extensions and Linux specifics; however, I would like to call BSD sockets the de facto standard and my point is the same: I am familiar with socket programming) sockets API and for many years I have used the newer API. That includes for both IPv4 service (without IPv6 stack) and for both (and IPv6-only is also possible).
If you have an ubuntu system, you can check your glibc version with:
$ sudo apt list | grep glibc
WARNING: apt does not have a stable CLI interface yet. Use with caution in scripts.
clisp-module-bindings-glibc/trusty 1:2.49-9ubuntu1 amd64
eglibc-source/trusty-updates 2.19-0ubuntu6.5 all
glibc-doc/trusty-updates 2.19-0ubuntu6.5 all
glibc-doc-reference/trusty 2.19-0ubuntu1 all
Note that some variant of ubuntu, namely Linux Mint, may have a different apt in your path (which is a bit disturbing to me). In this case, specifically for Mint 17, you would use:
rmf@vecna ~ $ sudo /usr/bin/apt list | grep glibc
[sudo] password:
WARNING: /usr/bin/apt does not have a stable CLI interface yet. Use with caution in scripts.
clisp-module-bindings-glibc/trusty 1:2.49-9ubuntu1 amd64
eglibc-source/trusty-updates 2.19-0ubuntu6.5 all
glibc-doc/trusty-updates 2.19-0ubuntu6.5 all
glibc-doc-reference/trusty 2.19-0ubuntu1 all
Frustrating….
If you're going to check glibc version you might as well not rely on distribution specifics. Try the following (you don't have to be root):
/lib64/libc.so.6 |sed -n '/release/p'
If you don't have sed you could just skip filtering it and look at the line that looks like :
GNU C Library (GNU libc) stable release version 2.20, by Roland McGrath et al.
Just as a tip for future reference.
(of course /lib64 would be /lib under 32-bit only systems and in addition, it is assuming the symlink exists – as it should – but the general idea is you're using libc itself to tell you what version it is rather than rely on a package manager to tell you. No comment on ppc, sparc and other architectures as I cannot recall for 100% – I seem to think some are similar but that there are also differences)
Anyone managed to trigger this vulnerability in something else than Exim with unconventional configuration?
Yes. The original advisory refers to several services (and otherwise software that uses the socket calls in question) that are vulnerable and also several that are not.
That ghost looks like Red, the character from the game "Story of Red" on Android! :-)
Unfortunately it'll probably never get patched in the endless NAS boxes, routers. printers, scanners, webcams, etc running linux from their firmware. The vendors have moved on and often don't supply updates once they've got a newer box to sell.
Someone has thoughtfully written a small vulnerability tester in C to compile:
http://www.cyberciti.biz/faq/cve-2015-0235-patch-ghost-on-debian-ubuntu-fedora-centos-rhel-linux/
Nice to know all my systems are already patched.
It (and much more) was actually in the original disclosure. They went through a lot of work to testing different services under different conditions as well as explaining what went wrong.. and then putting it all together as a presentation.