From: Kees Cook <firstname.lastname@example.org> To: "Perla, Enrico" <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: Wed, 20 Feb 2019 14:53:40 -0800 [thread overview] Message-ID: <CAGXu5j+833Rv5dnsNth522WGirAjysipPo2gecSX2HC5y-MkUg@mail.gmail.com> (raw) In-Reply-To: <CAGXu5jJSWf=CAij3_dxA9+n6+fWtt1MOT3dWD07vdkhrfC8bpQ@mail.gmail.com> On Wed, Feb 20, 2019 at 2:15 PM Kees Cook <email@example.com> wrote: > > On Tue, Feb 12, 2019 at 2:16 AM Perla, Enrico <firstname.lastname@example.org> wrote: > > I was somewhat fond of randomizing the pt_regs location, as that is something I could relate with in writing an exploit (handy way to load user controlled data to kernel at a known location). > > > > But, as Jann pointed out, that only has value in a ptrace-blocked sandbox, because the randomization offset can be leaked otherwise through ptrace PEEK/POKE and observing cache behavior. Worse, if ptrace is present, then the randomization is moot. > > > > Since containers seems to be going towards leaving ptrace open, I'm now wondering whether that is a good motivation at all and the proposed simplified version is not just better. > > 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. > > > That's all fair. What I struggle with is finding a precise motivation for the randomization (granted this might be extended to other KASLR cases, so perhaps is not a strong hard stop). > > > > The proposed randomization does fit the overall KASLR story and it does its job of not letting an attacker predict future stack offset from one leak, but in practical terms I'm struggling to find a case or two where this would have made a difference in an exploit. > > > > Can any of you think of some? > > As you know, exploits tend to be written using the > easiest-possible-path to attack, so prior to VMAP_STACK, thread_info > moving, and VLA removal, attacks would use those properties. However, > looking at something like half-nelson, an attack may just probe to > find the distance between stacks and using a confused index to jump > over guard pages, etc. But if that calculation is disrupted at every > syscall, reliability goes way down. (Which, BTW, is likely why stack > randomization might be better to do an syscall entry time so the > offset isn't calculated and left hanging around in memory to be > exposed via some other flaw before starting the next syscall.) BTW, the attack that inspired grsecurity's RANDKSTACK is described in these slides (lots of steps, see slide 79): https://www.slideshare.net/scovetta/stackjacking -- Kees Cook
next prev parent reply other threads:[~2019-02-20 22:53 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 [this message] 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 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+833Rv5dnsNth522WGirAjysipPo2gecSX2HC5y-MkUg@mail.gmail.com \ --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).