[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAJcbSZGo25eo4-ukF39vNvvpdzpmnQY6RVBcxc41Z-goS5F1LA@mail.gmail.com>
Date: Sat, 9 Apr 2016 07:24:24 -0700
From: Thomas Garnier <thgarnie@...gle.com>
To: kernel-hardening@...ts.openwall.com
Subject: Re: [RFC v2] mm: SLAB freelist randomization
Yes and no. With slabinfo not being available if not root you are not sure
when you start a new SLAB. You also can't quantify the risk of another
allocation happening on a real machine under load.
It decreases the odds on a successful overflow that just requires two
allocations to follow one another. It doesn't mitigate heap overflows.
Thanks,
Thomas
On Apr 9, 2016 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).
>
>
> - twiz
Content of type "text/html" skipped
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.
