linux-kernel - Re: [kernel-hardening] [PATCH] lib: harden strncpy_from

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAOp4FwS+AdOMLO-az85D7fF79Aq9W0Aig7sT=McCzy2w9Kv3eg@mail.gmail.com>
Date:   Mon, 17 Oct 2016 17:06:25 +0400
From:   Loganaden Velvindron <loganaden@...il.com>
To:     kernel-hardening@...ts.openwall.com
Cc:     Kees Cook <keescook@...omium.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [kernel-hardening] [PATCH] lib: harden strncpy_from_user

On Mon, Oct 17, 2016 at 5:04 PM, Mark Rutland <mark.rutland@....com> wrote:
> On Fri, Aug 26, 2016 at 02:57:58PM -0400, Kees Cook wrote:
>> On Fri, Aug 26, 2016 at 10:31 AM, Mark Rutland <mark.rutland@....com> wrote:
>> > The strncpy_from_user() accessor is effectively a copy_from_user()
>> > specialised to copy strings, terminating early at a NUL byte if
>> > possible. In other respects it is identical, and can be used to copy an
>> > arbitrarily large buffer from userspace into the kernel. Conceptually,
>> > it exposes a similar attack surface.
>> >
>> > As with copy_from_user(), we check the destination range when the kernel
>> > is built with KASAN, but unlike copy_from_user() we do not check the
>> > destination buffer when using HARDENED_USERCOPY. As strncpy_from_user()
>> > calls get_user() in a loop, we must call check_object_size() explicitly.
>> >
>> > This patch adds this instrumentation to strncpy_from_user(), per the
>> > same rationale as with the regular copy_from_user(). In the absence of
>> > hardened usercopy this will have no impact as the instrumentation
>> > expands to an empty static inline function.
>
> [...]
>
>> Ah, yes, good catch! (And to repeat what you mentioned to me in
>> passing in the hall: there appear to be other users of get_user() in a
>> loop in other places in the kernel that will likely need some
>> attention too.)
>
> I was reminded of this as it just hit mainline; is it worth dropping a
> TODO on the KSPP wiki? I suspect I won't have the time to delve much
> further into this in the near term, and it might be a good intro task
> for someone.
>
> Thanks,
> Mark.

Yes. I believe that it is.