[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sat, 1 Apr 2017 20:27:36 +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
Hi,
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
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.
