Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752236AbdGGQvL (ORCPT ); Fri, 7 Jul 2017 12:51:11 -0400 Received: from mail-it0-f52.google.com ([209.85.214.52]:38363 "EHLO mail-it0-f52.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751100AbdGGQvJ (ORCPT ); Fri, 7 Jul 2017 12:51:09 -0400 MIME-Version: 1.0 In-Reply-To: References: <20170706002718.GA102852@beast>

<1499363602.26846.3.camel@redhat.com> From: Kees Cook Date: Fri, 7 Jul 2017 09:51:07 -0700 X-Google-Sender-Auth: ctCke8_6Zn7xmerDAhmgIAlrsBo Message-ID: Subject: Re: [PATCH v3] mm: Add SLUB free list pointer obfuscation To: Christoph Lameter Cc: Rik van Riel , 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 , 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 Content-Length: 2724 Lines: 62 On Fri, Jul 7, 2017 at 6:50 AM, Christoph Lameter wrote: > On Thu, 6 Jul 2017, Kees Cook wrote: > >> Right. This is about blocking the escalation of attack capability. For >> slab object overflow flaws, there are mainly two exploitation methods: >> adjacent allocated object overwrite and adjacent freed object >> overwrite (i.e. a freelist pointer overwrite). The first attack >> depends heavily on which slab cache (and therefore which structures) >> has been exposed by the bug. It's a very narrow and specific attack >> method. The freelist attack is entirely general purpose since it >> provides a reliable way to gain arbitrary write capabilities. >> Protecting against that attack greatly narrows the options for an >> attacker which makes attacks more expensive to create and possibly >> less reliable (and reliability is crucial to successful attacks). > > > The simplest thing here is to vary the location of the freelist pointer. > That way you cannot hit the freepointer in a deterministic way > > The freepointer is put at offset 0 right now. But you could put it > anywhere in the object. > > Index: linux/mm/slub.c > =================================================================== > --- linux.orig/mm/slub.c > +++ linux/mm/slub.c > @@ -3467,7 +3467,8 @@ static int calculate_sizes(struct kmem_c > */ > s->offset = size; > size += sizeof(void *); > - } > + } else > + s->offset = s->size / sizeof(void *) * > > #ifdef CONFIG_SLUB_DEBUG > if (flags & SLAB_STORE_USER) I wouldn't mind having both mitigations, but this alone is still open to spraying attacks. As long as an attacker's overflow can span an entire object, they can still hit the freelist pointer (which is especially true with small objects). With the XOR obfuscation they have to know where the pointer is stored (usually not available since they have only been able to arrange "next object is unallocated" without knowing _where_ it is allocated) and the random number (stored separately in the cache). If we also added a >0 offset, that would make things even less deterministic. Though I wonder if it would make the performance impact higher. The XOR patch right now is very light. Yet another option would be to moving the freelist pointer over by sizeof(void *) and adding a canary to be checked at offset 0, but that involves additional memory fetches and doesn't protect against a bad array index attack (rather than a linear overflow). So, I still think the XOR patch is the right first step. Would could further harden it, but I think it's the place to start. -Kees -- Kees Cook Pixel Security