[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAJcbSZGvhRfoqnMF6Ec1c9hPEp-vOiyeN4xYPsNseu0mzW4Uog@mail.gmail.com>
Date: Sat, 9 Apr 2016 08:31:50 -0700
From: Thomas Garnier <thgarnie@...gle.com>
To: kernel-hardening@...ts.openwall.com
Subject: Re: [RFC v2] mm: SLAB freelist randomization
I understand. There is correlation but no silver bullet against heap
overflows especially without significant performance impact.
The SLAB freelist was recently moved at the end of the set of pages. That
will create interesting attacks to transform an overflow to a use after
free. The freelist randomization can help on that.
Thomas
On Apr 9, 2016 7:42 AM, "lazytyped" <lazytyped@...il.com> wrote:
>
>
> On 4/9/16 7:24 AM, Thomas Garnier wrote:
> >
> > 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.
> >
>
> Both things you mention above are somehow unrelated to the freelist
> randomization. But that's fine. This has no performance impact, so there
> is no problem in having it (not that I would or would want to have a say
> :-) ).
>
> I was just arguing that hinting at that specific exploit as one that
> would have had 'decreased' odds of exploitation didn't seem like the
> best choice.
>
>
> - 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.
