Bug 1423071 (CVE-2017-6074)
Summary: | CVE-2017-6074 kernel: use after free in dccp protocol | |||
---|---|---|---|---|
Product: | [Other] Security Response | Reporter: | Wade Mealing <wmealing> | |
Component: | vulnerability | Assignee: | Red Hat Product Security <security-response-team> | |
Status: | CLOSED ERRATA | QA Contact: | ||
Severity: | high | Docs Contact: | ||
Priority: | high | |||
Version: | unspecified | CC: | acme, agordeev, aquini, bhu, bmcclain, cperry, cye, dblechte, dedgar, dhoward, eedri, esammons, fche, fhrbata, fwestpha, gnaik, grocha, hannsj_uhl, hsowa, iboverma, jiji, jkacur, joelsmith, jross, kent, kernel-mgr, krsebi, lgoncalv, lsurette, lwang, matt, mcressma, mgoldboi, mguzik, michal.skrivanek, nmurray, pholasek, plougher, pmatouse, rbalakri, rkhan, rvrbovsk, sbonazzo, security-response-team, sherold, skontar, slawomir, sparks, srevivo, thomas.oulevey, vdronov, williams, ykaul, ylavi, yozone | |
Target Milestone: | --- | Keywords: | Security | |
Target Release: | --- | |||
Hardware: | All | |||
OS: | Linux | |||
Whiteboard: | ||||
Fixed In Version: | Doc Type: | Bug Fix | ||
Doc Text: |
A use-after-free flaw was found in the way the Linux kernel's Datagram Congestion Control Protocol (DCCP) implementation freed SKB (socket buffer) resources for a DCCP_PKT_REQUEST packet when the IPV6_RECVPKTINFO option is set on the socket. A local, unprivileged user could use this flaw to alter the kernel memory, allowing them to escalate their privileges on the system.
|
Story Points: | --- | |
Clone Of: | ||||
: | 1425406 (view as bug list) | Environment: | ||
Last Closed: | 2017-05-09 17:27:38 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: | 1423462, 1423463, 1423464, 1423465, 1423466, 1423467, 1424626, 1424628, 1424633, 1425260, 1425261, 1425262, 1425270, 1425358, 1425359, 1425360, 1425361, 1425362, 1425363, 1425364, 1425511, 1425822, 1425921, 1425924, 1427912 | |||
Bug Blocks: | 1423069 |
Description
Wade Mealing
2017-02-17 01:44:45 UTC
Mitigation: Recent versions of the SELinux policy can mitigate this flaw. The steps below will work with SELinux enabled or disabled. As the DCCP module will be auto-loaded when required, its use can be disabled by preventing the module from loading with the following instructions: # echo "install dccp /bin/true" >> /etc/modprobe.d/disable-dccp.conf The system will need to be restarted if the DCCP modules are loaded. In most circumstances, the DCCP kernel modules will be unable to be unloaded while any network interfaces are active and the protocol is in use. If you need further assistance, see KCS article https://access.redhat.com/solutions/41278 or contact Red Hat Global Support Services. Statement: This issue affects Red Hat Enterprise Linux 5, 6, 7, and Red Hat Enterprise MRG 2 kernels. As this issue is rated as Important, it has been scheduled to be fixed in a future version of Red Hat Enterprise Linux 5, 6, 7, and Red Hat Enterprise MRG 2 kernels. Acknowledgements: Name: Andrey Konovalov (Google) The following small systemtap script appears to work as a band-aid around this problem, by blocking the initial connect() call. It requires the appropriate kernel-debuginfo / kernel-devel installed, as aided by the stap-prep script. It's been tested on RHEL5 & Fedora25. # stap-prep [install stuff if needed] # cat > deccp.stp << 'EOF' probe module("dccp*").function("dccp_v?_connect") { $addr_len = 0; printf("%s[%d] DCCP socket connect denied\n", execname(), tid()) } probe begin { printf("DCCP band-aid active\n") } probe end,error { printf("DCCP band-aid shutdown\n") } EOF # stap -g deccp.stp DCCP band-aid active trigger[24951] DCCP socket connect denied trigger[24960] DCCP socket connect denied trigger[24969] DCCP socket connect denied trigger[24978] DCCP socket connect denied trigger[24987] DCCP socket connect denied ^CDCCP band-aid shutdown # This band-aid will not persist between system reboots or cancellation of the systemtap script. This was assigned CVE-2017-6074. *** Bug 1425406 has been marked as a duplicate of this bug. *** Created kernel tracking bugs for this issue: Affects: fedora-all [bug 1425822] Upstream patch: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=5edabca9d4cff7f1f2b68f0bac55ef99d9798ba4 Public announcement: http://www.openwall.com/lists/oss-security/2017/02/22/3 This issue has been addressed in the following products: Red Hat Enterprise Linux 7 Via RHSA-2017:0295 https://rhn.redhat.com/errata/RHSA-2017-0295.html This issue has been addressed in the following products: Red Hat Enterprise Linux 6 Via RHSA-2017:0293 https://rhn.redhat.com/errata/RHSA-2017-0293.html This issue has been addressed in the following products: Red Hat Enterprise Linux 7 Via RHSA-2017:0294 https://rhn.redhat.com/errata/RHSA-2017-0294.html External References: https://access.redhat.com/node/2934281 This issue has been addressed in the following products: Red Hat Enterprise Linux 6.7 Extended Update Support Via RHSA-2017:0316 https://rhn.redhat.com/errata/RHSA-2017-0316.html This issue has been addressed in the following products: Red Hat Enterprise Linux 6.6 Advanced Update Support Red Hat Enterprise Linux 6.6 Telco Extended Update Support Via RHSA-2017:0324 https://rhn.redhat.com/errata/RHSA-2017-0324.html This issue has been addressed in the following products: Red Hat Enterprise Linux 5 Via RHSA-2017:0323 https://rhn.redhat.com/errata/RHSA-2017-0323.html - IS IPV6 blocking a solution? # sysctl net.ipv6.conf.all.disable_ipv6=1 - ifconfig : IPv6 remove hello, krsebi, yes, disabling ipv6 mitigates the flaw as the problem connect() call cannot be made (despite socket(), listen() and setsockopt() still being successful): # sysctl -w net.ipv6.conf.all.disable_ipv6=1 # strace ./trigger ... socket(PF_INET6, SOCK_DCCP, IPPROTO_IP) = 3 bind(3, {sa_family=AF_INET6, sin6_port=htons(20002), inet_pton(AF_INET6, "::1", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, 32) = -1 EADDRNOTAVAIL (Cannot assign requested address) listen(3, 9) = 0 setsockopt(3, SOL_IPV6, 0x31 /* IPV6_??? */, [8], 4) = 0 socket(PF_INET6, SOCK_DCCP, IPPROTO_IP) = 4 connect(4, {sa_family=AF_INET6, sin6_port=htons(20002), inet_pton(AF_INET6, "::1", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, 32) = -1 ENETUNREACH (Network is unreachable) the reproducer rhel-7.3 system is crashing/locking-up with ipv6 enabled after running the reproducer, but stays up fine with net.ipv6.conf.all.disable_ipv6=1. Hello, Vladis Dronov, Thank you very much for your lending a helping hand. This issue has been addressed in the following products: Red Hat Enterprise Linux 6.4 Advanced Update Support Via RHSA-2017:0345 https://rhn.redhat.com/errata/RHSA-2017-0345.html This issue has been addressed in the following products: Red Hat Enterprise Linux 5.6 Long Life Via RHSA-2017:0347 https://rhn.redhat.com/errata/RHSA-2017-0347.html This issue has been addressed in the following products: Red Hat Enterprise Linux 5.9 Long Life Via RHSA-2017:0346 https://rhn.redhat.com/errata/RHSA-2017-0346.html This issue has been addressed in the following products: Red Hat Enterprise Linux 6.5 Advanced Update Support Red Hat Enterprise Linux 6.5 Telco Extended Update Support Via RHSA-2017:0366 https://rhn.redhat.com/errata/RHSA-2017-0366.html This issue has been addressed in the following products: Red Hat Enterprise Linux 6.2 Advanced Update Support Via RHSA-2017:0365 https://rhn.redhat.com/errata/RHSA-2017-0365.html This issue has been addressed in the following products: Red Hat Enterprise Linux 7.1 Extended Update Support Via RHSA-2017:0403 https://rhn.redhat.com/errata/RHSA-2017-0403.html This issue has been addressed in the following products: Red Hat Enterprise Linux 7.2 Extended Update Support Via RHSA-2017:0501 https://rhn.redhat.com/errata/RHSA-2017-0501.html This issue has been addressed in the following products: Red Hat Enterprise MRG 2 Via RHSA-2017:0932 https://access.redhat.com/errata/RHSA-2017:0932 This issue has been addressed in the following products: RHEV 3.X Hypervisor and Agents for RHEL-6 RHEV 3.X Hypervisor and Agents for RHEL-7 Via RHSA-2017:1209 https://access.redhat.com/errata/RHSA-2017:1209 |