ARM has confirmed the possibility of an attack on systems with Cortex-X2, Cortex-X3, Cortex-A510, Cortex-A520, Cortex-A710, Cortex-A715 and Cortex-A720 processors, but does not intend to make changes to the CPU to block the problem[0], as how the MemTag architecture means that tags are not sensitive data to applications. Chrome's security team acknowledged the issues but won't fix them, as the V8 sandbox isn't designed for memory data confidentiality, and MTE defenses aren't enabled by default.
It's mentioned quite early in the paper but there's a prototype toolkit on GitHub[1] if you want to jump straight into that.
I'm not sure anyone is really surprised by this. Apple for example likewise calls out that you are at risk of an attacker using timing attacks to construct an authentication oracle for PAC, which is much more explicit about when exactly authentication checks actually happen.
Does this actually have any real world implications? If you're using MTE you already know there's a simple attack that succeeds with 1/16th probability (or maybe greater if you reserve some tags for special purposes or have some exploitable pattern in how your allocator hands out tags). In that system this pushes the attack probability to 100%. A nice technique but (hopefully) you've already architectured things assuming MTE will be broken so this doesn't change anything.
Certainly MTE was always pushed as a debugging feature only.
> Certainly MTE was always pushed as a debugging feature only.
This claim seems to come from ARM marketing but every SW company applying it - notably Google which I believe may have worked with ARM on this - mention of these types of tags in a security context (I believe Herb Sutter also talks about this as a way to harden c++ code). In fact, it’s seen as one very important way to harden existing legacy c/c++ code (and even unsafe Rust). There’s a big difference between 100% success rate and 1/16th - while you will still get an exploit through a 1/16th chance, the chances of detection raise significantly which isn’t nothing in a security context as it leaves a trail of breadcrumbs to investigate.
> It will take more fundamental mitigations that address the root issue of memory corruption, like MTE, in order to dramatically raise the bar for attackers.
> Hardware memory tagging may fix some security pitfalls of C++, while still allowing high performance. We are looking forward to see a more broad adoption of hardware memory tagging in the future and suggest using Scan on top of hardware memory tagging to fix temporary memory safety for C++
Of course MTE + Scan described above may not be vulnerable to this attack, but my point stands that MTE is very much viewed as a memory safety hardening feature (and thus the security implications that come with safety hardening).
This isn’t that bad news either. It may leave existing chips vulnerable but the next iteration of MTE will probably account for this problem (assuming you can’t patch microcode to solve this).
Are Google really pushing it a 'proper' security feature? You've quoted a line at the end of a blog that doesn't elaborate further. In the android documentation for instance it stats '[MTE] helps detect use-after-free and buffer-overflow bugs': https://source.android.com/docs/security/test/memory-safety/... without making any stronger claims.
> This isn’t that bad news either. It may leave existing chips vulnerable but the next iteration of MTE will probably account for this problem (assuming you can’t patch microcode to solve this).
I might argue fixing is is actively bad. Helps push the idea this is a feature to actually use for security rather than augment bug detection. Still fixing it shouldn't be too hard, just speculate as you do currently but always assume the tag check passes so you get the same speculative behaviour regardless of tag values (likely easier said than done of course, probably some fun corner cases where they'd still differ).
I totally agree. The authors have found a security vulnerability in a mechanism that wasn’t even trying to protect the software from attacks. I don’t see any relevance in this paper except being a good exercise
> Considering
the affected core (i.e., Cortex-A715) dispatches 5 instructions
in a cycle [ 55], it is likely that the CPU cannot detect the
dependency if the store and load instructions are executed in
the same cycle, since the store information is not yet written
to the internal buffers.
> If Len(GAP) is 4 or more, the store and load instructions are executed in the different cycles,
and the CPU can detect the dependency. Therefore, the CPU
skips the tag check and always forwards the data from the
store to load instructions.
> If Len(GAP) is less than 4, the store
and load instructions are executed in the same cycle, and
the CPU fails to detect the dependency and performs the tag
check for the load instruction. In this case, the forwarding
is blocked on tag check faults.
This would mean there's no forwarding from stores to loads within the same dispatch group on these cores?
> No problem, I was told, it’s not intended as a mitigation technique, it’s intended for at-scale debugging. Then certain companies decided it was a security technology.
> Why would they release research on security if they are being targeted for security concerns
Hmm. That doesn’t really follow IMO.
Every big corporation needs to have information security people. And most of them probably do some form of research as well. That’s the only way to stay on top of information security.
Whether they publish anything or not is up to them. But it’d be super silly to base the decision for that on the fact that USA government is banning TikTok.
> The Global Security Organization provides industry-leading cyber-security and business protection services to TikTok globally. Our organization employs four principles that guide our strategic and tactical operations. Firstly, we Champion Transparency & Trust by leading the charge in organizational transparency, prioritizing customer trust, and placing user needs first. Secondly, we aim to maintain Best in Class Global Security by proactively identifying and reducing risks while enabling innovative product development. We constantly work towards a sustainable world-class security capability. Thirdly, we strive to be a Business Catalyst & Enabler by embodying the DNA of technical innovation and ensuring our Global Security operations are fast and agile.
Heck here they even say just that: “proactively identifying and reducing risks while enabling innovative product development”. A natural part of that would be doing for example the kind of security researcher that the article of the OP is about.
No, this is a feature created for memory-unsafe languages which has turned out to be yet another memory safety attack vector. But there's no way to prevent this.
ARM has confirmed the possibility of an attack on systems with Cortex-X2, Cortex-X3, Cortex-A510, Cortex-A520, Cortex-A710, Cortex-A715 and Cortex-A720 processors, but does not intend to make changes to the CPU to block the problem[0], as how the MemTag architecture means that tags are not sensitive data to applications. Chrome's security team acknowledged the issues but won't fix them, as the V8 sandbox isn't designed for memory data confidentiality, and MTE defenses aren't enabled by default.
It's mentioned quite early in the paper but there's a prototype toolkit on GitHub[1] if you want to jump straight into that.
[0]: https://developer.arm.com/documentation/109544/latest
[1]: https://github.com/compsec-snu/tiktag
I'm not sure anyone is really surprised by this. Apple for example likewise calls out that you are at risk of an attacker using timing attacks to construct an authentication oracle for PAC, which is much more explicit about when exactly authentication checks actually happen.
"Confirmed the possibility" -- it was known when they invented this.
https://infosec.exchange/@david_chisnall/112632040031740747
Are you going to be posting the original shor's algorithm when the first quantum prime factorization hits the streets too?
Does this actually have any real world implications? If you're using MTE you already know there's a simple attack that succeeds with 1/16th probability (or maybe greater if you reserve some tags for special purposes or have some exploitable pattern in how your allocator hands out tags). In that system this pushes the attack probability to 100%. A nice technique but (hopefully) you've already architectured things assuming MTE will be broken so this doesn't change anything.
Certainly MTE was always pushed as a debugging feature only.
> Certainly MTE was always pushed as a debugging feature only.
This claim seems to come from ARM marketing but every SW company applying it - notably Google which I believe may have worked with ARM on this - mention of these types of tags in a security context (I believe Herb Sutter also talks about this as a way to harden c++ code). In fact, it’s seen as one very important way to harden existing legacy c/c++ code (and even unsafe Rust). There’s a big difference between 100% success rate and 1/16th - while you will still get an exploit through a 1/16th chance, the chances of detection raise significantly which isn’t nothing in a security context as it leaves a trail of breadcrumbs to investigate.
> It will take more fundamental mitigations that address the root issue of memory corruption, like MTE, in order to dramatically raise the bar for attackers.
https://googleprojectzero.blogspot.com/2024/06/driving-forwa...
> Hardware memory tagging may fix some security pitfalls of C++, while still allowing high performance. We are looking forward to see a more broad adoption of hardware memory tagging in the future and suggest using Scan on top of hardware memory tagging to fix temporary memory safety for C++
https://security.googleblog.com/2022/05/retrofitting-tempora...
Of course MTE + Scan described above may not be vulnerable to this attack, but my point stands that MTE is very much viewed as a memory safety hardening feature (and thus the security implications that come with safety hardening).
This isn’t that bad news either. It may leave existing chips vulnerable but the next iteration of MTE will probably account for this problem (assuming you can’t patch microcode to solve this).
Are Google really pushing it a 'proper' security feature? You've quoted a line at the end of a blog that doesn't elaborate further. In the android documentation for instance it stats '[MTE] helps detect use-after-free and buffer-overflow bugs': https://source.android.com/docs/security/test/memory-safety/... without making any stronger claims.
> This isn’t that bad news either. It may leave existing chips vulnerable but the next iteration of MTE will probably account for this problem (assuming you can’t patch microcode to solve this).
I might argue fixing is is actively bad. Helps push the idea this is a feature to actually use for security rather than augment bug detection. Still fixing it shouldn't be too hard, just speculate as you do currently but always assume the tag check passes so you get the same speculative behaviour regardless of tag values (likely easier said than done of course, probably some fun corner cases where they'd still differ).
2 replies →
The difference between 100% reliability and 7% reliability in this environment might exceed a million dollars.
I totally agree. The authors have found a security vulnerability in a mechanism that wasn’t even trying to protect the software from attacks. I don’t see any relevance in this paper except being a good exercise
The authors' hypothesis about the STLF case:
> Considering the affected core (i.e., Cortex-A715) dispatches 5 instructions in a cycle [ 55], it is likely that the CPU cannot detect the dependency if the store and load instructions are executed in the same cycle, since the store information is not yet written to the internal buffers.
> If Len(GAP) is 4 or more, the store and load instructions are executed in the different cycles, and the CPU can detect the dependency. Therefore, the CPU skips the tag check and always forwards the data from the store to load instructions.
> If Len(GAP) is less than 4, the store and load instructions are executed in the same cycle, and the CPU fails to detect the dependency and performs the tag check for the load instruction. In this case, the forwarding is blocked on tag check faults.
This would mean there's no forwarding from stores to loads within the same dispatch group on these cores?
> No problem, I was told, it’s not intended as a mitigation technique, it’s intended for at-scale debugging. Then certain companies decided it was a security technology.
Yeah and it did work well for that usecase. https://grapheneos.social/@GrapheneOS/112066872276203917
[dead]
My brain automatically thought this is "TikTok" -> Why would they release research on security if they are being targeted for security concerns
> Why would they release research on security if they are being targeted for security concerns
Hmm. That doesn’t really follow IMO.
Every big corporation needs to have information security people. And most of them probably do some form of research as well. That’s the only way to stay on top of information security.
Whether they publish anything or not is up to them. But it’d be super silly to base the decision for that on the fact that USA government is banning TikTok.
By that line of argument, couldn’t you just as well say that they shouldn’t reveal that they hire infosec people either? Yet for example at https://careers.tiktok.com/m/position?category=6704215862603... they have several job openings relating to infosec such as this one: https://careers.tiktok.com/m/position/7379470900063095078/de...
> The Global Security Organization provides industry-leading cyber-security and business protection services to TikTok globally. Our organization employs four principles that guide our strategic and tactical operations. Firstly, we Champion Transparency & Trust by leading the charge in organizational transparency, prioritizing customer trust, and placing user needs first. Secondly, we aim to maintain Best in Class Global Security by proactively identifying and reducing risks while enabling innovative product development. We constantly work towards a sustainable world-class security capability. Thirdly, we strive to be a Business Catalyst & Enabler by embodying the DNA of technical innovation and ensuring our Global Security operations are fast and agile.
Heck here they even say just that: “proactively identifying and reducing risks while enabling innovative product development”. A natural part of that would be doing for example the kind of security researcher that the article of the OP is about.
Going to need another one of these, Xe: https://xeiaso.net/shitposts/no-way-to-prevent-this/CVE-2024...
This is not a bug caused by memory unsafe languages.
No, this is a feature created for memory-unsafe languages which has turned out to be yet another memory safety attack vector. But there's no way to prevent this.
5 replies →
The only exception is if the microcode responsible for this was written in C somehow. I highly doubt it though.
1 reply →
That's the point. /s