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.

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

Replying to

and

The enabled-by-default quarantine support in hardened_malloc delays allocation reuse, which has a nice synergy with this. Memory tagging will also allow disabling heap canaries and write-after-free detection. Setting tags on free will be 1 operation combined with zero-on-free.

Replying to

and

On allocation, setting the tags will replace the write-after-free detection, which is based on checking that the zero-on-free filling is intact. That's no longer necessary with a reserved memory tag protecting the memory. It combines well with some other parts of the design too.

Show replies

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.

Show replies