Conversation

one of the most interesting things about this work is that it might be the gateway drug that finally leads to widespread deployment of real memory safety for C and C++

Quote Tweet

Kostya Serebryany

@kayseesee

Aug 3, 2019

Adopting the Arm Memory Tagging Extension in Android security.googleblog.com/2019/08/adopti

Replying to

I have a more pessimistic outlook: these kinds of mitigations will just prolong C and C++ lifespan, while being quickly defeated by exploit authors, worsening security overall

Replying to

and

In my opinion, features like this work far better with memory safe languages where memory corruption bugs are very scarce. The attacker doesn't have the opportunity to choose from a huge selection of bugs / helpful memory corruption primitives to build a reliable way around it.

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

Replying to

and

Agreed.

Replying to

and

also makes exploitation of stuff like standalone file format loaders MUCH harder- in situations where you don't have some scripting language to glue your different bugs together. (in the distance, you hear langsec screaming that all file formats are scripting languages, but)

Replying to

and

It's part of a 2nd line of defence and that works better with sparse memory corruption bugs. Many vulnerabilities can be rendered unexploitable via non-random use of memory tagging (github.com/GrapheneOS/har), with reliable exploitation made much more difficult for most of others.

Replying to

and

There are still some memory corruption bugs left in the runtime and low-level libraries with safe languages, but the attacker doesn't have much to choose from and it's far harder for them to find the set of tools they need to bypass an assortment of good mitigations like tagging.