linux-kernel - Re: [PATCH] usercopy: add testcases to check zeroing on failure of usercopy

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAGXu5j+-ad5AwJ3sQbud3LsrpB_4-duvfF5kUGKjpY+5gmzJtw@mail.gmail.com>
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