From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 References: <1549628149-11881-1-git-send-email-elena.reshetova@intel.com> <1549628149-11881-2-git-send-email-elena.reshetova@intel.com> <20190208130544.GI32511@hirez.programming.kicks-ass.net> <2236FBA76BA1254E88B949DDB74E612BA4BB7580@IRSMSX102.ger.corp.intel.com> <20190208142642.GJ32511@hirez.programming.kicks-ass.net> <2236FBA76BA1254E88B949DDB74E612BA4BB96C5@IRSMSX102.ger.corp.intel.com> <2236FBA76BA1254E88B949DDB74E612BA4BBA73C@IRSMSX102.ger.corp.intel.com> <5E269FBC3009974381A340959F3135C95C8F78E5@hasmsx108.ger.corp.intel.com> In-Reply-To: From: Kees Cook Date: Wed, 20 Feb 2019 14:53:40 -0800 Message-ID: Subject: Re: [RFC PATCH] x86/entry/64: randomize kernel stack offset upon system call Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable To: "Perla, Enrico" Cc: Andy Lutomirski , "Reshetova, Elena" , Andy Lutomirski , Jann Horn , Peter Zijlstra , "kernel-hardening@lists.openwall.com" , "tglx@linutronix.de" , "mingo@redhat.com" , "bp@alien8.de" , "tytso@mit.edu" List-ID: On Wed, Feb 20, 2019 at 2:15 PM Kees Cook wrote: > > On Tue, Feb 12, 2019 at 2:16 AM Perla, Enrico wr= ote: > > I was somewhat fond of randomizing the pt_regs location, as that is s= omething 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 sandb= ox, 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 simpli= fied 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 f= or 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 le= ak, 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 --=20 Kees Cook