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

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.

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

Replying to

and

Tag reserved for free can also be used for metadata, although for hardened_malloc the metadata for both slab and large allocations is entirely out-of-line in a dedicated region never reused for anything else. That's still important for deterministic invalid free detection, etc.