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

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

6

36

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.

1

1

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.

1

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.

2

1

Replying to

and

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

1

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.

1

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.

1

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.

2

1

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.

1

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.

1

Replying to

and

Leaking those isn't desirable since the initial value was randomized and the weak probabilistic part of memory tagging does have some value too. To bypass the incremented tag, the use-after-free can't happen until the allocation is active after being allocated again 15 times.

5:37 PM · Aug 8, 2019Twitter Web App

Replying to

and

Combine that with the quarantine, which for example with 128k per class will delay reuse of 16 byte allocations for 8192 alloc/free cycles. There are really 2 layers of quarantine, the ring buffer (FIFO) and a random array (swaps with random slot), which makes it hard to line up.

1

Replying to

and

Since it actually has to line up with the allocation being reused a multiple of 15 times later (due to having 16 tags with 1 tag reserved for free memory). It's a bit more complex than that due to skipping adjacent tags when incrementing as with choosing the initial random one.