lkml.org 
[lkml]   [2011]   [Mar]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    SubjectRe: [PATCH] Make /proc/slabinfo 0400
    From
    On Fri, 2011-03-04 at 14:31 -0600, Matt Mackall wrote:
    >> On Fri, 2011-03-04 at 22:02 +0200, Pekka Enberg wrote:
    >> > On Fri, Mar 4, 2011 at 8:14 PM, Matt Mackall <mpm@selenic.com> wrote:
    >> > >> Of course, as you say, '/proc/meminfo' still does give you the trigger
    >> > >> for "oh, now somebody actually allocated a new page". That's totally
    >> > >> independent of slabinfo, though (and knowing the number of active
    >> > >> slabs would neither help nor hurt somebody who uses meminfo - you
    >> > >> might as well allocate new sockets in a loop, and use _only_ meminfo
    >> > >> to see when that allocated a new page).
    >> > >
    >> > > I think lying to the user is much worse than changing the permissions.
    >> > > The cost of the resulting confusion is WAY higher.
    >> >
    >> > Yeah, maybe. I've attached a proof of concept patch that attempts to
    >> > randomize object layout in individual slabs. I'm don't completely
    >> > understand the attack vector so I don't make any claims if the patch
    >> > helps or not.
    >>
    >> In general, the attack relies on getting an object A (vulnerable to
    >> overrun) immediately beneath an object B (that can be exploited when
    >> overrun).
    >>
    >> I'm not sure how much randomization helps, though. Allocate 1000 objects
    >> of type B, deallocate the 800th, then allocate an object of type A. It's
    >> almost certainly next to a B.

    On Fri, Mar 4, 2011 at 10:42 PM, Dan Rosenberg <drosenberg@vsecurity.com> wrote:
    > On second thought, this does pose a problem.  Even if you don't know how
    > full the most recent slab is or where free vs. used chunks are within
    > it, if you can guarantee that you filled an entire previous slab with
    > your objects and then free and reallocate one of them, then you can
    > still win.

    Guys, I still don't get it, sorry.

    Why can you still win? With my patch, reallocation shouldn't matter;
    the freelist randomization ought to make it less likely for *any* two
    allocated objects to be adjacent.

    Pekka
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

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