On Fri, 2011-03-04 at 22:02 +0200, Pekka Enberg wrote: > On Fri, Mar 4, 2011 at 8:14 PM, Matt Mackall <mpm@xxxxxxxxxxx> 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. > > Pekka Thanks for your work on this. The most general exploitation techniques involving kernel SLUB/SLAB corruption involve manipulating heap state such that an object that can be overflowed by the attacker resides immediately before another object whose contents are worth overwriting, or overflowing into the page following the slab. The most common known techniques involve overflowing into an allocated object with useful contents such as a function pointer and then triggering these (various IPC-related structs are often used for this). It's also possible to overflow into a free object and overwrite its free pointer, causing subsequent allocations to result in a fake heap object residing in userland being under an attacker's control. 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. Of course people more knowledgeable on SLUB should look this over for sanity's sake, but it looks good to me. -Dan -- 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>