Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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

Your e-mail address:

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Powered by Openwall GNU/*/Linux - Powered by OpenVZ