From: Kees Cook <firstname.lastname@example.org> To: Jann Horn <email@example.com> Cc: Thomas Gleixner <firstname.lastname@example.org>, Elena Reshetova <email@example.com>, the arch/x86 maintainers <firstname.lastname@example.org>, Andy Lutomirski <email@example.com>, Peter Zijlstra <firstname.lastname@example.org>, Catalin Marinas <email@example.com>, Will Deacon <firstname.lastname@example.org>, Mark Rutland <email@example.com>, Alexander Potapenko <firstname.lastname@example.org>, Ard Biesheuvel <email@example.com>, Kernel Hardening <firstname.lastname@example.org>, email@example.com, Linux-MM <firstname.lastname@example.org>, kernel list <email@example.com> Subject: Re: [PATCH v2 0/5] Optionally randomize kernel stack offset each syscall Date: Tue, 24 Mar 2020 16:07:53 -0700 [thread overview] Message-ID: <202003241604.7269C810B@keescook> (raw) In-Reply-To: <CAG48ez3yYkMdxEEW6sJzBC5BZSbzEZKnpWzco32p-TJx7y_srg@mail.gmail.com> [-enrico, who is bouncing] On Tue, Mar 24, 2020 at 10:28:35PM +0100, Jann Horn wrote: > On Tue, Mar 24, 2020 at 9:32 PM Kees Cook <firstname.lastname@example.org> wrote: > > This is a continuation and refactoring of Elena's earlier effort to add > > kernel stack base offset randomization. In the time since the previous > > discussions, two attacks were made public that depended on stack > > determinism, so we're no longer in the position of "this is a good idea > > but we have no examples of attacks". :) > [...] > >  https://a13xp0p0v.github.io/2020/02/15/CVE-2019-18683.html > > This one only starts using the stack's location after having parsed > it out of dmesg (which in any environment that wants to provide a > reasonable level of security really ought to be restricted to root), > right? If you give people read access to dmesg, they can leak all > sorts of pointers; not just the stack pointer, but also whatever else > happens to be in the registers at that point - which is likely to give > the attacker more ways to place controlled data at a known location. > See e.g. <https://googleprojectzero.blogspot.com/2018/09/a-cache-invalidation-bug-in-linux.html>, > which leaks the pointer to a BPF map out of dmesg. It was mentioned that it would re-use the base across syscalls, so this defense would have frustrated it. More to my point was that there still are attacks using a deterministic stack as part of the exploit chain. We have a low-cost way to make that go away. > Also, are you sure that it isn't possible to make the syscall that > leaked its stack pointer never return to userspace (via ptrace or > SIGSTOP or something like that), and therefore never realign its > stack, while keeping some controlled data present on the syscall's > stack? > > >  https://repositorio-aberto.up.pt/bitstream/10216/125357/2/374717.pdf > > That's a moderately large document; which specific part are you referencing? IIRC, section 3.3 discusses using the stack for CFI bypass, though thinking about it again, it may have been targeting pt_regs. I'll double check and remove this reference if that's the case. But, as I mention, this is proactive and I'd like to stop yet more things from being able to depend on the stack location. -- Kees Cook
next prev parent reply other threads:[~2020-03-24 23:07 UTC|newest] Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-03-24 20:32 Kees Cook 2020-03-24 20:32 ` [PATCH v2 1/5] jump_label: Provide CONFIG-driven build state defaults Kees Cook 2020-03-24 22:06 ` Peter Zijlstra 2020-03-24 20:32 ` [PATCH v2 2/5] init_on_alloc: Unpessimize default-on builds Kees Cook 2020-03-26 15:48 ` Alexander Potapenko 2020-03-24 20:32 ` [PATCH v2 3/5] stack: Optionally randomize kernel stack offset each syscall Kees Cook 2020-03-30 11:25 ` Mark Rutland 2020-03-30 18:18 ` Kees Cook 2020-03-30 18:27 ` Kees Cook 2020-03-24 20:32 ` [PATCH v2 4/5] x86/entry: Enable random_kstack_offset support Kees Cook 2020-03-28 22:26 ` Kees Cook 2020-03-24 20:32 ` [PATCH v2 5/5] arm64: entry: " Kees Cook 2020-03-25 13:21 ` Mark Rutland 2020-03-25 20:22 ` Kees Cook 2020-03-26 11:15 ` Mark Rutland 2020-03-26 16:31 ` Kees Cook 2020-03-30 11:26 ` Mark Rutland 2020-04-20 20:54 ` Will Deacon 2020-04-20 22:34 ` Kees Cook 2020-04-21 7:02 ` Will Deacon 2020-03-24 21:28 ` [PATCH v2 0/5] Optionally randomize kernel stack offset each syscall Jann Horn 2020-03-24 23:07 ` Kees Cook [this message] 2020-03-25 12:15 ` Reshetova, Elena 2020-03-25 20:27 ` Kees Cook 2020-03-25 23:20 ` Jann Horn 2020-03-26 17:18 ` Kees Cook
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=202003241604.7269C810B@keescook \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --subject='Re: [PATCH v2 0/5] Optionally randomize kernel stack offset each syscall' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
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).