Re: [kernel-hardening] [PATCH] lib: harden strncpy_from_user
On Mon, Oct 17, 2016 at 6:04 AM, Mark Rutlandwrote: > On Fri, Aug 26, 2016 at 02:57:58PM -0400, Kees Cook wrote: >> On Fri, Aug 26, 2016 at 10:31 AM, Mark Rutland 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
Re: [kernel-hardening] [PATCH] lib: harden strncpy_from_user
On Mon, Oct 17, 2016 at 6:04 AM, Mark Rutland 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 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
Re: [kernel-hardening] [PATCH] lib: harden strncpy_from_user
On Mon, Oct 17, 2016 at 5:04 PM, Mark Rutlandwrote: > On Fri, Aug 26, 2016 at 02:57:58PM -0400, Kees Cook wrote: >> On Fri, Aug 26, 2016 at 10:31 AM, Mark Rutland 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.
Re: [kernel-hardening] [PATCH] lib: harden strncpy_from_user
On Mon, Oct 17, 2016 at 5:04 PM, Mark Rutland 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 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.
Re: [kernel-hardening] [PATCH] lib: harden strncpy_from_user
On Fri, Aug 26, 2016 at 02:57:58PM -0400, Kees Cook wrote: > On Fri, Aug 26, 2016 at 10:31 AM, Mark Rutlandwrote: > > 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.
Re: [kernel-hardening] [PATCH] lib: harden strncpy_from_user
On Fri, Aug 26, 2016 at 02:57:58PM -0400, Kees Cook wrote: > On Fri, Aug 26, 2016 at 10:31 AM, Mark Rutland 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.
Re: [kernel-hardening] [PATCH] lib: harden strncpy_from_user
On Fri, Aug 26, 2016 at 10:31 AM, Mark Rutlandwrote: > 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 > Cc: Andrew Morton > Cc: Kees Cook > --- > 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 > #include > #include > +#include > #include > #include > #include > @@ -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
Re: [kernel-hardening] [PATCH] lib: harden strncpy_from_user
On Fri, Aug 26, 2016 at 10:31 AM, Mark Rutland 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 > Cc: Andrew Morton > Cc: Kees Cook > --- > 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 > #include > #include > +#include > #include > #include > #include > @@ -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