[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAGXu5j+833Rv5dnsNth522WGirAjysipPo2gecSX2HC5y-MkUg@mail.gmail.com>
Date: Wed, 20 Feb 2019 14:53:40 -0800
From: Kees Cook <keescook@...omium.org>
To: "Perla, Enrico" <enrico.perla@...el.com>
Cc: Andy Lutomirski <luto@...capital.net>, "Reshetova, Elena" <elena.reshetova@...el.com>,
Andy Lutomirski <luto@...nel.org>, Jann Horn <jannh@...gle.com>,
Peter Zijlstra <peterz@...radead.org>,
"kernel-hardening@...ts.openwall.com" <kernel-hardening@...ts.openwall.com>,
"tglx@...utronix.de" <tglx@...utronix.de>, "mingo@...hat.com" <mingo@...hat.com>, "bp@...en8.de" <bp@...en8.de>,
"tytso@....edu" <tytso@....edu>
Subject: Re: [RFC PATCH] x86/entry/64: randomize kernel stack offset upon
system call
On Wed, Feb 20, 2019 at 2:15 PM Kees Cook <keescook@...omium.org> wrote:
>
> On Tue, Feb 12, 2019 at 2:16 AM Perla, Enrico <enrico.perla@...el.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.)
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
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
