A very serious security issue has been found and patched: CVE-2015-0235 nicknamed “Ghost”.
The security bug
A heap-based buffer overflow was found in glibc’s __nss_hostname_digits_dots() function, which is used by the gethostbyname() and gethostbyname2() glibc function calls. A remote attacker able to make an application call either of these functions could use this flaw to execute arbitrary code with the permissions of the user running the application.
This is major. The gethostbyname() calls can often be triggered remotely for applications that do any kind of DNS resolving within the code.
GHOST is a ‘buffer overflow’ bug affecting the gethostbyname() and gethostbyname2() function calls in the glibc library. This vulnerability allows a remote attacker to execute arbitrary code with the permissions of the user running the application.
The gethostbyname() function calls are used for DNS resolving, which is a very common event. To exploit this vulnerability, an attacker must trigger a buffer overflow by supplying an invalid hostname argument to an application that then calls gethostbyname().
The patch shows the updated files in the nss library (Name Service Switch). The bug was first disclosed on a French mailing list, but it may have been an accident -– the bug probably wasn’t meant to be disclosed already, as no distro’s had updated packages available.
This bug is present in all versions of Red Hat Enterprise Linux and variants (CentOS etc.) as well as debian systems.
Qualys, who discovered the bug during a code audit, wrote a mailing-list entry with more details, including a more in-depth analysis and exploit vectors.
Fixing CVE-2015-0235
Just like the recent OpenSSL heartbleed bug, this will be an annoying one to fix. The update is in the glibc package, but that’s a set of libraries that are being used by a lot of running services. After the update, each of these services needs to be restarted …
To find all the services that rely on the glibc libraries, run the following command. It will list all open files (lsof) and find the files that refer to the glibc libraries.
$ lsof | grep libc | awk '{print $1}' | sort | uniq
The updates are now available for RHEL 5, 6 and 7 as well as CentOS 5, 6 and 7 (all architectures).
GLibc update for CentOS-7 http://t.co/jeLhte0Upu ;; CentOS-6 http://t.co/4FRQQP0B7S ;; CentOS-5 http://t.co/Nq5drHAGyz
— Karanbir Singh (@CentOS) January 28, 2015
Debian and Ubuntu have the updated packages available already so you can upgrade those.
Once the packages are updated and available for your distro, update your box.
For CentOS, Red Hat, Fedora, Scientific Linux, …
$ yum clean all && yum update
For Debian, Ubuntu and derivatives:
$ apt-get clean && apt-get update && apt-get upgrade
Afterwards, restart every service you found with the lsof command above. It’s probably easiest to just reboot your entire server, since pretty much everything depends on glibc … If you can’t reboot the entire system, at least restart all public-facing services like webservers, mailservers, etc.
Until the updates are available to all distributions, it’s a waiting game. And until that time, every DNS name being resolved is a potential security threat …
Possible attack vectors
The gethostbyname() call is probably among the most used ones on a server. That means any kind of DNS resolve can be used to trigger the CVE. The only catch is, you need to control whatever DNS is being resolved.
That could mean;
- Mailservers using reverse DNS lookups on connecting IPs (DNS Blacklisting, SPF checks, …)
- Form submits that allow user content which results in a DNS lookup, think URLs, WordPress XML-RPC pingbacks, …
- MySQL servers doing authentication checks based on hostnames (in MySQL privileges)
- SSH servers that perform DNS lookups for authentication allow/deny rules
- …
For a more in-depth look, including code examples, have a look at the Qualys mailing list entry which covers the situation more in-depth.
Any kind of DNS lookup can potentially trigger this. The only “positive” thing is that the exploit doesn’t immediately escalate privileges, you’re still the same user that ran the command. But there are ways of doing privilege escalation of course. And non-privileged users are still valuable assets for DDoS attacks, making server inventories, …
Update: I’ve been thinking about ways to automate these patches using config management, and I’d love to hear thoughts!
If you’re looking for scripts to test GHOST / CVE-2015-0235 vulnerability, check out this post.