after many years of procrastination, private (née unreadable) kstacks are about to graduate from PoC to production. not possible without some existing infrastructure we've developed for UDEREF and other features over a decade ago. payoff++ :)
3
8
31
PaX Team retweeted
As part of our new GitHub organization, OSS' @wipawel does a deep-dive into a @HexRaysSA IDA Pro plugin that he developed focusing on Linux kernel alternatives:
grsecurity.net/linux_kernel_…
1
15
2
47
PaX Team retweeted
New blog post from @_minipli : Watch Your Step(ping): Atoms Breaking Apart
grsecurity.net/watch_your_st…
Join us on a deep dive into a customer-reported issue that ended up being an Intel Atom CPU bug unfixed on a specific stepping. A microcode update fixing the issue is provided.
1
58
6
133
I am not sure that many people with deep offensive experience would agree that fine-grained KASLR is a good solution here (but I've had this discussion many times in the past and am frankly tired that it keeps coming back).
2/n: single-leak KASLR exposure reinforcing the need for Function-Granular KASLR.
While KASLR adds an additional hurdle, a single exposure will fully bypass it. Gaining FGKASLR would strongly diminish the value of a single exposure.
github.com/KSPP/linux/issues…
5
7
2
52
We should hold ourselves to a higher standard than that. Shipping a useless mitigation that will live forever and add complexity and cost to the entire world is strictly worse than not shipping it.
1
7
You may be happy to hear that ~10 years ago we did R&D on fine-grained randomization of images on Windows, but we chose not to move forward with it because we didn't think it would provide enough long-term value :)
priorart.ip.com/IPCOM/000210…
3
4
37
sorry to burst your bubble there :) but another 10y before your R&D the *very first* version of ASLR implemented per-mmap randomization (and had in fact been called ASR for a whole week maybe before i figured that it had enough bad sideeffects and went with ASLR ever since).
1
3
I learned something interesting today, gcc doesn't know memalign() returns aligned pointers (notice all the movdqus). This caused some very confusing benchmark results 😆. The solution was to use aligned_alloc() or __builtin_assume_aligned().
godbolt.org/z/j6vboqcME
3
9
71
as other said already: godbolt.org/z/5o4s9fqP5
2
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
How? The content of the page is erased in the process and we keep no pointers to PA. So what dangling pointer can you use here to carry out the attack?
1
VA is not reused and we zero pages on population so you can’t ever see data from a physical page from a previous life.
2
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?
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
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
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
the first implementation of AUTOSLAB was type based too (wherever we could infer an lhs type from kmalloc, that is), resulting in about 9k autoslabs on linux 5.4/amd64/allyes. then we decided to see how far we can take it and went with the per call-site conversion :).
Reading a kernel dev thread where it's clear not a single person read the NCC Group blog from 2019 regarding struct padding, and so are repeating the same old mistakes (particularly wrt some GCC vers). The blog seems to have disappeared since, so I guess they're out of luck 🤷♂️
2
13
That's amazing, would love to know how many extra barriers get inserted in say an Ubuntu kernel. No way you could find them all through code review!
1
don't have current numbers at hand, but on a 5.4.13-allyes-amd64 config respectre reported about 33k v4 instances as above. that was over 1.5y ago, so not quite representative of the current code but you get the idea.
1
PaX Team retweeted
For the past 3 months, we had the talented @Markak_ (co-author of last year's "elastic objects" paper) investigate how #grsecurity's compiler-driven AUTOSLAB feature changes kernel heap exploitation (positively or negatively). His writeup is now available: grsecurity.net/how_autoslab_…
3
50
5
103
PaX Team retweeted
First picture, me to eBPF devs in 2016, second picture Qualys in 2021 exploiting the exact property I mentioned
2
80
2
344
PaX Team retweeted
New Blog Post: The Complicated History of a Simple Linux Kernel API
grsecurity.net/complicated_h…
34
1
81