[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 15 Feb 2017 10:45:03 +0000
From: Mark Rutland <mark.rutland@....com>
To: Kees Cook <keescook@...omium.org>
CC: Hoeun Ryu <hoeun.ryu@...il.com>, LKML <linux-kernel@...r.kernel.org>,
"kernel-hardening@...ts.openwall.com" <kernel-hardening@...ts.openwall.com>,
<nd@....com>
Subject: Re: [PATCH] usercopy: add testcases to check zeroing on failure of
usercopy
On Tue, Feb 14, 2017 at 12:36:48PM -0800, Kees Cook wrote:
> On Mon, Feb 13, 2017 at 5:44 PM, Hoeun Ryu <hoeun.ryu@...il.com> wrote:
> >> On Feb 14, 2017, at 4:24 AM, Kees Cook <keescook@...omium.org> wrote:
> >>> On Mon, Feb 13, 2017 at 10:33 AM, Kees Cook <keescook@...omium.org> wrote:
> >>>> On Sat, Feb 11, 2017 at 10:13 PM, Hoeun Ryu <hoeun.ryu@...il.com> wrote:
> >>>> @@ -69,25 +76,35 @@ static int __init test_user_copy_init(void)
> >>>> "legitimate put_user failed");
> >>>>
> >>>> /* Invalid usage: none of these should succeed. */
> >>>> + memset(kmem, 0x5A, PAGE_SIZE);
> >>>> ret |= test(!copy_from_user(kmem, (char __user *)(kmem + PAGE_SIZE),
> >>>> PAGE_SIZE),
> >>>> "illegal all-kernel copy_from_user passed");
> >>>> + ret |= test(memcmp(zerokmem, kmem, PAGE_SIZE),
> >>>> + "zeroing failure for illegal all-kernel copy_from_user");
> >>>> + memset(bad_usermem, 0x5A, PAGE_SIZE);
> >>>
> >>> Oh, actually, ha-ha: this isn't legal: it's a direct copy from kernel
> >>> to userspace. :) This needs a copy_to_user()... (and same for the
> >>> memcmp...)
> >
> > I just came up with that usercopy doesn't check the buffer is valid
> > when zeroing happens. I mean if the buffer is wrong address pointing
> > other kernel objects or user space address, is it possible for
> > zeroing to overwrite the address ?
>
> The overwrite happening even when the address is "wrong" seems like a
> bug to me, but it's sort of already too late (a bad kernel address
> would have already been a target for a userspace copy), but if
> something has gone really wrong (i.e. attacker doesn't have control
> over the source buffer) this does give a "write 0" primitive.
>
> Mark Rutland noticed some order-of-operations issues here too, and his
> solution is pretty straight forward: move the checks outside the
> failure path. If the kernel target is demonstrably bad, then the
> process will be killed before the write 0 happens. (In the non-const
> case at least...)
>
> (Oh, btw, I just noticed that x86's copy_from_user() already does the
> check before _copy_from_user() can do the memset, so x86 is already
> "ok" in this regard.)
FWIW, the patch making arm64 do the check first is queued [1], and
should be in v4.11.
Doing the same for other architectures would be good.
Mark.
[1] https://git.kernel.org/cgit/linux/kernel/git/arm64/linux.git/commit/?h=for-next/core&id=76624175dcae6f7a808d345c0592908a15ca6975
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
