- 128comments
- 13comments
- 21comments
- 37comments
- 8comments
- 136comments
- 249comments
- 8comments
- 32comments
- 10comments
- 25comments
- 11comments
- 17comments
- 219comments
- 117comments
- 91comments
- 14comments
- 117comments
- 16comments
- 87comments
- 52comments
- 41comments
- 32comments
- 5comments
- 991comments
- 2comments
- 51comments
- 92comments
- 7comments
- 39comments
Relatedly, check out Apple’s own kalloc_type allocator that they use with MTE as well as newer silicon-level changes for extremely broad memory integrity enforcement:
https://security.apple.com/blog/memory-integrity-enforcement...
Or Solaris SPARC ADI memory allocator,
https://docs.oracle.com/cd/E88353_01/html/E37843/malloc-3c.h...
Yeah that work is way more impressive.
I like how they demonstrated exactly how it impacts known exploits for example
The problem with these kinds of hardened allocators is that:
- They impact performance.
- They don’t prevent the attacker from pivoting a memory safety bug to remote execution.
- They get oversold (like calling it “secure”).
That’s not to say there aren’t allocator mitigations that help. It’s just that this isn’t it. Quarantining for example just means the attacker has to do a bit more acrobatics, but it won’t stop them.
I think what Apple is doing with typed allocations is much more principled and they have data to prove it in their blog posts
Yes, but it also means you need an Apple device, and hence a locked down system. You also need to take all of Apple's privacy claims at face value. No thanks.
I'm confused. Isn't this potentially preventing some classes of memory-safety bugs?
No, it’s not
This is one of the things that hardened malloc is doing (and is part of the post). Newer pixels are shipping with MTE support and graphene's malloc leverages MTE as much as possible.
They’re referring to kalloc_type [0] [1].
[0]: https://security.apple.com/blog/towards-the-next-generation-...
[1]: https://security.apple.com/blog/what-if-we-had-sockpuppet-in...
There might be processes that have high privileges, but don't need high performance, for example: sudo utility, new USB device detection daemon, bluetooth communication daemon.
Also idea described in Apple's article (never reuse allocated addresses for other types) cannot be easily implemented for any allocator. Consider a memory pipe (circular buffer), where one process pushes messages and another reads them. How do you implement Apple-style memory safety here? One of the ideas is of course to map the buffer multiple times, so that every allocation returns a new virtual address, but how many syscalls you will need for that and how badly that would impact performance.