Critical security flaw: glibc stack-based buffer overflow in getaddrinfo() (CVE-2015-7547)

The glibc package contains standard libraries which are used by multiple programs on the system. In order to save disk space and memory, as well as to make upgrading easier, common system code is kept in one place and shared between programs. This package contains the standard C library against which all GNU/Linux programs are linked. The libresolv library shipped with glibc provides functions which provide translation between host names and IP addresses. nss_dns is the glibc component which provides the Name Service Switch (NSS) service module which uses libresolv to perform DNS lookups.

Background

A stack-based buffer overflow was found in libresolv in the code which performs dual A/AAAA DNS queries. A remote attacker could create specially crafted DNS responses which could cause libresolv to crash or potentially execute code with the permissions of the user running the library. The buffer overflow occurs in the function send_dg (for UDP queries) and send_vc (for TCP queries) in libresolv. The issue is only exposed when libresolv is called from the nss_dns NSS service module. This flaw has been assigned CVE-2015-7547.

Applications which call getaddrinfo with the AF_UNSPEC address family are affected, except on Red Hat Enterprise Linux 6.4, where applications are also affected if they use the AF_INET6 address family. Applications which only use the old gethostbyname functions or libresolv functions such res_search (and not getaddrinfo) are not affected.

This issue did not affect the version of glibc shipped with Red Hat Enterprise Linux 5 or earlier. This issue affected the versions of glibc shipped with Red Hat Enterprise Linux 6 and 7.

Impact

This issue has been rated as having Critical impact by Red Hat Product Security.

Mitigation

In a default libresolv configuration, the UDP-based vector is mitigated by using a trusted, protocol-compliant DNS resolver on a trusted network. A compliant resolver will not produce the kind of oversized responses which are necessary to exploit this vulnerability because by default, the glibc resolver does not enable EDNS0 and does not request large responses.

The TCP-based vector could be mitigated by a trusted recursive resolver on a trusted network which limits the size of individual DNS responses to 1023 bytes and below. However, such a capability is not common in DNS resolver implementations because it breaks the DNS protocol. (The buffer size configuration option offered by most resolvers only applies to UDP, not TCP.) Rejecting AAAA responses, without also limiting the size of A responses, does not mitigate the vulnerability.

Disabling IPv6 support on affected systems does not mitigate the vulnerability because the dual A/AAAA lookups are performed even if the system lacks IPv6 support.

Affected Products and Resolution

All versions of the glibc package included with Red Hat Enterprise Linux 6 and 7 were affected by this flaw. See the table below for links to respective security advisories that fix this issue:

Resolution

After the update is applied you need to reboot the system or restart all affected services:

Because this vulnerability affects a large amount of applications on the system, the safest and recommended way to assure every application uses the updated glibc packages is to restart the system.

In case you are unable to restart the entire system after applying the update, execute the following command to list all running processes (not restricted to services) still using the old [in-memory] version of glibc on your system.

lsof +c0 -d DEL | awk 'NR==1 || /libc-/ {print $2,$1,$4,$NF}' | column -t

From the resulting list, identify the public-facing services and restart them. While this process may work as a temporary workaround, it is not supported by Red Hat and, should a problem arise, you will be requested to reboot the system before any troubleshooting begins.

FAQ

1. Does SELinux block this security flaw?
A suitable SELinux policy can contain some of the damage an attacker might do and constrain their access to the system, but DNS is used by many applications and system components, so SELinux policies offer only limited containment for this issue.

2. Can a trusted recursive DNS resolver protect against this issue?
A trusted recursive resolver, in a default, protocol-compliant configuration, cannot mitigate this issue because potential exploits could involve syntactically well-formed DNS responses. Restricting response sizes to to 1023 bytes can mitigate the issue if the network between the recursive resolver and clients using affected versions of glibc is trusted, and potential attackers cannot spoof the source address of the recursive resolver. The packet size restrictions have to be applied to the responses the recursive resolver generates, not the responses it receives from the Internet. Such packet size restrictions break some DNS-related services, including DNSSEC. Apart from the size aspect, there is no way for DNS recursors to detect and block attack traffic.

3. Is it sufficient to upgrade Internet-facing DNS servers and recursive resolvers?
No, the glibc packages on all hosts (both servers and clients) need to be updated.

4. TCP mode is not enabled in /etc/resolv.conf. Is the system still affected by this flaw?
The stub resolver will automatically switch to TCP if response sizes exceeds the UDP buffer size (which is 512 bytes by default). As a result, systems are exposed to the TCP-based vector even if TCP is not enabled explicitly.

5. Is it possible to avoid combined A/AAAA DNS lookups?
Some applications have options to switch from dual lookups (AF_UNSPEC) to IPv4 (AF_INET, A records) or IPv6 (AF_INET6, AAAA records) lookups only. Typically, the command line options are called -4 and -6. Such a mitigation would have to be applied on a per-application basis. Currently, there is no global switch to turn AF_UNSPEC lookups into A record or AAAA record lookups. The single-request and single-request-reopen options do not offer protection.

6. Is it possible to mitigate this attack via /etc/nsswitch.conf?
If the dns service modules is not listed in /etc/nsswitch.conf, a system is not exposed. However, it will not be possible to perform DNS lookups using the standard glibc name resolution functions. As a result, such a mitigation is rarely useful.

7. Can this vulnerability be mitigated by having a system contact trusted DNS servers only?
In theory, this is possible, but once a system is connected to the Internet, it is likely that it accidentally makes DNS queries using unexpected names, potentially obtaining data from untrusted DNS servers (through the configured recursive resolvers).

8. Are statically-linked binaries affected by this flaw?
Red Hat does not support static linking of glibc. However, if customers have built statically linked applications using the glibc-static package, these applications will still use the system copies of nss_dns and libresolv, and installing updated glibc packages will address the vulnerability.

Acknowledgments

The vulnerability was discovered by the Google Security Team and Red Hat.