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.
