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.