Conversation

Memory tagging is an awesome technology, and the scariest mitigation I have seen as an attacker, ever. As such I am excited to read the paper, but dismayed that the authors seem to be affected by Redmondian RIP/PC obsession. The true value of MT is not in control flow integrity.

Quote Tweet

Matt Miller

@epakskape

Jul 19, 2019

Interested in memory safety exploits & mitigations? Here's a new research paper that explores an ISA extension which tries to make it more difficult to corrupt pointers. All feedback on the security efficacy and overall design is appreciated :) microsoft.com/en-us/research

168

Replying to

This. CFI is all snake oil aimed at giving attackers headaches at best. But MT admits mitigations that fully shut off lots of vulns.

Replying to

and

Unless I'm mistaken, even just 3 tag values suffice to ensure that no adjacent objects have same tag, which eliminates all sequential-store buffer overflows, or can be used to protect metadata between objects from *all* OOB stores.

Replying to

and

It can also be used for deterministic use-after-free mitigation for a given number of cycles. I've documented the approach that I'll be using for it in hardened_malloc: github.com/GrapheneOS/har There will be a value reserved for free memory, and then it increments the old value.

Replying to

and

This assumes freed chunks aren't splittable/mergeable, I think, which is another motivating factor for dropping dlmalloc design.

Replying to

and

A performance-oriented allocator would work well with a similar region-based slab allocation design. It could just use free lists within slabs instead of bitmaps, while still using the same approach to out-of-line metadata for tracking slabs. Main loss is double-free detection.

Replying to

and

There are other approaches to out-of-line metadata than the address space reservation. I'm doing that largely to get dedicated, isolated memory regions for metadata and each size class with the address space never being mixed / reused. Can also use an approach based on alignment.

Replying to

and

Memory tagging with a reserved free tag makes it so that the free list gets memory protected (free list accessed with pointers using the reserved free tag) and it's possible to detect double-free by checking for the free tag instead of checking if the slot is free in the bitmap.

4:53 PM · Aug 8, 2019Twitter Web App

Replying to

and

On that note, I'm really not a big fan of the ARMv8.3 pointer authentication feature. It's a very low entropy probabilistic mitigation without many compelling uses and I don't think it's a good use of scarce pointer bits. I'm already finding that address space is too scarce...

Replying to

and

And that's assuming free silicon as well

Replying to

and

Note that this depends on clearing the free list pointers from the chunk before returning it to satisfy an allocation. Otherwise the "uninitialized" memory returned by malloc contains valid (correctly-tagged!) pointers into the free list.

Replying to

and

Yeah, and also to preserve the nice property of having allocated memory guaranteed to be zero without information leaks. In my approach, the old tag for the previous allocation of that slot will be saved in the free slot too, in order to increment it, so that gets zeroed too.

Show replies