Re: CVE-2017-7184: kernel: Local privilege escalation in XFRM framework

[Solar Designer <solar () openwall com>]

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