grsecurity.net/how_autoslab_…
nice article here. We're shipping, in iOS 15 and aligned releases, a protection with a very similar spirit.
we call it kalloc_type().
Our impl has different characteristics, e.g. XNU has zone sequestering, so cross-zone attacks isn't a thing.
2
9
4
61
Based on the API name, I assume this isn't used for everything? It's not clear from the current blog (since the purpose was the security eval, not debugging or other aspects), but we get some nice properties out of having AUTOSLAB applied to everything:
Extending on what AUTOSLAB already had earlier, the next beta will be able to turn arbitrary addresses instantly into something like:
autoslab_const_M_main_P_init_main_1100_27_1100_27_S_6848_A_64_n_1.task_struct.wake_entry.llist.next+0x38/0x1ac0
without any sl[a|u]b debugging
2
We typically do not comment on future roadmaps so I won’t go in details. But yes unlike autoslab we rely on manual adoption and it isn’t thorough yet, and covers zones (~= sub-page) for now.
We are indeed type based which gives us precise free sites (the free site pins types)
3
2
3
re: sequestering, it's 2 scalability problems: perf impact of small pages (e.g., linux/kmalloc uses the lowmem map with 2M/1G pages on amd64) and available address space (think 100k autoslabs and months of uptime on a busy server).
1
1
you assume we used 100k zones ;)
we randomize type-to-zone mappings each boot, sequestering combined with precise free sites allows us to tune the balance between perf and security.
iDevices have even less RAM, and run in such trouble you mention even faster than a busy server
1
the 100k was the autoslab number and i'm pretty sure manual conversion or the whole sequestering idea wouldn't scale there :). re free sites, are you saying (if you can :) that objects from the same allocation site(s) can end up in different zones (some sequestered, some not)?
1
No. I say that we group types into buckets to diminish the number of zones (slabs). But in general a free site can only free to a single zone. If an attacker tries to pass a pointer from bucket slab you panic. This rigidity makes up for the bucketting we do
1
To exploit a vuln you need to do it with the types your bucket shares as a result. That’s it. and that bucketing is random.
1
so does it mean that once a physical page is allocated to a (sequestered) zone, it'll never be freed, even if all objects in that zone get freed? 'cos i don't see how else you can guarantee that there's no cross-cache attack possible.
1
so you do free the backing page and allow it to be reallocated to another zone later. then cross-cache UAF exploitation is still possible, right?
Aug 13, 2021 · 8:46 PM UTC
1