Date: Sat, 1 Apr 2017 20:27:36 +0200 From: Solar Designer <solar@...nwall.com> To: oss-security@...ts.openwall.com Subject: Re: CVE-2017-7184: kernel: Local privilege escalation in XFRM framework Hi, I address this message primarily to Red Hat, but I'd like us to discuss it in public so that others can benefit from this information as well. On Wed, Mar 29, 2017 at 04:43:28PM -0500, Tyler Hicks wrote: > A security issue was reported by ZDI, on behalf of Chaitin Security > Research Lab, against the Linux kernel in Ubuntu. It also affected the > upstream kernel. > > Chaitin Security Research Lab discovered that xfrm_replay_verify_len(), > as called by xfrm_new_ae(), did not verify that the user-specified > replay_window was within the replay state buffer. > > This allowed for out-of-bounds reads and writes of kernel memory. > Chaitin Security showed that this can lead to local privilege escalation > by using user namespaces in order to configure XFRM. XFRM configuration > requires CAP_NET_ADMIN so this issue is mitigated in kernels which do > not enable user namespaces by default. > > Fixes: > - https://git.kernel.org/linus/677e806da4d916052585301785d847c3b3e6186a > - https://git.kernel.org/linus/f843ee6dd019bcece3e74e76ad9df0155655d0df Red Hat claims that all of RHEL5, RHEL6, and RHEL7 are affected, although the issue is mitigated by it requiring CAP_NET_ADMIN and/or unprivileged user namespaces, neither of which are available by default: https://access.redhat.com/security/cve/cve-2017-7184 RHEL7 does indeed contain the vulnerable upstream code, but RHEL5 and RHEL6 don't - at least not the same code that the commits referenced above patch. This leaves me with two other interpretations of Red Hat's analysis: 1. Similar issues existed for other inputs (not ESN) and were silently fixed some time between RHEL6 and RHEL7 (perhaps in equivalent upstream revisions). Maybe with the current renewed attention, Red Hat realized that older fixes were missed, which are now finally understood as security-relevant. The code does look to me like this may be the case, but I didn't spend much time on its analysis yet. -OR- 2. Red Hat's analysis is not correct, and RHEL5 and RHEL6 are not affected at all. Which is it, or something else I haven't thought of? While for RHEL itself this is almost a non-issue either way due to the mitigations mentioned above, better understanding is required for other distros where such mitigations might not fully apply (such as along with use of containers, where container root would have CAP_NET_ADMIN). And while I am at it, kudos to Red Hat for patching out unprivileged user namespaces in RHEL7! /* While user namespaces remain in tech preview disable them */ static bool enable_user_ns_creation; Alexander
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Powered by Openwall GNU/*/Linux - Powered by OpenVZ