Saturday, November 23, 2024

Arm Memory Tag Extensions broken by speculative execution

Must read

In 2018, chip designer Arm introduced a hardware security feature called Memory Tagging Extensions (MTE) as a defense against memory safety bugs. But it may not be as effective as first hoped.

Implemented and supported last year in Google’s Pixel 8 and Pixel 8 Pro phones and previously in Linux, MTE aims to help detect memory safety violations, as well as hardening devices against attacks that attempt to exploit memory safety flaws.

Memory safety bugs are said to be responsible for the majority of security vulnerabilities in large codebases. And for the past few years, there’s been a concerted effort in the public and private sector to reduce such flaws by promoting memory safe programming languages, software-based code hardening techniques, and hardware-specific options like SPARC ADI and Arm MTE.

MTE works by tagging 16-byte blocks of physical memory with four bits of metadata. This metadata serves as a key that permits access. When a pointer references data within a tagged block of memory, the hardware checks to make sure the pointer contains a key matching that of the memory block to gain access to the data. A mismatch throws out an error.

Tag, you’re IT

Diving deeper, this is how MTE basically works. When MTE is active, programs can use special instructions to tag 16-byte blocks of memory with a 4-bit key. For example, when allocating a chunk of memory from the heap, that chunk (aligned and rounded to 16 bytes) can be tagged with the same 4-bit key, and a pointer to that chunk is generated containing the key in its upper unused bits.

When the program uses that pointer in future, referencing some part of the block, everything works fine. The pointer still contains the correct key. But if the block is freed and its key is changed, subsequent use of that stale pointer will trigger a fault, due to a mismatching key, which indicates a programming bug or a vulnerability exploit attempt, both of which you want to catch.

And if the program is hijacked via some other vulnerability, and the code is made to reference a tagged block without the right key in the pointer, that will also be caught.

Thus MTE can defend against attempts to exploit common C/C++-style memory bugs, such as buffer overflows, heap-use-after-free, and stack-use-after-return, which can lead to software and systems being hijacked and compromised, and also help developers catch those bugs during testing. Or so Arm hopes.

Leaks

Unfortunately, MTE appears to be insufficiently secure to fulfill its security promises. Researchers affiliated with Seoul National University in South Korea, Samsung Research, and Georgia Institute of Technology in the US have found that they can break MTE through speculative execution.

The authors – Juhee Kim, Jinbum Park, Sihyeon Roh, Jaeyoung Chung, Youngjoo Lee, Taesoo Kim, and Byoungyoung Lee – say as much in their research paper, “TikTag: Breaking Arm’s Memory Tagging Extension with Speculative Execution.”

Having looked at MTE to assess whether it provides the claimed security benefit, the boffins say it does not. Instead, they found they could extract MTE tags in under four seconds around 95 per cent of the time.

“[W]e found that speculative execution attacks are indeed possible against MTE, which severely harms the security assurance of MTE,” the authors report. “We discovered two new gadgets, named TIKTAG-v1 and TIKTAG-v2, which can leak the MTE tag of an arbitrary memory address.”

This doesn’t blow the security of applications on Arm wide open; it means that MTE can be bypassed in the right conditions.

Security speculations

Speculative execution refers to the practice of performing certain operations on modern processors before they’re needed and either using the results, if required by the program’s path, or tossing them, if the program takes a different path. Doing so tends to make application execution faster, though it adds a significant security risk, exemplified by the Meltdown and Spectre bugs that surfaced in 2018 and have plagued makers of hardware and software ever since.

By using gadgets – machine instruction patterns in memory – the scientists found they could observe memory access patterns to determine the MTE tag of a given memory address. The root causes, they say, have to do with the way tag check results influence CPU data prefetching and the way the CPU core prevents store-and-load forwarding when there’s a tag check fault.

The authors say that their research expands on prior work from May 2024 that found MTE vulnerable to speculative probing. What’s more, they contend their findings challenge work by Google’s Project Zero that found no side-channel attack capable of breaking MTE.

Using proof-of-concept code, MTE tags were ferreted out of Google Chrome on Android and the Linux kernel using this technique, with a success rate that exceeded 95 percent in less than four seconds, it’s claimed.

The authors have made their code available on GitHub. “When TikTag gadgets are speculatively executed, cache state differs depending on whether the gadgets trigger a tag check fault or not,” the code repo explains. “Therefore, by observing the cache states, it is possible to leak the tag check results without raising any exceptions.”

Access to leaked tags doesn’t ensure exploitation. It simply means that an attacker capable of exploiting a particular memory bug on an affected device wouldn’t be thwarted by MTE.

The researchers disclosed their findings to Arm, which acknowledged them in a developer note published in December 2023. The chip design firm said that timing differences in successful and failed tag checking can be enough to create an MTE speculative oracle – a mechanism to reveal MTE tags – in Cortex-X2, Cortex-X3, Cortex-A510, Cortex-A520, Cortex-A710, Cortex-A715, and Cortex-A720 processors.

However, Arm argues that the risk does not undermine the value of MTE, even as it urges the implementation of mechanisms to prevent speculative oracles. Mitigations that place speculation barriers and limit gadget construction could be implemented in Chromium and Linux kernel code, the authors suggest.

Google’s Chrome team, the researchers say, acknowledged the issue but declined to fix it in Chrome’s V8 engine because it “is not intended to guarantee the confidentiality of memory data and MTE tags.” The authors observe that they somewhat agree since Chrome does not implement MTE by default, though they still would like to see their suggested mitigations deployed.

When the authors reported their work on MTE oracles in Pixel 8 devices to the Android Security Team in April 2024, they say the team acknowledged the issue, addressed it, and awarded a bug bounty.

Arm and Google did not immediately respond to requests for comment. ®

Latest article