linux-kernel - Re: [RFC PATCH 0/4] Allow tasks to have their user stack pointer sanity checked

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]

Date:   Mon, 11 Feb 2019 11:12:19 -0800
From:   Kees Cook <keescook@...omium.org>
To:     Will Deacon <will.deacon@....com>
Cc:     LKML <linux-kernel@...r.kernel.org>, Jann Horn <jannh@...gle.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Matthew Wilcox <willy@...radead.org>,
        Michal Hocko <mhocko@...e.com>,
        Peter Zijlstra <peterz@...radead.org>
Subject: Re: [RFC PATCH 0/4] Allow tasks to have their user stack pointer
 sanity checked

On Mon, Feb 11, 2019 at 9:59 AM Will Deacon <will.deacon@....com> wrote:
>
> Hi all,
>
> I attended an interesting talk at LCA last month that described some of the
> security features deployed in OpenBSD [1]. One hardening feature that piqued
> my interest was, on syscall entry and page faults from userspace, checking
> that the user stack pointer for a task points at pages that were either
> allocated by the kernel for the initial process stack of mapped with mmap()
> using the MAP_STACK flag. This acts as a basic defense against stack
> pivoting attacks.

I think this is nice to have, yes! Thanks for working on it. It seems
like this blocks pivots to heap -- relocating to a groomed stack area
would still be allowed. Regardless, this does narrow the scope of such
attacks quite nicely.

> The problem with this checking is that it is a retrospective tightening
> of the ABI, but that hasn't stopped me hacking it together behind a couple
> of prctl() options.

MAP_STACK has been around for a long time, so I think anything using
threads via glibc should be "covered". I would assume this would mean
that glibc could set the prctl() for such users. I suspect there are a
lot of open-coded threading implementations, though. It'd be
interesting to see how many need modification.

Given that this is behind a prctl(), it seems the CONFIG isn't needed?

> Anyway, it was fun to implement so I figured I'd post it as an RFC.

Thanks! I'd love to see an x86 counterpart to the sycall check too.

Did you trying bringing up a full userspace and windowing environment
with this enabled by default (i.e. forcing init to set the prctls)?
I'd be curious to see how much (if anything) goes boom. :)

Reviewed-by: Kees Cook <keescook@...omium.org>

-Kees

>
> Will
>
> [1] https://2019.linux.conf.au/schedule/presentation/164/
>
> Cc: Kees Cook <keescook@...omium.org>
> Cc: Jann Horn <jannh@...gle.com>
> Cc: Andrew Morton <akpm@...ux-foundation.org>
> Cc: Matthew Wilcox <willy@...radead.org>
> Cc: Michal Hocko <mhocko@...e.com>
> Cc: Peter Zijlstra <peterz@...radead.org>
>
> --->8
>
> Will Deacon (4):
>   mm: Check user stack pointer is mapped with MAP_STACK
>   mm: Expose user stack pointer checking via prctl()
>   mm: Add kconfig entries for user stack pointer checking
>   arm64: Check user stack pointer on syscall entry
>
>  arch/arm64/Kconfig          |  1 +
>  arch/arm64/kernel/syscall.c |  4 +++
>  include/linux/mm.h          | 15 +++++++++-
>  include/linux/mman.h        |  3 +-
>  include/linux/sched.h       |  4 +++
>  include/uapi/linux/prctl.h  |  5 ++++
>  kernel/sys.c                |  5 ++++
>  mm/Kconfig                  | 17 ++++++++++++
>  mm/memory.c                 | 67 +++++++++++++++++++++++++++++++++++++++++++++
>  9 files changed, 119 insertions(+), 2 deletions(-)
>
> --
> 2.11.0
>


-- 
Kees Cook