On Thu, 2011-03-03 at 17:30 -0500, Dan Rosenberg wrote: > > 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. That's my hope, as I'm basically on the fence. -- Mathematics is the supreme nostalgia of our time. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxxx For more info on Linux MM, see: http://www.linux-mm.org/ . Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/ Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>