Date: Mon, 11 Apr 2016 12:08:57 -0700 From: Kees Cook <keescook@...omium.org> To: "kernel-hardening@...ts.openwall.com" <kernel-hardening@...ts.openwall.com> Cc: lazytyped <lazytyped@...il.com> Subject: Re: [RFC v2] mm: SLAB freelist randomization On Sat, Apr 9, 2016 at 7:08 AM, lazytyped <lazytyped@...il.com> wrote: > > > On 4/8/16 11:03 AM, Thomas Garnier wrote: >> For example this attack against SLUB (also applicable against SLAB) >> would be affected: >> https://jon.oberheide.org/blog/2010/09/10/linux-kernel-can-slub-overflow/ > > would it? > > - allocate a ton of shmid_kernel until you get a fresh page > - free one of such objects (here is where your randomization comes into > play) > - allocate the "vulnerable" object > - trigger the overflow > - start "freeing" the others - one will work > > This doesn't work only in the case in which you are the last object in > the SLUB. So what you are achieving is a 1/(pagesize/sizeof_objects) > chance of making the attack less reliable. But I can free yet another > object and retry, if the previous overflow didn't kill me (simplest way > to guarantee that is to not completely fill the newly allocated SLUB page). All the randomization stuff is just a statistical defense, though it would seem to raise the bar of exploitation. I'd love to get a solid example for an exploit that this mitigation would interfere with, though. Do you know of any that would fit better here? -Kees -- Kees Cook Chrome OS & Brillo Security
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.