Defeating the 90%: How MTE Transforms Android Security

We're thrilled to share a ground-breaking development for our ChatMail on Renati customers, one that has been in the works for over four years and is set to revolutionize Android security. While it may not make the headlines immediately, this monumental change will have far-reaching implications for the safety of your devices. Introducing MTE - Memory Tag Extensions, a kernel-level security feature making its debut on the Pixel 8 and Pixel 8 Pro handsets.

A device enabled with MTE will act like a force field around each memory allocation, preventing potential threats like overflows, use-after-free and out of bound exceptions. These may sound like technical jargon, but an astonishing 90% of all Android vulnerabilities stem from these specific types of errors:

Source: security.googleblog.com/2019/05/queue-hardening-enhancements

MTE is a feature introduced into Arm v9 architecture, used in the Pixel 8 and 8 Pro devices. It creates a map of metadata for every 16 bytes of memory. This equates to about 3% of your RAM being used to store metadata about each 16-byte segment of memory. The metadata acts like a key that unlocks its respective 16-byte lock in memory. The CPU checks the memory tags for every load and stores instruction made to memory. This way any "unauthorized" change to memory allocation will trigger either a crash and prevent further exploits or merely be recorded for further analysis.

The below diagram shows two examples: the first of a buffer overflow error and the second of use-after-free error. Both of these would trigger a memory safety check by MTE. This simple check and balance system is enough to circumvent 90% of vulnerabilities that are currently present in the Android ecosystem.

How Does This Affect Me? Buffer overflows, and use-after-frees? How can an attacker possibly make use of that to get access to my private data?

In 2019 the infamous NSO group was identified as using a simple use-after-free bug on the iPhones to gain root access and ex-filtrate data. You or your company may not be the direct target of a multi-million-dollar spyware agency like the NSO group, but keep in mind that the exact same mechanisms are used by script kiddies and ransomware gangs that presently justifies the existence of a multi-billion dollar cyber-security industry. The NSO group created a three-stage exploit in 2019 that went something like this:

• Stage 1 - The user clicks on a link that opens the Safari browser. Nowadays, we have heard of zero-click mechanisms that don't even require the user to click anything. Safari had a use-after-free zero-day bug as part of their JavaScriptCore library. The exploit uses the browser to run a JavaScript payload that gains arbitrary code execution privileges.
• Stage 2 - The malware now escalates privileges to create an environment that enables it to jailbreak (root) the device. Stage2 uses a use-after-free (UAF) vulnerability within the "io_service_open_extended" deserialization routine.
• Stage 3 - Finally, it gains root access on the iPhone, disables code signing, then drops and activates the jailbreak binary. This stage leverages the final Trident vulnerability, where kernel memory corruption leads to jailbreak.

Without memory corruption this sort of attack would have been impossible.

Source: Pegasus Exploits Technical Details (pdf)

All is not perfect however, MTE will not be available for components like Bluetooth and NFC:

“we can't currently enable MTE for a few components in a normal production build - these exceptions are system_server and applications related to NFC, the secure element and Bluetooth”

The reason for this is understandable, MTE will break functionality on any app that has memory corruption bugs. This is not feasible to implement on major system services until they have been made memory safe. However, this compromise also leaves open the door for bad actors to get in through zero-days on NFC, Bluetooth, and other system components. Further, this feature is also not yet available on Chrome:

Chrome doesn't use the system allocator for most allocations, and instead uses PartitionAlloc. There is experimental MTE support under development.

So, while MTE is a huge stride forward, it is hamstrung by limitations in a lot of legacy code still bearing the burden of memory corruption.

Source: googleprojectzero.blogspot.com/2023/11/first-handset-with-mte-on-market

Does this mean attackers will give up? Certainly not. The cat and mouse game cannot end. Attackers will have to re-focus and come up with better strategies. Perhaps they will re-double their efforts in attacking public facing APIs instead. But MTE is certainly a powerful new weapon in the hands of engineers.

I'm all too well familiar with the adage that "It is the poor workman that blames his tools". And I'll gladly say that I'm a poor workman. Until memory safe languages like Rust came along, us engineers, have been fighting a losing battle. It is generally easier to break things than to make them. Being on the red team is easier than being on the blue team. It doesn't take nearly as much work to find a weak brick in a wall than it is to build that wall. But the tide is shifting. Google is banking heavily on Rust, migrating ever larger portions of the Android source code to it. And MTE is an unexpected but much vaunted protection for us blue team engineers and a great addition to our toolset.

If you are presently on Renati, you don't even need to wait for this new and shiny silver bullet. Renati has kneecapped most attackers by destroying NFC, Bluetooth, and other exploitable system components. Even the Pegasus attack described above would be fruitless on a Renati device because we intentionally disabled the use of sand boxed Webkit UIs and WebViews. Even if an attacker wants to send you a phishing link to your Renati device running ChatMail encrypted communications, there is no WebView system that can be used to direct you to a malicious site or inject malicious code.

Renati truly is your best guarantee against both script kiddies and even persistent and determined adversaries. MTE will however enable us to bring you newer features and apps with a far better guarantee of security. App development can be cumbersome and time consuming and most vendors will compromise on security in favor of speed. MTE offsets some security guarantees to the kernel and enables more rapid app development. Some big changes are coming in 2024.