Date: Tue, 12 Feb 2019 10:16:01 +0000 From: "Perla, Enrico" <enrico.perla@...el.com> To: Andy Lutomirski <luto@...capital.net>, "Reshetova, Elena" <elena.reshetova@...el.com> CC: 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>, "keescook@...omium.org" <keescook@...omium.org>, "tytso@....edu" <tytso@....edu> Subject: RE: [RFC PATCH] x86/entry/64: randomize kernel stack offset upon system call Hi, 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. > > If an attacker has write-what-where (i.e. can write controlled values to > controlled absolute virtual addresses), then I expect that pt_regs is a pretty > low ranking target. But it may be a fairly juicy target if you have a stack > buffer overflow that lets an attacker write to a controlled *offset* from the > stack. We used to keep thread_info at the bottom of the stack, and that was > a great attack target. > > But there’s an easier mitigation: just do regs->cs |= 3 or something like that > in the exit code. Then any such attack can only corrupt *user* state. The > performance impact would be *very* low, since this could go in the asm > path that’s only used for IRET to user mode. 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? - Enrico --------------------------------------------------------------------- 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.