oss-sec mailing list archives
Re: CVE-2017-7184: kernel: Local privilege escalation in XFRM framework
From: Solar Designer <solar () openwall com>
Date: Sat, 1 Apr 2017 22:33:15 +0200
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/f843ee6dd019bcece3e74e76ad9df0155655d0dfRed 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
Current thread:
- Re: CVE-2017-7184: kernel: Local privilege escalation in XFRM framework Solar Designer (Apr 01)
- Re: CVE-2017-7184: kernel: Local privilege escalation in XFRM framework Solar Designer (Apr 01)
- Re: CVE-2017-7184: kernel: Local privilege escalation in XFRM framework Vladis Dronov (Apr 04)
- Re: CVE-2017-7184: kernel: Local privilege escalation in XFRM framework Solar Designer (Apr 01)