lkml.org 
[lkml]   [2011]   [Mar]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [PATCH] Make /proc/slabinfo 0400
    From
    Date

    > Well if it were a 1000x-1000000x difficulty improvement, I would say you
    > had a point. But at 10x, it's just not a real obstacle. For instance, in
    > this exploit:
    >
    > http://www.exploit-db.com/exploits/14814/
    >
    > ..there's already detection of successful smashing, so working around
    > not having /proc/slabinfo is as simple as putting the initial smash in a
    > loop. I can probably improve my odds of success to nearly 100% by
    > pre-allocating a ton of objects all at once to get my own private slab
    > page and tidy adjoining allocations. I'll only fail if someone does a
    > simultaneous allocation between my target objects or I happen to
    > straddle slab pages.
    >

    For this particular exploit, the allocation and triggering of the
    vulnerability were in separate stages, so that's the case, but other
    exploits might have additional constraints. For example, there is a
    public exploit for a two-byte SLUB overflow that relies on a partial
    overwrite into a free chunk; exploitation of vulnerabilities similar to
    this may be significantly hindered by the lack of availability of this
    interface. Still other issues may only get one shot at exploitation
    without needing to clean up corrupted heap state to avoid panicking the
    kernel. In short, every exploit is different, and exposure
    of /proc/slabinfo may be the thing that puts some more difficult cases
    within reach.

    > And once an exploit writer has figured that out once, everyone else just
    > copies it (like they've copied the slabinfo technique). At which point,
    > we might as well make the file more permissive again..
    >

    This may be true to some extent, but kernel vulnerabilities tend to be
    somewhat varied in terms of exploitation constraints, so I'm not
    convinced a general technique would apply to enough cases to render this
    change completely pointless.

    Many security features, for example NX enforcement, have not proven to
    be especially significant in completely mitigating exploitation of
    userland memory corruption vulnerabilities by themselves, given the
    advent of code-reuse exploitation techniques. They have also come at
    the cost of breaking some applications. However, the reason we don't
    just turn them all off is because they provide SOME hurdle, however
    small, and given enough incremental improvements, we eventually get to
    the point where things are actually hard.

    > > > On the other hand, I'm not convinced the contents of this file are of
    > > > much use to people without admin access.
    > > >
    > >
    > > Exactly. We might as well do everything we can to make attackers' lives
    > > more difficult, especially when the cost is so low.
    >
    > There are thousands of attackers and millions of users. Most of those
    > millions are on single-user systems with no local attackers. For every
    > attacker's life we make trivially more difficult, we're also making a
    > few real user's lives more difficult. It's not obvious that this is a
    > good trade-off.
    >

    I appreciate your input on this, you've made very reasonable points.
    I'm just not convinced that those few real users are being substantially
    inconvenienced, even if there's only a small benefit for the larger
    population of users who are at risk for attacks. Perhaps others could
    contribute their opinions to the discussion.

    -Dan

    > --
    > Mathematics is the supreme nostalgia of our time.




    \
     
     \ /
      Last update: 2011-03-03 23:33    [W:0.024 / U:30.584 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site