From: Rik van Riel <riel@redhat.com> To: Christoph Lameter <cl@linux.com>, Kees Cook <keescook@chromium.org> Cc: Andrew Morton <akpm@linux-foundation.org>, Pekka Enberg <penberg@kernel.org>, David Rientjes <rientjes@google.com>, Joonsoo Kim <iamjoonsoo.kim@lge.com>, "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>, Ingo Molnar <mingo@kernel.org>, Josh Triplett <josh@joshtriplett.org>, Andy Lutomirski <luto@kernel.org>, Nicolas Pitre <nicolas.pitre@linaro.org>, Tejun Heo <tj@kernel.org>, Daniel Mack <daniel@zonque.org>, Sebastian Andrzej Siewior <bigeasy@linutronix.de>, Sergey Senozhatsky <sergey.senozhatsky@gmail.com>, Helge Deller <deller@gmx.de>, Linux-MM <linux-mm@kvack.org>, Tycho Andersen <tycho@docker.com>, LKML <linux-kernel@vger.kernel.org>, "kernel-hardening@lists.openwall.com" <kernel-hardening@lists.openwall.com> Subject: Re: [PATCH v3] mm: Add SLUB free list pointer obfuscation Date: Thu, 06 Jul 2017 13:53:22 -0400 [thread overview] Message-ID: <1499363602.26846.3.camel@redhat.com> (raw) In-Reply-To: <alpine.DEB.2.20.1707061052380.26079@east.gentwo.org> [-- Attachment #1: Type: text/plain, Size: 2701 bytes --] On Thu, 2017-07-06 at 10:55 -0500, Christoph Lameter wrote: > On Thu, 6 Jul 2017, Kees Cook wrote: > > > On Thu, Jul 6, 2017 at 6:43 AM, Christoph Lameter <cl@linux.com> > > 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. > > These reads are not arbitrary. You can usually calculate the page > struct > address easily from the address and then do a couple of loads to get > there. > > Ok so you get rid of the old attacks because we did not have that > hardening in effect when they designed their approaches? The hardening protects against situations where people do not have arbitrary code execution and memory read access in the kernel, with the goal of protecting people from acquiring those abilities. > > 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. > > Na I am not convinced of the "much more difficult". Maybe they will > just > have to upgrade their approaches to fetch the proper values to > decode. Easier said than done. Most of the time there is an unpatched vulnerability outstanding, there is only one known issue, before the kernel is updated by the user, to a version that does not have that issue. Bypassing kernel hardening typically requires the use of multiple vulnerabilities, and the absence of roadblocks (like hardening) that make a type of vulnerability exploitable. Between usercopy hardening, and these slub freelist canaries (which is what they effectively are), several classes of exploits are no longer usable. -- All rights reversed [-- Attachment #2: This is a digitally signed message part --] [-- Type: application/pgp-signature, Size: 473 bytes --]
WARNING: multiple messages have this Message-ID (diff)
From: Rik van Riel <riel@redhat.com> To: Christoph Lameter <cl@linux.com>, Kees Cook <keescook@chromium.org> Cc: Andrew Morton <akpm@linux-foundation.org>, Pekka Enberg <penberg@kernel.org>, David Rientjes <rientjes@google.com>, Joonsoo Kim <iamjoonsoo.kim@lge.com>, "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>, Ingo Molnar <mingo@kernel.org>, Josh Triplett <josh@joshtriplett.org>, Andy Lutomirski <luto@kernel.org>, Nicolas Pitre <nicolas.pitre@linaro.org>, Tejun Heo <tj@kernel.org>, Daniel Mack <daniel@zonque.org>, Sebastian Andrzej Siewior <bigeasy@linutronix.de>, Sergey Senozhatsky <sergey.senozhatsky@gmail.com>, Helge Deller <deller@gmx.de>, Linux-MM <linux-mm@kvack.org>, Tycho Andersen <tycho@docker.com>, LKML <linux-kernel@vger.kernel.org>, "kernel-hardening@lists.openwall.com" <kernel-hardening@lists.openwall.com> Subject: [kernel-hardening] Re: [PATCH v3] mm: Add SLUB free list pointer obfuscation Date: Thu, 06 Jul 2017 13:53:22 -0400 [thread overview] Message-ID: <1499363602.26846.3.camel@redhat.com> (raw) In-Reply-To: <alpine.DEB.2.20.1707061052380.26079@east.gentwo.org> [-- Attachment #1: Type: text/plain, Size: 2701 bytes --] On Thu, 2017-07-06 at 10:55 -0500, Christoph Lameter wrote: > On Thu, 6 Jul 2017, Kees Cook wrote: > > > On Thu, Jul 6, 2017 at 6:43 AM, Christoph Lameter <cl@linux.com> > > 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. > > These reads are not arbitrary. You can usually calculate the page > struct > address easily from the address and then do a couple of loads to get > there. > > Ok so you get rid of the old attacks because we did not have that > hardening in effect when they designed their approaches? The hardening protects against situations where people do not have arbitrary code execution and memory read access in the kernel, with the goal of protecting people from acquiring those abilities. > > 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. > > Na I am not convinced of the "much more difficult". Maybe they will > just > have to upgrade their approaches to fetch the proper values to > decode. Easier said than done. Most of the time there is an unpatched vulnerability outstanding, there is only one known issue, before the kernel is updated by the user, to a version that does not have that issue. Bypassing kernel hardening typically requires the use of multiple vulnerabilities, and the absence of roadblocks (like hardening) that make a type of vulnerability exploitable. Between usercopy hardening, and these slub freelist canaries (which is what they effectively are), several classes of exploits are no longer usable. -- All rights reversed [-- Attachment #2: This is a digitally signed message part --] [-- Type: application/pgp-signature, Size: 473 bytes --]
next prev parent reply other threads:[~2017-07-06 17:53 UTC|newest] Thread overview: 66+ messages / expand[flat|nested] mbox.gz Atom feed top 2017-07-06 0:27 [PATCH v3] mm: Add SLUB free list pointer obfuscation Kees Cook 2017-07-06 0:27 ` [kernel-hardening] " Kees Cook 2017-07-06 0:27 ` Kees Cook 2017-07-06 13:43 ` Christoph Lameter 2017-07-06 13:43 ` [kernel-hardening] " Christoph Lameter 2017-07-06 13:43 ` Christoph Lameter 2017-07-06 15:48 ` Kees Cook 2017-07-06 15:48 ` [kernel-hardening] " Kees Cook 2017-07-06 15:48 ` Kees Cook 2017-07-06 15:55 ` Christoph Lameter 2017-07-06 15:55 ` [kernel-hardening] " Christoph Lameter 2017-07-06 15:55 ` Christoph Lameter 2017-07-06 16:16 ` [kernel-hardening] " Daniel Micay 2017-07-06 16:16 ` Daniel Micay 2017-07-06 16:16 ` Daniel Micay 2017-07-06 17:53 ` Rik van Riel [this message] 2017-07-06 17:53 ` Rik van Riel 2017-07-06 17:53 ` Rik van Riel 2017-07-06 18:50 ` Kees Cook 2017-07-06 18:50 ` [kernel-hardening] " Kees Cook 2017-07-06 18:50 ` Kees Cook 2017-07-07 13:50 ` Christoph Lameter 2017-07-07 13:50 ` [kernel-hardening] " Christoph Lameter 2017-07-07 13:50 ` Christoph Lameter 2017-07-07 16:51 ` Kees Cook 2017-07-07 16:51 ` [kernel-hardening] " Kees Cook 2017-07-07 16:51 ` Kees Cook 2017-07-07 17:06 ` Christoph Lameter 2017-07-07 17:06 ` [kernel-hardening] " Christoph Lameter 2017-07-07 17:06 ` Christoph Lameter 2017-07-07 18:43 ` Kees Cook 2017-07-07 18:43 ` [kernel-hardening] " Kees Cook 2017-07-07 18:43 ` Kees Cook 2017-07-24 21:17 ` [v3] " Alexander Popov 2017-07-24 21:17 ` [kernel-hardening] " Alexander Popov 2017-07-24 21:17 ` Alexander Popov 2017-07-25 9:42 ` Alexander Popov 2017-07-25 9:42 ` [kernel-hardening] " Alexander Popov 2017-07-25 9:42 ` Alexander Popov 2017-07-26 0:21 ` Kees Cook 2017-07-26 0:21 ` [kernel-hardening] " Kees Cook 2017-07-26 0:21 ` Kees Cook 2017-07-26 14:08 ` Christopher Lameter 2017-07-26 14:08 ` [kernel-hardening] " Christopher Lameter 2017-07-26 14:08 ` Christopher Lameter 2017-07-26 16:20 ` Kees Cook 2017-07-26 16:20 ` [kernel-hardening] " Kees Cook 2017-07-26 16:20 ` Kees Cook 2017-07-26 16:55 ` Christopher Lameter 2017-07-26 16:55 ` [kernel-hardening] " Christopher Lameter 2017-07-26 16:55 ` Christopher Lameter 2017-07-26 17:13 ` Kees Cook 2017-07-26 17:13 ` [kernel-hardening] " Kees Cook 2017-07-26 17:13 ` Kees Cook 2017-07-27 15:15 ` Christopher Lameter 2017-07-27 15:15 ` [kernel-hardening] " Christopher Lameter 2017-07-27 15:15 ` Christopher Lameter 2017-07-27 22:48 ` Alexander Popov 2017-07-27 22:48 ` [kernel-hardening] " Alexander Popov 2017-07-27 22:48 ` Alexander Popov 2017-07-27 23:53 ` Christopher Lameter 2017-07-27 23:53 ` [kernel-hardening] " Christopher Lameter 2017-07-27 23:53 ` Christopher Lameter 2017-07-31 20:17 ` Alexander Popov 2017-07-31 20:17 ` [kernel-hardening] " Alexander Popov 2017-07-31 20:17 ` Alexander Popov
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=1499363602.26846.3.camel@redhat.com \ --to=riel@redhat.com \ --cc=akpm@linux-foundation.org \ --cc=bigeasy@linutronix.de \ --cc=cl@linux.com \ --cc=daniel@zonque.org \ --cc=deller@gmx.de \ --cc=iamjoonsoo.kim@lge.com \ --cc=josh@joshtriplett.org \ --cc=keescook@chromium.org \ --cc=kernel-hardening@lists.openwall.com \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=luto@kernel.org \ --cc=mingo@kernel.org \ --cc=nicolas.pitre@linaro.org \ --cc=paulmck@linux.vnet.ibm.com \ --cc=penberg@kernel.org \ --cc=rientjes@google.com \ --cc=sergey.senozhatsky@gmail.com \ --cc=tj@kernel.org \ --cc=tycho@docker.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.