Lord of the Ring(s): Side Channel Attacks on the CPU On-Chip Ring Interconnect (currently Intel only)

[kvuj]

Summary

A completely new type of attacks has been devised which are specific to Intel CPUs (it may be possible to port to other CPUs, but requires reverse engineering of a CPU's on-chip interconnect). This whole new class of attack ignores previous ways to prevent such papers attacking CPU architectures (such as disabling SMT, cleansing microarchitectural state when context switching, etc). 

 

The attack comes from reverse engineering the ring interconnect's protocol in order to reveal the conditions for 2 processes that will incur ring contention. It can be used to leak key bits from vulnerable EdDSA/RSA implementations and also allows the attack to get the timing of keystrokes which can be used to reconstruct passwords.

 

To protect your program against it, you have to make your code timing-attack free (follow constant-time programming principles). 

 

Quotes

Quote

A side-channel secure implementation will not be vulnerable to the current state of being in the Cache-Ring attack. However, achieving that may not be an easy job since Intel CPUs perform hardware store elimination between the private caches and ring interconnect ( see Hardware Store Elimination)

Quote

In this paper, we introduced side channel attacks on the ring interconnect. We reverse engineered the ring interconnect’s protocols to reveal the conditions for two processes to incurring contention. We used these findings to build a covert chan-nel with a capacity of over 4 Mbps, the largest to date for cross-core channels not relying on shared memory. We also showed that the temporal trends of ring contention can be used to leak key bits from vulnerable EdDSA/RSA implemen-tations as well as the timing of keystrokes typed by a user. We have disclosed our results to Intel.

Quote

Intel classifies our attack as a “traditional sidechannel” because it takes advantage of architecturally commit-ted operations [47]. The recommended line of defense against this class of attacks is to rely on software mitigations, and par-ticularly on following constant-time programming principles (...) However, a more comprehensive understanding of hardware optimizations is needed beforewe can have truly constant-time code.

 

My thoughts

Woohoo, another vulnerability that takes advantages of hardware design, so it can't be patched. Even if we might be tired of hearing about yet another one, the depth and ingenuity of these always impress me. Even if I can't understand everything in the paper, it's a super interesting read and a reminder of the complexity of CPUs.

 

This type of attack is currently very early in its design so it is unknown how bad it is in the grand scheme of things. I'm not super worried about the consequences of this since it will probably patched quickly in the handful programs needing a fix, but it is always interesting to remind ourselves that hackers will never stop sharpening their fangs. As such the security of systems needs to constantly evolve to keep up with the increased hostility of attacks.

 

If this decade has thought us anything, is that CPU designs need to recieve extra care during their infancy to protect against such attacks.

 

Sources

https://arxiv.org/pdf/2103.03443.pdf (Paper from USENIX Security 2021)

https://github.com/FPSG-UIUC/lotr (PoC source code)

https://crypto.stackexchange.com/questions/88724/what-is-the-lord-of-the-rings-side-channel-attack-and-what-are-the-results#88727

 

[Salv8 (sam)]

yay...

[StDragon]

"One Ring-0 to rule them all, One Ring-0 to find them,
One Ring-0 to bring them all, and in the darkness bind them"

[Jet_ski]

Oh Intel.

[Fnige]

Spoiler

yes its a pic

Spoiler

or is it?

 

 

[Helpful Tech Witch]

Amds not on top yet. We would know when amds on top when it's not "this only works on Intel but might be able to be ported", but "this only works on amd but we might be able to Port it.

[kvuj]

1 hour ago, HelpfulTechWizard said:

Amds not on top yet. We would know when amds on top when it's not "this only works on Intel but might be able to be ported", but "this only works on amd but we might be able to Port it.

Yup. Targeting Intel is often preferred because of the amount of their CPUs in the wild. 

 

However, let's not forget 2 things:

- AMD's interconnect is completely different from Intel which may or may not prevent this sort of attack. (I don't think so since it would probably require them having a fundementally different way cache is controlled)

- This paper is extremely technical, which I imagine is outside of the reach of most script kiddies trying to get your credit card.

 

Also:

Quote

For example, recent server-class Intel CPUs utilize mesh interconnects [58], which consist of a 2-dimensional array of half rings. Traffic on this grid-like structure is always routed vertically first and then horizontally. More wires may make it harder for an attacker to contend with a victim.

 

It's unclear if ARM SOC makers and IBM POWER CPUs are (could?) be affected. Since it's specific to the way Intel uses its private cache and their LLC.

[dizmo]

Is this actually a problem though, or is it another vulnerability that requires the attacker to actually have physical access to the machine?
I feel most of these vulnerabilities are blown way out of proportion.

[Arika]

11 minutes ago, dizmo said:

Is this actually a problem though, or is it another vulnerability that requires the attacker to actually have physical access to the machine?
I feel most of these vulnerabilities are blown way out of proportion.

from my quick skim of the paper, it CAN be done remotely, but through an SSH connection, which, much like physical access, if someone has the ability to SSH into your PC, you're already fucked.

 

edit: also there is a lot of things that need to happen if a very very specific way with such precise timings, that i don't see this as being one that will actually show up in the wild.

[dizmo]

12 hours ago, Arika S said:

from my quick skim of the paper, it CAN be done remotely, but through an SSH connection, which, much like physical access, if someone has the ability to SSH into your PC, you're already fucked.

 

edit: also there is a lot of things that need to happen if a very very specific way with such precise timings, that i don't see this as being one that will actually show up in the wild.

Haha, yeah. I kind of figured. I just hate seeing everyone jump on it and trash Intel like it's something that's going to cause so much headache for the average user.

I don't fanboy for one side or the other (though I definitely have preferences), but seeing it all the time gets old.

5 hours ago, valdyrgramr said:

This is like the second main one that doesn't require physical access, but is somewhat overexaggerated.   Apparently Intel listed this as nothing more than a normal side channel attack, and already has guides on how to mitigate them.  So, while you don't need physical access this is nothing more than a minor headache at best.

Are the guides easy to follow? Or is the "fix" convoluted? Not that I'd bother, just curious.