[HN Gopher] Exploring GrapheneOS secure allocator: Hardened Malloc
___________________________________________________________________
Exploring GrapheneOS secure allocator: Hardened Malloc
Author : r4um
Score : 87 points
Date : 2025-09-24 09:56 UTC (13 hours ago)
(HTM) web link (www.synacktiv.com)
(TXT) w3m dump (www.synacktiv.com)
| mrtesthah wrote:
| 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...
| pjmlp wrote:
| Or Solaris SPARC ADI memory allocator,
|
| https://docs.oracle.com/cd/E88353_01/html/E37843/malloc-3c.h...
| pizlonator wrote:
| Yeah that work is way more impressive.
|
| I like how they demonstrated exactly how it impacts known
| exploits for example
| pizlonator wrote:
| 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
| drnick1 wrote:
| 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.
| manbash wrote:
| > They don't prevent the attacker from pivoting a memory safety
| bug to remote execution.
|
| I'm confused. Isn't this potentially preventing some classes of
| memory-safety bugs?
___________________________________________________________________
(page generated 2025-09-24 23:01 UTC)