Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Tue, 4 Apr 2017 08:05:19 -0400 (EDT)
From: Vladis Dronov <vdronov@...hat.com>
To: Solar Designer <solar@...nwall.com>
Cc: oss-security@...ts.openwall.com
Subject: Re: CVE-2017-7184: kernel: Local privilege
 escalation in XFRM framework

Hello, Alexander,

Indeed you are right, RHEL-5,6 are invulnerable to this XFRM bug.

This was an incorrect analysis on our side. Thank you much for
raising this. We are changing the vulnerability statement in this
bugzilla bz1435153 and in the CVE description.

As for unprivileged user namespaces, they were considered too
insecure up to and including RHEL-7.3 to be enabled by default.
There are plans to enable them (by sysctl parameter) in RHEL-7.4.

Best regards,
Vladis Dronov | Red Hat, Inc. | Product Security Engineer

----- Original Message -----
From: "Solar Designer" <solar@...nwall.com>
To: oss-security@...ts.openwall.com
Sent: Saturday, April 1, 2017 10:33:15 PM
Subject: Re: [oss-security] 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