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 <>
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:
> > -
> > -
> 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:

Bugzilla, including the same statement in a comment, but without
explanation on how this statement was arrived at:

> 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;


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