A stack-based buffer overflow was found in libresolv when invoked from nss_dns, allowing specially crafted DNS responses to seize control of EIP in the DNS client. The buffer overflow occurs in the functions send_dg (send datagram) and send_vc (send TCP) for the NSS module libnss_dns.so.2 when calling getaddrinfo with AF_UNSPEC family, or in some cases AF_INET6 family. The use of AF_UNSPEC (or AF_INET6 in some cases) triggers the low-level resolver code to send out two parallel queries for A and AAAA. A mismanagement of the buffers used for those queries could result in the response of a query writing beyond the alloca allocated buffer created by __res_nquery.
Acknowledgements: This issue was discovered by the Google Security Team and Red Hat.
External References: https://access.redhat.com/articles/2161461
Public now via: https://sourceware.org/ml/libc-alpha/2016-02/msg00416.html The announcement links related upstream bug report investigation of which led to the discovery of this issue: https://sourceware.org/bugzilla/show_bug.cgi?id=18665
Created glibc tracking bugs for this issue: Affects: fedora-all [bug 1308943]
This issue has been addressed in the following products: Red Hat Enterprise Linux 6 Via RHSA-2016:0175 https://rhn.redhat.com/errata/RHSA-2016-0175.html
This issue has been addressed in the following products: Red Hat Enterprise Linux 6.6 EUS - Server and Compute Node Only Red Hat Enterprise Linux 6.2 AUS Red Hat Enterprise Linux 6.5 AUS - Server Only Red Hat Enterprise Linux 6.4 AUS - Server Only Red Hat Enterprise Linux 7.1 EUS - Server and Compute Node Only Via RHSA-2016:0225 https://rhn.redhat.com/errata/RHSA-2016-0225.html
This issue has been addressed in the following products: Red Hat Enterprise Linux 7 Via RHSA-2016:0176 https://rhn.redhat.com/errata/RHSA-2016-0176.html
Google's write-up of the issue: https://googleonlinesecurity.blogspot.com/2016/02/cve-2015-7547-glibc-getaddrinfo-stack.html
At some sites, a systemtap-based band-aid for this bug may be suitable as a temporary workaround. The following script interposes at an interior point in the stub resolver, redirecting T_UNSPEC to T_A queries. This corresponds to the "do not use AF_UNSPEC" mitigating factor from Carlos' email posting, which Florian and Carlos confirmed should also work for TCP. It requires systemtap of course, and debuginfo for the version(s) of glibc's libresolv.so. So on a Fedora machine, run "# debuginfo-install glibc", and repeat for the secondary architecture glibc if installed. (e.g., glibc-debuginfo*.i686 and glibc-debuginfo*.x86_64). Then, adjusting /lib*/ to the path or wildcard-path where libresolv may be found: # stap -g -e ' global T_UNSPEC = 62321 global T_A = 1 probe process("/lib*/libresolv.so.*").function("__libc_res_nquery") { if ($type == T_UNSPEC ) { $type = T_A } } ' will instantly, system-wide, quietly perform this single mitigation, as long as the systemtap script remains running. For example, but bug18665 test program runs to completion instead of suffering the SEGV. (Add stap -v or -t and/or printf() statements to trace the mitigation's operation.) Please test it carefully before deploying it seriously, and remember, it's meant only as a temporary band-aid, until a glibc update is fully deployed.
Statement: After updating the glibc package on affected systems, it is strongly recommended to reboot the system or restart all the affected services. For more information please refer to: https://access.redhat.com/articles/2161461
glibc-2.21-11.fc22 has been pushed to the Fedora 22 stable repository. If problems still persist, please make note of it in this bug report.
glibc-2.22-9.fc23 has been pushed to the Fedora 23 stable repository. If problems still persist, please make note of it in this bug report.
https://access.redhat.com/articles/2161461 only mentions RHEL 6 and 7, but what about RHEL 6 or 7 based products such as RHEV (especially RHEV-H)? From my point of view they should be affected as well, but it's not mentioned at any place so far. The last RHEV-H Image (for RHEV-M 3.5) is from 2016-01-13.
Robert, speaking purely generally, it can occur that products such as RHEV-H are assumed to operate in a different environment from a general purpose OS - for example where one where it never contacts untrusted data sources. So the severity of the same bug may be less, and its fix deferred.
Given GHOST (CVE-2015-0235) was addressed for RHEV-H it would be quite strange that this CVE is not relevant - while the issue is similar. I also filed case 01585853 on the Red Hat customer portal now to ensure that the fix makes it to RHEV-H, because they could consume on untrusted data sources such as DNS.
(In reply to Robert Scheck from comment #24) Hi Robert, we're working on the RHEV-H updates and will release them early next week. Thank you, Petr Matousek / Red Hat Product Security
This issue has been addressed in the following products: RHEV-H and Agents for RHEL-6 RHEV-H and Agents for RHEL-7 Via RHSA-2016:0277 https://rhn.redhat.com/errata/RHSA-2016-0277.html