* [PATCH] lib: harden strncpy_from_user
@ 2016-08-26 14:31 Mark Rutland
2016-08-26 18:57 ` [kernel-hardening] " Kees Cook
0 siblings, 1 reply; 5+ messages in thread
From: Mark Rutland @ 2016-08-26 14:31 UTC (permalink / raw)
To: linux-kernel, kernel-hardening; +Cc: Mark Rutland, Andrew Morton, Kees Cook
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.
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Kees Cook <keescook@chromium.org>
---
lib/strncpy_from_user.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/lib/strncpy_from_user.c b/lib/strncpy_from_user.c
index 9c5fe81..7e35fc4 100644
--- a/lib/strncpy_from_user.c
+++ b/lib/strncpy_from_user.c
@@ -1,6 +1,7 @@
#include <linux/compiler.h>
#include <linux/export.h>
#include <linux/kasan-checks.h>
+#include <linux/thread_info.h>
#include <linux/uaccess.h>
#include <linux/kernel.h>
#include <linux/errno.h>
@@ -111,6 +112,7 @@ long strncpy_from_user(char *dst, const char __user *src, long count)
long retval;
kasan_check_write(dst, count);
+ check_object_size(dst, count, false);
user_access_begin();
retval = do_strncpy_from_user(dst, src, count, max);
user_access_end();
--
2.7.4
^ permalink raw reply related [flat|nested] 5+ messages in thread
* Re: [kernel-hardening] [PATCH] lib: harden strncpy_from_user
2016-08-26 14:31 [PATCH] lib: harden strncpy_from_user Mark Rutland
@ 2016-08-26 18:57 ` Kees Cook
2016-10-17 13:04 ` Mark Rutland
0 siblings, 1 reply; 5+ messages in thread
From: Kees Cook @ 2016-08-26 18:57 UTC (permalink / raw)
To: kernel-hardening; +Cc: LKML, Mark Rutland, Andrew Morton
On Fri, Aug 26, 2016 at 10:31 AM, Mark Rutland <mark.rutland@arm.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.
>
> Signed-off-by: Mark Rutland <mark.rutland@arm.com>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: Kees Cook <keescook@chromium.org>
> ---
> lib/strncpy_from_user.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/lib/strncpy_from_user.c b/lib/strncpy_from_user.c
> index 9c5fe81..7e35fc4 100644
> --- a/lib/strncpy_from_user.c
> +++ b/lib/strncpy_from_user.c
> @@ -1,6 +1,7 @@
> #include <linux/compiler.h>
> #include <linux/export.h>
> #include <linux/kasan-checks.h>
> +#include <linux/thread_info.h>
> #include <linux/uaccess.h>
> #include <linux/kernel.h>
> #include <linux/errno.h>
> @@ -111,6 +112,7 @@ long strncpy_from_user(char *dst, const char __user *src, long count)
> long retval;
>
> kasan_check_write(dst, count);
> + check_object_size(dst, count, false);
> user_access_begin();
> retval = do_strncpy_from_user(dst, src, count, max);
> user_access_end();
> --
> 2.7.4
>
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'll get this into the hardened usercopy tree when I get back from the
Security Summit. This will likely need to grow knowledge about
builtin-const "count" arguments like we need to the architectures that
are missing them in the copy_*_user calls.
Thanks!
-Kees
--
Kees Cook
Nexus Security
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [kernel-hardening] [PATCH] lib: harden strncpy_from_user
2016-08-26 18:57 ` [kernel-hardening] " Kees Cook
@ 2016-10-17 13:04 ` Mark Rutland
2016-10-17 13:06 ` Loganaden Velvindron
2016-10-18 20:49 ` Kees Cook
0 siblings, 2 replies; 5+ messages in thread
From: Mark Rutland @ 2016-10-17 13:04 UTC (permalink / raw)
To: Kees Cook; +Cc: kernel-hardening, LKML, Andrew Morton
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@arm.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.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [kernel-hardening] [PATCH] lib: harden strncpy_from_user
2016-10-17 13:04 ` Mark Rutland
@ 2016-10-17 13:06 ` Loganaden Velvindron
2016-10-18 20:49 ` Kees Cook
1 sibling, 0 replies; 5+ messages in thread
From: Loganaden Velvindron @ 2016-10-17 13:06 UTC (permalink / raw)
To: kernel-hardening; +Cc: Kees Cook, LKML, Andrew Morton
On Mon, Oct 17, 2016 at 5:04 PM, Mark Rutland <mark.rutland@arm.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@arm.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.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [kernel-hardening] [PATCH] lib: harden strncpy_from_user
2016-10-17 13:04 ` Mark Rutland
2016-10-17 13:06 ` Loganaden Velvindron
@ 2016-10-18 20:49 ` Kees Cook
1 sibling, 0 replies; 5+ messages in thread
From: Kees Cook @ 2016-10-18 20:49 UTC (permalink / raw)
To: Mark Rutland; +Cc: kernel-hardening, LKML, Andrew Morton
On Mon, Oct 17, 2016 at 6:04 AM, Mark Rutland <mark.rutland@arm.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@arm.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.
Ah, right. I've updated the kernserc TODO list with this (recently the
csum_* routines were pointed out), and added a bunch more TODOs that
were in my notes.
-Kees
--
Kees Cook
Nexus Security
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2016-10-18 20:49 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-08-26 14:31 [PATCH] lib: harden strncpy_from_user Mark Rutland
2016-08-26 18:57 ` [kernel-hardening] " Kees Cook
2016-10-17 13:04 ` Mark Rutland
2016-10-17 13:06 ` Loganaden Velvindron
2016-10-18 20:49 ` Kees Cook
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).