On Thu, 22 Jun 2017 18:50:10 -0700 Kees Cook <[email protected]> wrote:
> This SLUB free list pointer obfuscation code is modified from Brad > Spengler/PaX Team's code in the last public patch of grsecurity/PaX based > on my understanding of the code. Changes or omissions from the original > code are mine and don't reflect the original grsecurity/PaX code. > > This adds a per-cache random value to SLUB caches that is XORed with > their freelist pointers. This adds nearly zero overhead and frustrates the > very common heap overflow exploitation method of overwriting freelist > pointers. A recent example of the attack is written up here: > http://cyseclabs.com/blog/cve-2016-6187-heap-off-by-one-exploit > > This is based on patches by Daniel Micay, and refactored to avoid lots > of #ifdef code. > > ... > > --- a/init/Kconfig > +++ b/init/Kconfig > @@ -1900,6 +1900,15 @@ config SLAB_FREELIST_RANDOM > security feature reduces the predictability of the kernel slab > allocator against heap overflows. > > +config SLAB_FREELIST_HARDENED > + bool "Harden slab freelist metadata" > + depends on SLUB > + help > + Many kernel heap attacks try to target slab cache metadata and > + other infrastructure. This options makes minor performance > + sacrifies to harden the kernel slab allocator against common > + freelist exploit methods. > + Well, it is optable-outable. > config SLUB_CPU_PARTIAL > default y > depends on SLUB && SMP > diff --git a/mm/slub.c b/mm/slub.c > index 57e5156f02be..590e7830aaed 100644 > --- a/mm/slub.c > +++ b/mm/slub.c > @@ -34,6 +34,7 @@ > #include <linux/stacktrace.h> > #include <linux/prefetch.h> > #include <linux/memcontrol.h> > +#include <linux/random.h> > > #include <trace/events/kmem.h> > > @@ -238,30 +239,50 @@ static inline void stat(const struct kmem_cache *s, > enum stat_item si) > * Core slab cache functions > *******************************************************************/ > > +#ifdef CONFIG_SLAB_FREELIST_HARDENED > +# define initialize_random(s) \ > + do { \ > + s->random = get_random_long(); \ > + } while (0) > +# define FREEPTR_VAL(ptr, ptr_addr, s) \ > + (void *)((unsigned long)(ptr) ^ s->random ^ (ptr_addr)) > +#else > +# define initialize_random(s) do { } while (0) > +# define FREEPTR_VAL(ptr, addr, s) ((void *)(ptr)) > +#endif > +#define FREELIST_ENTRY(ptr_addr, s) \ > + FREEPTR_VAL(*(unsigned long *)(ptr_addr), \ > + (unsigned long)ptr_addr, s) > + That's a bit of an eyesore. Is there any reason why we cannot implement all of the above in nice, conventional C functions? > > ... > > @@ -3536,6 +3557,7 @@ 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; > + initialize_random(s); > > if (need_reserve_slab_rcu && (s->flags & SLAB_TYPESAFE_BY_RCU)) > s->reserved = sizeof(struct rcu_head); We regularly have issues where the random system just isn't ready (enough) for clients to use it. Are you sure the above is actually useful for the boot-time caches?
