From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752502AbdGFPss (ORCPT ); Thu, 6 Jul 2017 11:48:48 -0400 Received: from mail-it0-f45.google.com ([209.85.214.45]:36041 "EHLO mail-it0-f45.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751846AbdGFPsp (ORCPT ); Thu, 6 Jul 2017 11:48:45 -0400 MIME-Version: 1.0 In-Reply-To: References: <20170706002718.GA102852@beast> From: Kees Cook Date: Thu, 6 Jul 2017 08:48:43 -0700 X-Google-Sender-Auth: VZicuBh9uB3UXMKiyKBmnum-_eQ Message-ID: Subject: Re: [PATCH v3] mm: Add SLUB free list pointer obfuscation To: Christoph Lameter Cc: Andrew Morton , Pekka Enberg , David Rientjes , Joonsoo Kim , "Paul E. McKenney" , Ingo Molnar , Josh Triplett , Andy Lutomirski , Nicolas Pitre , Tejun Heo , Daniel Mack , Sebastian Andrzej Siewior , Sergey Senozhatsky , Helge Deller , Rik van Riel , Linux-MM , Tycho Andersen , LKML , "kernel-hardening@lists.openwall.com" Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Jul 6, 2017 at 6:43 AM, Christoph Lameter wrote: > On Wed, 5 Jul 2017, Kees Cook wrote: > >> @@ -3536,6 +3565,9 @@ static int kmem_cache_open(struct kmem_cache *s, unsigned long flags) >> { >> s->flags = kmem_cache_flags(s->size, flags, s->name, s->ctor); >> s->reserved = 0; >> +#ifdef CONFIG_SLAB_FREELIST_HARDENED >> + s->random = get_random_long(); >> +#endif >> >> if (need_reserve_slab_rcu && (s->flags & SLAB_TYPESAFE_BY_RCU)) >> s->reserved = sizeof(struct rcu_head); >> > > So if an attacker knows the internal structure of data then he can simply > dereference page->kmem_cache->random to decode the freepointer. That requires a series of arbitrary reads. This is protecting against attacks that use an adjacent slab object write overflow to write the freelist pointer. This internal structure is very reliable, and has been the basis of freelist attacks against the kernel for a decade. > Assuming someone is already targeting a freelist pointer (which indicates > detailed knowledge of the internal structure) then I would think that > someone like that will also figure out how to follow the pointer links to > get to the random value. The kind of hardening this provides is to frustrate the expansion of an attacker's capabilities. Most attacks are a chain of exploits that slowly builds up the ability to perform arbitrary writes. For example, a slab object overflow isn't an arbitrary write on its own, but when combined with heap allocation layout control and an adjacent free object, this can be upgraded to an arbitrary write. > Not seeing the point of all of this. It is a probabilistic defense, but then so is the stack protector. This is a similar defense; while not perfect it makes the class of attack much more difficult to mount. -Kees -- Kees Cook Pixel Security