[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Wed, 15 Feb 2017 11:18:23 -0800
From: Kees Cook <keescook@...omium.org>
To: Mark Rutland <mark.rutland@....com>
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 Wed, Feb 15, 2017 at 2:45 AM, Mark Rutland <mark.rutland@....com> wrote:
> 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.
It looks like x86 is already ok (kind of by accident). ARM needs
fixing. I think it'd be best to model it after arm64's approach.
-Kees
--
Kees Cook
Pixel Security
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.
