> 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. -- 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>