AMD's trusted execution environment blown wide open by new BadRAM attack | Hacker News Reader

AMD's trusted execution environment blown wide open by new BadRAM attack

arstechnica.com

144 pointsalecco45 comments

Open articleView on HN

"The BadRAM attack – which does require physical access to hardware"

so...academically "blown wide open" but for anyone with a cogent opsec, probably not the end of the world.

the tee also "protects" parties trusted by the manufacturer from the owner

That is useful because many computers are portable which means they can be stolen.

Well right, they can't be stolen from you because they were not yours to begin with :)

Suppose that a portable computer uses full disk encryption. On boot it requires a long passphrase, or requires a short passphrase and connects to a remote server to supply a long decryption key but the remote server rate limits attempts. Either of these are rare because the system is normally on or in suspend rather than being cold booted, and once on the operating system rate limits local unlock attempts.

What is the TEE supposed to buy you over this? Avoiding the negligible inconvenience of typing the long passphrase once a month if you don't have a remote server, which the enterprises that demand features like this would have? That seems like more of a solution in search of a problem and in any event not worth the cost in authoritarianism.

Not only that, the TEE solution is less secure. If the device is stolen and you revoke access on the remote server then there is no way for an attacker with only the device to get the key. If the key is in a TPM on the device they can stick the device in a drawer and wait until someone finds a TPM vulnerability, then unlock it.

A boot password + disk encryption helps but

a) they can attack it before it reboots.

b) most of the value is in the parts, so they don't need your data. You need to make the parts useless for repairs so it's not worth stealing it.

> they can attack it before it reboots.

But they can do that anyway? If they would guess your password or exploit your OS from the lock screen then they get access to your files even if the running OS is the one certified by the hardware.

> most of the value is in the parts, so they don't need your data. You need to make the parts useless for repairs so it's not worth stealing it.

Putting aside that "make the parts useless for repairs" is an obvious misfeature that will be used against you by the manufacturer, it's also orthogonal to boot loader signing etc.

Making the parts "useless for repairs" would also be better achieved by making new and used repair parts available for competitive prices, driving down the cost of repairs to the point that stealing devices for repair parts isn't a lucrative endeavor. For example, make sure that traded-in devices never get crushed if they could be scavenged for parts to be sold into the repair market, providing a plentiful supply of used parts instead of making them scarce enough to be worth stealing.

Physical access is one of the things that a trusted execution environment is supposed to protect against. It's one of the major reasons to use a TEE instead of just normal VM isolation.

If I were holding billions of dollars of bitcoin keys for a darknet drug market, I would not trust a TEE...

A TEE restricts attackers to nation-state and similar actors today, and is probably no hurdle at all in 5-10 yrs when some attack like this is published and the hardware is unpatchable.

Academics break TEE’s on a regular cadence. There’s this article, for example. A while back, there was clkscrew.

I don’t get the impression these classes of attacks will ever be patchable.

> Physical access is one of the things that a trusted execution environment is supposed to protect against

Is supposed to. Because money are sweet. Physical access means that you can exchange any part of your system and the bloody TEE would have no idea that it is MITM.

The whole feature is advertised as something hypervisor operators can use to show customers that their data and code is safe from interference by these operators. Basically, it's about separating physical access to the hardware from access to the computation that occurs on the hardware, and the data that is processed there. This means that such attacks are relevant for once.

I have my doubts whether this can ever work reliably. It seems risky to bet a lot of infrastructure investment on the fact that attacks like this one (or even better ones) do not happen. But the entire hypervisor business has the same structural problem (a bad CPU bug like the T-Head C910 vector issue could turn your hypervisor fleet into very expensive single-tenant machines over night), and yet here we are …

The entire point is to protect against those (like the owner of the hardware) who have physical access.

So basically this is the best kind of vuln; not exploitable remotely, and unpatchable so you will always be able to get root on your own hardware.

AMD has patches for all impacted platforms, and a method to verify that patch has been applied.

a method that can't be spoofed though?

TAO tho...

I think this type of implements are also used to make payments work on devices, in addition to enabling DRM.

In that case it doesn't seem it's really the "owner" of that hardware..

The operators own the hardware and lease it to customers for computation. Those customers do not trust the operators to not peek at their Super Sensitive Data. TEE is a way for the operator to provide assurances to their customers that they will not, and more importantly cannot, exfiltrate customer data.

This is in theory. In practice, as demonstrated by the article, these assurances are not bulletproof.

This makes sense for enterprise use cases, but then the soc manufacturer shouldn't be able to do this as well.. otherwise customers still need to trust the manufacturer.

So I was referring to the case where there exists an entity that has some equivalent of "private keys" that makes it possible to control the TEE/attestation..

Ah that makes sense.

I would think as long as the manufacturer and the operator are not the same entity then the danger in that regard would be mitigated.

> In some cases, with certain DIMM models that don't adequately lock down the chip, the modification can likely be done through software.

So on some systems, the hack could be performed entirely remotely.

The whole purpose of TEEs and confidential computing is to prevent the people with your server from seeing what you're doing on it.

This is somewhat relevant for DRM. All those downloads from netflix/prime/disney plus depend on breaking into a TEE and retrieving decryption keys.

In modern threat models, this is a malicious insider and hardly some exotic circumstance. If you're running a data center in an authoritarian country, you probably care.

> If you're running a data center in an authoritarian country, you probably care.

You should care also about democratic countries. For your own good.

All these "trusted" environments are meant to be used by DRM, copy protection, manufacturer backdoors, etc, so it is only better if they are compromised.

Regarding processing sensitive data in the cloud, just don't do it.

These server based TEEs are not solely for the benefit of cloud consumers, but end users as well.

You could theoretically ensure your dental appointment booking platform is not keeping tabs on you.

Was there a secure enclave that determined people didn't find bugs in? I remember the modding community around old Motorola phones before Android was a thing, they obviously had a secure loader, write once memory to prevent downgrades, signed firmwares and all that, yet each and every version was bugged in one way or another. From sofisticated ones to "just keep writing despite the driver signaling error" kind of ones.

Using a separate processor (eg HSM or hardware wallet) is still the only secure enclave that hasn't been broken, and even some of those have been broken.

I’m not sure anyone involved in this space seriously believed in the physical attack resistance TDX/SNP. At least not yet. The attack surface is just so vast.

This reads like yet another overhyped named vulnerability.

These tools are a fence. The fence started out pretty short with AMD’s original SEV and has been getting taller since.

Taking the software operators out of the trust boundary is still (comparatively) viable despite this type of attack. And, if the cloud provider sends you attestations proving your workload is in their Real Deal data center with actual guards, cameras, and compliance operations, I’d expect this specific attack to be irrelevant.

——————

Only had a quick skim at the paper. Looks like they are mucking with the DDR sticks to make aliasing possible, which lets them circumvent integrity protection.

I thought circumventing integrity was already possible-ish with rowhammer and SNP? SNP doesn’t store integrity bits anywhere so it can’t even pretend to catch changes in dram.

That whole song and dance about protection from an untrusted cloud operator sounds like a red herring to me. CSPs are the ones to deploy the technology. I suspect their main desire is to (a) avoid the hassle of law enforcement requests, as one cannot grant access to keys one does not have and (b) allay would-be customer concerns around cloud hosting versus on-prem deployments. Maybe (c) is to support compliance and regulatory checkboxes. TEEs are not about security, rather about security liability. Academic attacks are indeed just that, and not necessarily expected to be seen in the wild or affect security posture.

>CSPs are the ones to deploy the technology

The idea behind this whole paradigm is that you can verify the technology the CSP is running.

I agree with you on the CSP motivations.

True. Notwithstanding, I can verify that the technology stack is too complex to secure.

The BadRAM thing is interesting -- shouldn't this be easy to catch with a memory test?

Chip lies that it's twice as big as it is, so just check if something you write to 0x0001 shows up at 0x1001

Actually a bit surprising that modern boards don't do enough testing to catch this from the start -- checking that the address lines are working should take pretty much no time and would be a good check for whether a module is making good contact on all the pins.

You're trying to catch the specific implementation of the attack rather than the general attack. Suppose they don't lie about the size of the memory, instead they find a way to mask out one of the address bits so reads from higher addresses go to lower addresses or vice versa. Which they can change in hardware at runtime after you've done whatever checks you want and which doesn't necessarily have to be the most significant bit.

Oh, I'm sure, but this just seems like an oddly simple exploit that seems to rely on things that almost look like they shouldn't work.

Like you'd think things like address lines being shorted together, or not being connected, or such things would be simple to test for in a millisecond or two, and be a logical part of a basic test of functionality that just checks that everything seems to be wired up right.

That's quite neat; SNP has a pretty complex system for avoiding multiple mappings (the RMP aka Reverse Map Table); this nicely walks around it :-)

If a nation state wants to hack your shit, they will. And if they can't hack you, they have a rubber hose. The best possible defense you have is to not be on their radar to begin with.

Ah the good ole 'Dont outrun the bear, outrun the slowest camper defense'. these type of absolutist thinking ignores the various degrees you can make things harder so they are not economical to do en-mass or at least unfeasible for random govt departments.

you think they're going to hack Amazon "en-mass" by installing faulty ram in every rackmount server?

I, too, would like to offer here my unconditional surrender of my SEV enclaves to the Montenegro immigration service.

Rubber hose is the last thing they try before this exploit. There are dozens of side channels that are easier and cheaper.

The explanation paints a picture of an elegant hack.

Reply on news.ycombinator.com