From: "Perla, Enrico" <firstname.lastname@example.org> To: Kees Cook <email@example.com> Cc: Andy Lutomirski <firstname.lastname@example.org>, "Reshetova, Elena" <email@example.com>, Andy Lutomirski <firstname.lastname@example.org>, Jann Horn <email@example.com>, Peter Zijlstra <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 Date: Thu, 21 Feb 2019 17:48:32 +0000 [thread overview] Message-ID: <5E269FBC3009974381A340959F3135C95C8FE928@hasmsx108.ger.corp.intel.com> (raw) In-Reply-To: <CAGXu5jJoODVOd8Bt+eMRPGvm=ZZNBHVmGE8LBsgMk6K=1Dv-cQ@mail.gmail.com> 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. 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. So the open questions are: 1) are pt_regs considered enough of a vector to add the randomization nuisance? 2) is it worthwhile to randomize both pt_regs and the stack start location, so that ptrace doesn't leak at least the latter? 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. - Enrico > -----Original Message----- > From: Kees Cook [mailto:email@example.com] > Sent: Thursday, February 21, 2019 6:24 PM > 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>; kernel- > 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 > > On Thu, Feb 21, 2019 at 1:35 AM Perla, Enrico <email@example.com> > wrote: > > > It does seem that using a flaw to attack one's own registers is > > > rather pointless. Maybe we'll eat our words, but for now, I'd agree. > > > > > > > You don't attack your own registers, you use them to load controlled data > to the kernel and emulate structures or similar at any stage of an exploit, > bypassing SMAP and co. > > Given all the rewriting of the syscall entry code over the last few years, > perhaps I'm missing something. My understanding was that at syscall entry > we do effectively this: > > - save pt_regs > - clear all registers not needed for a syscall > - run syscall > - restore pt_regs (excepting syscall return value) > > I didn't think pt_regs got used during the syscall? In looking more closely, I > see some current_pt_regs() in some paths, but again: what's the attack > you're thinking of that isn't directly overlapped with existing control over > registers at entry or via ptrace? > > -- > Kees Cook --------------------------------------------------------------------- INTEL CORPORATION ITALIA S.p.A. con unico socio Sede: Milanofiori Palazzo E 4 CAP 20094 Assago (MI) Capitale Sociale Euro 104.000,00 interamente versato Partita I.V.A. e Codice Fiscale 04236760155 Repertorio Economico Amministrativo n. 997124 Registro delle Imprese di Milano nr. 183983/5281/33 Soggetta ad attivita' di direzione e coordinamento di INTEL CORPORATION, USA This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.
next prev parent reply other threads:[~2019-02-21 17:48 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 [this message] 2019-02-21 19:18 ` Kees Cook 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=5E269FBC3009974381A340959F3135C95C8FE928@hasmsx108.ger.corp.intel.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 \ --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).