[lkml]   [2011]   [Mar]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH] Make /proc/slabinfo 0400
    On Fri, 2011-03-04 at 22:58 +0200, Pekka Enberg wrote:
    > On Fri, Mar 4, 2011 at 10:37 PM, Dan Rosenberg <> wrote:
    > > This patch makes these techniques more difficult by making it hard to
    > > know whether the last attacker-allocated object resides before a free or
    > > allocated object. Especially with vulnerabilities that only allow one
    > > attempt at exploitation before recovery is needed to avoid trashing too
    > > much heap state and causing a crash, this could go a long way. I'd
    > > still argue in favor of removing the ability to know how many objects
    > > are used in a given slab, since randomizing objects doesn't help if you
    > > know every object is allocated.
    > So if the attacker knows every object is allocated, how does that help
    > if we're randomizing the initial freelist?

    First note that all of these attacks are probabilistic.

    Now, with a randomized free list, if I create 1000 objects of type B,
    then, on average, the partially-filled page the next allocation comes
    from will be half-full of B objects. Thus, the next object will have a
    50% chance of being in the right spot for an exploit.

    Now if I delete the 800th B object, it's probably on a slab that's
    otherwise full of B objects since we fill partial slabs before creating
    new ones. If my next allocation comes from that slab, it will thus get a
    spot that's almost guaranteed to be in the right spot.

    Similarly, if I create 1000 objects and then delete every tenth one,
    I've now got a swiss cheese heap where just about every hole is

    Mathematics is the supreme nostalgia of our time.

     \ /
      Last update: 2011-03-06 11:19    [W:4.032 / U:37.608 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site