Date: Sat, 1 Apr 2017 22:33:15 +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 On Sat, Apr 01, 2017 at 08:27:36PM +0200, Solar Designer wrote: > 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 Bugzilla, including the same statement in a comment, but without explanation on how this statement was arrived at: https://bugzilla.redhat.com/show_bug.cgi?id=1435153 > 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