archive mirror
 help / color / mirror / Atom feed
From: Kees Cook <>
To: "Perla, Enrico" <>
Cc: Andy Lutomirski <>,
	"Reshetova, Elena" <>,
	Andy Lutomirski <>, Jann Horn <>,
	Peter Zijlstra <>,
	"" <>,
	"" <>,
	"" <>, "" <>
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: <> (raw)
In-Reply-To: <>

On Thu, Feb 21, 2019 at 9:48 AM Perla, Enrico <> 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

> 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

  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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='' \ \ \ \ \ \ \ \ \ \ \ \ \
    --subject='Re: [RFC PATCH] x86/entry/64: randomize kernel stack offset upon system call' \

* 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).