Bug 1293532 (CVE-2015-7547)
| Summary: | CVE-2015-7547 glibc: getaddrinfo stack-based buffer overflow | ||
|---|---|---|---|
| Product: | [Other] Security Response | Reporter: | Fabio Olive Leite <fleite> |
| Component: | vulnerability | Assignee: | Red Hat Product Security <security-response-team> |
| Status: | CLOSED ERRATA | QA Contact: | |
| Severity: | urgent | Docs Contact: | |
| Priority: | urgent | ||
| Version: | unspecified | CC: | alonbl, ashankar, bmcclain, btotty, cfergeau, codonell, dblechte, fche, fdeutsch, fleite, fweimer, gklein, gscott, hpc_rd, jgreguske, lsurette, mcermak, mgoldboi, michal.skrivanek, mnewsome, nagamatsu.h-bm, pfrankli, pmatouse, pstehlik, qguo, rbalakri, redhat-bugzilla, rh-spice-bugs, rik.theys, sardella, security-response-team, sherold, slawomir, upendra.gandhi, ycui, yeylon, ykaul, ylavi |
| Target Milestone: | --- | Keywords: | Security |
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: |
A stack-based buffer overflow was found in the way the libresolv library performed dual A/AAAA DNS queries. A remote attacker could create a specially crafted DNS response which could cause libresolv to crash or, potentially, execute code with the permissions of the user running the library. Note: this issue is only exposed when libresolv is called from the nss_dns NSS service module.
|
Story Points: | --- |
| Clone Of: | Environment: | ||
| Last Closed: | 2016-02-16 16:58:28 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | 1296028, 1296029, 1296030, 1296031, 1296069, 1296071, 1296073, 1296074, 1296076, 1308943, 1309629, 1309632, 1310202, 1310218, 1310219 | ||
| Bug Blocks: | 1293533 | ||
|
Description
Fabio Olive Leite
2015-12-22 04:36:25 UTC
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 |