GHOST (CVE-2015-0235) just popped up.

GHOST bug: is there a simple way to test if my system is secure? deals with how to find out if your system is vulnerable.

In the mean time, you can implement immediate limited threat mitigation by disabling reverse DNS checks in all your public facing services. For example, you can disable reverse DNS checks in SSH by setting UseDNS no in /etc/ssh/sshd_config.

Which other common server software open to the outside world are vulnerable to this attack? varnish, Apache, nginx? And are there quick work arounds like with OpenSSH?

  • 4
    The CVE lists the vulnerable function. Any service that uses that function is potentially vulnerable.
    – schroeder
    Jan 28, 2015 at 0:21
  • 3
    @KasperSouren are you just fishing for XP with these questions? Because the very documents you reference make it extremely clear just what this effects: your entire machine. Host resolution is basically on any deployed system, it's one of the pillars at the foundation of how networking functions.
    – user7933
    Jan 28, 2015 at 0:34
  • 3
    @digitalarchitect. I'm asking these questions because I can't easily find the answer. It's not clear to me if e.g. openssh or apache and other common services are using gethostbyname. I could fetch and grep the source code but that's not a very practical thing to do at this point. Also note that many systems do not yet have patches, so the answer to this question will help me decide: take down the entire system (not an option), just some services, or upgrade (not just some packages but MOST packages)...
    – the
    Jan 28, 2015 at 0:39
  • 1
    Oh and I could decide to switch to another package of which no version at all is not vulnerable based on some kind of list. All this would be a big pain to find out. While I should be sleeping.
    – the
    Jan 28, 2015 at 0:46
  • 2
    @KasperSouren I answered your question. You're panicking and that's never a solution. Relax. Run the command to update for whatever version of linux you're running, then reboot, and finally run the code in the answer to your other question to verify that the vulnerability is closed. There isn't a group of hackers pouncing on your servers actively trying to exploit this bug. It's okay, you're going to survive. :)
    – user7933
    Jan 28, 2015 at 1:07

1 Answer 1


One can reasonably conclude (see below) that it will require some detailed analysis to determine if an arbitrary software package is vulnerable, and what configuration or mitigations may apply. Any service which performs name resolution could be at risk (patch, and be safe!).

Qualys have already provided a list of software using the affected functions which they cannot exploit at this time:

apache, cups, dovecot, gnupg, isc-dhcp, lighttpd, mariadb/mysql, nfs-utils, nginx, nodejs, openldap, openssh, postfix, proftpd, pure-ftpd, rsyslog, samba, sendmail, sysklogd, syslog-ng, tcp_wrappers, vsftpd, xinetd.

Right now, only Exim is confirmed exploitable.

The CVE details site keeps track of vendor details for vulnerabilities, it's not up yet but it should appear shortly here fully complete yet, you can find it here: http://www.cvedetails.com/cve/CVE-2015-0235/ (see the recent Shellshock CVE-2014-7169 page for example). The oss-sec email list is a good way to keep track of breaking news.

The Qualys POC (GHOST.c) indicates only if the glibc is affected, what should accelerate the process is the upcoming promised Metasploit module from Qualys (though I suspect there will be others scrambling to develop modules).

(I don't buy the OpenSSH "mitigation" linked to, UseDNS causes a reverse look up of the IP address of the TCP connection, which of course cannot be sufficiently controlled by the attacker. I'll update this when I have a chance to verify the steps taken. Reverse DNS in OpenSSH or OpenSSH+libwrap is not exploitable.)

The original advisory is rather long, and the audience is expected to have a better than passing knowledge of libc and C programming. Much space is devoted to code and programs which are not vulnerable by way of explanation of the various complexities. The "publicity page" here is rather more digestible, and contains the nowadays obligatory vulnerability artwork.

Because of common programming idioms, and the very specific code paths to the vulnerable code, many programs are not vulnerable. To be clear, there is a problem affecting a handful of DNS related functions in glibc(<2.18), and DNS is an excellent way to get attacker controlled data into a system, though it's not a great way to get arbitrary data in. But, unlike some recent high profile issues, simply using the library or using those functions does not automatically make a program vulnerable.

That said, this is a newly publicised issue, other ways to trigger the issue may be found, there is no excuse to put off patching. The gethostbyname* functions in question are considered "obsolete" since they do not support IPv6 notations and have been replaced by functions that do, but they are very prevalent.

This non-trivial exploitation of the vulnerability is explained in detail in the advisory, take the example of the (not-exploitable) mount.nfs in §4.2 : a setuid-root binary on most distributions, so a good opportunity for local privilege escalation:

Similarly, mount.nfs (a SUID-root binary) is not vulnerable:

    if (inet_aton(hostname, &addr->sin_addr))
            return 0;
    if ((hp = gethostbyname(hostname)) == NULL) {
            nfs_error(_("%s: can't get address for %s\n"),
                            progname, hostname);
            return -1;

The above calling pattern of inet_aton() before trying gethostbyname() is the common idiom referred to above. Given an arbitrary string in hostname, first check to see if it can be treated as a valid IP dotted-quad via inet_aton() (cheap, and low-latency), otherwise see if it is a DNS host name via gethostbyname() (not cheap, and potentially high-latency. See section 3 - Mitigating factors of the advisory.

This is how OpenSSH uses those functions also, see the wrapper getaddrinfo() in openbsd-compat/fake-rfc25553.c. That function is only enabled at compile time if the host has no native getaddrinfo() (or you fudge configure to fool it). glibc has had that function since 1996 (pre v2.0), so gethostbyname() won't be called by OpenSSH.

If your OpenSSH is built with libwrap, then the sshd binary will have some symbol dependencies for gethostbyname* because of that — Qualys claim both TCP wrappers and OpenSSH are safe (for now). The only other use of gethostbyname() in OpenSSH is in HP-UX specific code where the X DISPLAY need contain an IP rather than a hostname, not relevant here.

In the general case, since conforming DNS data cannot contain problematic long/malformed IP addresses, reverse look up and forward/reverse checks are not an attack vector. Where hostnames/dotted-quad addresses are part of a higher protocol (e.g. the SMTP EHLO name, as used exploiting Exim) then you might have something. For OpenSSH this would suggest host names in port-forwarding. Close, but no cigar, even if OpenSSH did use gethostbyname() directly:

      if (strlen(host) >= NI_MAXHOST) {
            error("Forward host name too long.");
            return 0;

where NI_MAXHOST is 1025 in versions I've checked so far. This would be a less severe post-authentication attack vector in any case.


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .