[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170401203314.GA12852@openwall.com>
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.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
