From: Kees Cook <email@example.com> To: "Perla, Enrico" <firstname.lastname@example.org> Cc: Andy Lutomirski <email@example.com>, "Reshetova, Elena" <firstname.lastname@example.org>, Andy Lutomirski <email@example.com>, Jann Horn <firstname.lastname@example.org>, Peter Zijlstra <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> Subject: Re: [RFC PATCH] x86/entry/64: randomize kernel stack offset upon system call Date: Thu, 21 Feb 2019 11:18:32 -0800 [thread overview] Message-ID: <CAGXu5j+=KSiRgi4HXd=vQLT1YkWcOS3NxwrczBedhcb+CFBfirstname.lastname@example.org> (raw) In-Reply-To: <5E269FBC3009974381A340959F3135C95C8FE928@hasmsx108.ger.corp.intel.com> On Thu, Feb 21, 2019 at 9:48 AM Perla, Enrico <email@example.com> wrote: > In many kernel exploits one needs to emulate structures (or provide some controlled data) to keep things stable, do a second stage, etc. > Old school approach was to dereference to userland. Now, with SMAP (or any other dereference protection), that cannot be done anymore. Oh, I see now: using the pt_regs storage as a place in kernel memory to have built the malicious structure. Got it. > If I have a stack address leak, then I have a pretty nice primitive through pt_regs to load some arbitrary content at a known address. > As discussed with Jan, if I have ptrace, randomization is basically moot. I can just PTRACE_SYSCALL and time my way to the correct location. > Actually, randomization could even help getting some needed alignment. Okay, I've chatted more with Jann off-list now; he's enlightened me with more examples. Thank you both for walking me through my denseness. :) > So the open questions are: > 1) are pt_regs considered enough of a vector to add the randomization nuisance? In most cases, to be able to locate pt_regs at a fixed location, you already need a stack address location leak. If you have such a leak, and pt_regs location is randomized, a second thread's pt_regs could be used, held with ptrace, and have prime+probe with PEEKs to figure out where the offset to pt_regs is. And the other thread would just use THAT pt_regs for its scratch space. So, while it'd be nice to randomize it, it seems that only when there are no other threads and no ptrace would it be useful (i.e. the sandbox situation, as you've said). > 2) is it worthwhile to randomize both pt_regs and the stack start location, so that ptrace doesn't leak at least the latter? Given the pile of prerequisites needed for these attacks, I would say "no" currently. In my assessment, I generally think a sandboxed environment will already have reduced attack surface, so whatever needed flaws may already be unavailable. These stack attacks tend to need a lot of pieces working together, so better to optimize this defense for the non-sandboxed case, in order to reduce the code's complexity. > I had mostly sandboxed scenarios in mind, I guess you had mostly the stackjacking case. > > Any variation on the above is ok, from not considering any of this worthwhile to doing just some - as long as the tradeoffs are clear (which is basically Elena's email), since randomization ends up being always a stopgap, not really a great defense. > > I don't have a strong opinion on any of this, especially since lots is happening to reduce/remove the leaking of kernel stack contents. I'm sufficiently convinced that with all the trade-offs, leaving pt_regs unrandomized is fine. If all we see is sandbox escapes using fixed-location pt_regs, well, then we can change this later. :) -- Kees Cook
next prev parent reply other threads:[~2019-02-21 19:18 UTC|newest] Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-02-08 12:15 [RFC PATCH] Early version of thread stack randomization Elena Reshetova 2019-02-08 12:15 ` [RFC PATCH] x86/entry/64: randomize kernel stack offset upon system call Elena Reshetova 2019-02-08 13:05 ` Peter Zijlstra 2019-02-08 13:20 ` Reshetova, Elena 2019-02-08 14:26 ` Peter Zijlstra 2019-02-09 11:13 ` Reshetova, Elena 2019-02-09 18:25 ` Andy Lutomirski 2019-02-11 6:39 ` Reshetova, Elena 2019-02-11 15:54 ` Andy Lutomirski 2019-02-12 10:16 ` Perla, Enrico 2019-02-14 7:52 ` Reshetova, Elena 2019-02-19 14:47 ` Jann Horn 2019-02-20 22:20 ` Kees Cook 2019-02-21 6:37 ` Andy Lutomirski 2019-02-21 13:20 ` Jann Horn 2019-02-21 15:49 ` Andy Lutomirski 2019-02-20 22:15 ` Kees Cook 2019-02-20 22:53 ` Kees Cook 2019-02-21 23:29 ` Kees Cook 2019-02-27 11:03 ` Reshetova, Elena 2019-02-21 9:35 ` Perla, Enrico 2019-02-21 17:23 ` Kees Cook 2019-02-21 17:48 ` Perla, Enrico 2019-02-21 19:18 ` Kees Cook [this message] 2019-02-20 21:51 ` Kees Cook 2019-02-08 15:15 ` Peter Zijlstra 2019-02-09 11:38 ` Reshetova, Elena 2019-02-09 12:09 ` Greg KH 2019-02-11 6:05 ` Reshetova, Elena 2019-02-08 16:34 ` Andy Lutomirski 2019-02-20 22:03 ` Kees Cook 2019-02-08 21:28 ` Kees Cook 2019-02-11 12:47 ` Reshetova, Elena 2019-02-20 22:04 ` 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='CAGXu5j+=KSiRgi4HXd=vQLT1YkWcOS3NxwrczBedhcb+CFBfirstname.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: [RFC PATCH] x86/entry/64: randomize kernel stack offset upon system call' \ /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).