Re: [RFC PATCH] x86/entry/64: randomize kernel stack offset upon system call

[Kees Cook <keescook@chromium.org>]

On Tue, Feb 12, 2019 at 2:16 AM Perla, Enrico <enrico.perla@intel.com> 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[1], 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.)

-- 
Kees Cook