Date: Tue, 23 Jun 2020 15:38:32 +0300 From: Alexander Popov <alex.popov@...ux.com> To: Kees Cook <keescook@...omium.org>, Thomas Gleixner <tglx@...utronix.de> Cc: Elena Reshetova <elena.reshetova@...el.com>, x86@...nel.org, Andy Lutomirski <luto@...nel.org>, Peter Zijlstra <peterz@...radead.org>, Catalin Marinas <catalin.marinas@....com>, Will Deacon <will@...nel.org>, Mark Rutland <mark.rutland@....com>, Alexander Potapenko <glider@...gle.com>, Ard Biesheuvel <ard.biesheuvel@...aro.org>, Jann Horn <jannh@...gle.com>, kernel-hardening@...ts.openwall.com, linux-arm-kernel@...ts.infradead.org, linux-mm@...ck.org, linux-kernel@...r.kernel.org Subject: Re: [PATCH v4 3/5] stack: Optionally randomize kernel stack offset each syscall On 22.06.2020 22:31, Kees Cook wrote: > As Linux kernel stack protections have been constantly improving > (vmap-based stack allocation with guard pages, removal of thread_info, > STACKLEAK), attackers have had to find new ways for their exploits > to work. They have done so, continuing to rely on the kernel's stack > determinism, in situations where VMAP_STACK and THREAD_INFO_IN_TASK_STRUCT > were not relevant. For example, the following recent attacks would have > been hampered if the stack offset was non-deterministic between syscalls: > > https://repositorio-aberto.up.pt/bitstream/10216/125357/2/374717.pdf > (page 70: targeting the pt_regs copy with linear stack overflow) > > https://a13xp0p0v.github.io/2020/02/15/CVE-2019-18683.html > (leaked stack address from one syscall as a target during next syscall) > > The main idea is that since the stack offset is randomized on each system > call, it is harder for an attack to reliably land in any particular place > on the thread stack, even with address exposures, as the stack base will > change on the next syscall. Also, since randomization is performed after > placing pt_regs, the ptrace-based approach to discover the randomized > offset during a long-running syscall should not be possible. Hello Kees! I would recommend to disable CONFIG_STACKLEAK_METRICS if kernel stack offset randomization is enabled. It is a debugging feature that provides information about kernel stack usage. That info can be useful for calculating the random offset. I would also recommend to check: there might be other kernel features for debugging or getting statistics that can be used to disclose the random stack offset. Best regards, Alexander
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.