[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5E269FBC3009974381A340959F3135C95C8FE928@hasmsx108.ger.corp.intel.com>
Date: Thu, 21 Feb 2019 17:48:32 +0000
From: "Perla, Enrico" <enrico.perla@...el.com>
To: Kees Cook <keescook@...omium.org>
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
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:keescook@...omium.org]
> Sent: Thursday, February 21, 2019 6:24 PM
> 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; tglx@...utronix.de; mingo@...hat.com;
> bp@...en8.de; tytso@....edu
> 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 <enrico.perla@...el.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.
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.
