6 ms·
Battering RAM – Low-cost interposer attacks on confidential computing
- schoen 1y agoI think I talked about this possibility with Bunnie Huang about 15 years ago. As I recall, he said it was conceptually achievable. I guess it's also practically achievable!
- no_time 1y agoI find it reassuring that you can still get access to the data running on your own device, despite all the tens of thousands of engineering hours being poured into preventing just that.
- throawayonthe 1y agoI doubt you own hardware capable of any of the confidential computing technology mentioned
- kedihacker 1y agoWell microcontrollers can prevent you from repairing your own device with DRM and secure enclaves
- deleted 1y ago[deleted]
- deleted 1y ago[deleted]
- no_time 1y agoMy 2017 bottom shelf lenovo has SGX whether I like it or not. In current year you can't really buy new hardware without secure enclaves[0], be it a phone, a laptop or server. Best you can do is refuse to run software that requires it, but even that will become tough when goverments roll out mandatory software that depends on it. [0]: unless you fancy buying nerd vanity hardware like a Talos POWER workstation with all the ups and downs that come with it.
- RedShift1 1y agoPretty sure you can turn off SGX in the BIOS?
- da768 1y agoIntel killed SGX on consumer CPUs a while ago https://news.ycombinator.com/item?id=31047888 https://news.ycombinator.com/item?id=31047888
- heavyset_go 1y agoIntel TXT is another related trusted execution/attestation/secure enclave feature, not sure how prevalent that one is, though
- deleted 1y ago[deleted]
- Simple8424 1y agoIs this making confidential computing obsolete?
- Harvesterify 1y agoIn their current form, AMD and Intel proposals never fulfilled the Confidential Computing promises, one can hope they will do better in their next iteration of SGX/TDX/SEV, but they were always broken, by design.
- dist-epoch 1y agoThat's like saying a security vulnerability in OpenSSL/SSH is making SSL/SSH obsolete.
- JW_00000 1y agoIt's a bit more fundamental in my opinion. Cryptographic techniques are supported by strong mathematics; while I believe hardware-based techniques will always be vulnerable against a sufficiently advanced hardware-based attack. In theory, there exists an unbreakable version of OpenSSL ("under standard cryptographic assumptions"), but it is not evident that there even is a way to implement the kind of guarantees confidential computing is trying to offer using hardware-based protection only.
- dist-epoch 1y agoProof of existence does exist. Some Xbox variant has now been unbroken (jailbroken) for more than 10 years. And not for lack of trying. Credit/debit cards with chips (EMV) are another proof of existence that hardware-based protection can exist. > It is not evident that there even is a way to implement the kind of guarantees confidential computing is trying to offer using hardware-based protection only. Not in the absolute, but in the more than $10 mil required to break it (atomic microscopes to extract keys from CPU gates, ...), and that to break a single specific device, not the whole class.
- 1y ago
- fweimer 1y agoI'm kind of confused by AMD's and Intel's response. I thought both companies were building technology that allows datacenter operators to prove to their customers that they do not have access to data processed on the machines, despite having physical access to them. If that's out of scope, what is the purpose of these technologies?
- Harvesterify 1y agoSecurity theater, mostly.
- hbbio 1y agoTEEs don't work, period. FHE does (ok, it's much slower for now).
- LPisGood 1y agoWhy do you say TEEs don’t work at all?
- treyd 1y agoTEEs, as they're marketed, requires a true black box. True black boxes do not exist, as a property of the rules of our universe. You can ALWAYS break them, it's just a matter of cost, even assuming they're perfectly designed and have no design/implementation flaws. And they're often not perfectly designed, sometimes requiring no physical hardware tampering.
- rossjudson 1y agoThe point of security efforts is to make an attacker's life harder, not to construct perfect defenses (because there's no such thing, as you've noted). TEEs make attacker's lives harder. Unless you can find a way to make your interposer invisible and undetectable, the value is limited.
- fpoling 1y agoQuantum mechanics with its non-copy property implies that a true black box can be created.
- matja 1y ago> No, our interposer only works on DDR4 Not surprising - even having 2 DDR5 DIMMs on the same channel compromises signal integrity enough to need to drop the frequency by ~30-40%, so perhaps the best mitigation at the moment is to ensure the host is using the fastest DDR5 available. So - Is the host DRAM/DIMM technology and frequency included in the remote attestation report for the VM?
- seg_lol 1y agoAll of that info is faked. You should never trust a cloud vm. That is why it is called "public cloud".
- matja 1y agoThe attestation report is signed by a key in the PSP hardware, not accessible by any OS or software, which can then be validated with the vendor's certificate/public-key. If that can be faked, are you saying that those private keys are compromised?
- heavyset_go 1y agoI'm willing to bet if you ran terrorism-as-a-service.com on a protected VM, it wouldn't be secure for long, and if it really came down to it, the keys would be coughed up.
- 1oooqooq 1y ago[flagged]
- michaelt 1y ago> If that can be faked, are you saying that those private keys are compromised? As I understand it, the big idea behind Confidential Computing is that huge American tech multinationals AWS, GCP and Azure can't be trusted. It is hardly surprising, therefore, that the trustworthiness of huge American tech multinationals Intel and AMD should also be in doubt.
- Aurornis 1y ago
- commandersaki 1y agoI like how the FAQ doesn't really actually answer the questions (feels like AI slop but giving benefit of the doubt), so I will answer on their behalf, without even reading the paper: Am I impacted by this vulnerability? For all intents and purposes, no. Battering RAM needs physical access; is this a realistic attack vector? For all intents and purposes, no.
- JW_00000 1y agoYou're twisting their words. For the second question, they clearly answer yes. It depends on the threat model you have in mind. If you are a nation state that is hosting data in a US cloud, and you want to protect yourself from the NSA, I would say this is a realistic attack vector.
- commandersaki 1y agoI haven't twisted their words, they didn't actually answer the question, so I gave my own commentary. For all intents and purposes, as in practically speaking, this isn't going to affect anyone*. The nation state threat is atypical even to those customers of confidential computing, I guess the biggest pool of users being those that use Apple Intelligence (which wouldn't be vulnerable to this attack since they use soldered memory in their servers and a different TEE). Happy to revisit this in 20 years and see if this attack is found in the wild and is representative. (I notice it has been about 20 years since cold boot / evil maid was published and we still haven't seen or heard of it being used in the wild (though the world has kind of moved onto soldered ram for portable devices). * They went to great lengths to provide a logo, a fancy website and domain, etc. to publicise the issue, so they should at least give the correct impression on severity.
- Simple8424 1y agoThere is clearly a market for this and it is relevant to those customers. The host has physical access to the hardware and therefore can perform this kind of attack. Whether they have actually done so is irrelevant. I think the point of paying for confidential computing is knowing they cannot. Why do you consider physical access not a realistic attack vector?
- munchlax 1y agoDupe of: https://news.ycombinator.com/item?id=45439286 https://news.ycombinator.com/item?id=45439286 11 points by mici 4 days ago
- rhodey 1y agoI hope people dont give up on TEE, see AWS Nitro The AWS business is built on isolating compute so IMO AWS are the best choice I've built up a stack for doing AWS Nitro dev https://lock.host/ https://lock.host/ https://github.com/rhodey/lock.host https://github.com/rhodey/lock.host With Intel and AMD you need the attestation flow to prove not only that you are using the tech but you need to attest to who is hosting the CPU With Amazon Nitro always Amazon is hosting the CPU
- addaon 1y agoThis seems pretty trivial to fix (or at least work around) by adding an enclave generation number to the key initialization inputs. (They mention that the key is only based on the physical address, but surely it has to include CPUID or something similar as well?) Understood that this is likely hardware key generation so won’t be fixed without a change, and that persistent generation counters are a bit of a pain… but what else am I missing?
- Veliladon 1y agoNeed to go Apple style where the AES engine is on die. Only the AES engine and the Secure Enclave know the decryption keys. The CPU doesn't know the decryption key. Nothing is sent in clear text over the bus.
- mike_hearn 1y agoThat's how it works already. The memory is encrypted. However, the SGX/SEV model is a very powerful and flexible one - different entities who don't trust one another can share the same hardware simultaneously. If you encrypt all of RAM under a single key, then you can start up a malicious enclave, do some writes - which the CPU will encrypt - capture those writes and redirect them to the memory of a different enclave, and now you can overwrite the memory of that other enclave with your own cleartext. That such attacks are possible was known from the start. What they're doing here is exploiting the fact that Intel (knowingly!) enabled some hardware attacks on SGX in order to allow enclaves to scale up to much larger amounts of RAM consumed.
- exabrial 1y agoPhysical access owns. If the computer can’t trust its components what can it do?
- acidburnNSA 1y agoDamn. I was hoping that confidential compute could allow nuclear reactor design work (export controlled, not classified) to go into the public cloud and avoid the govcloud high premium costs. But this kind of takes the wind out of the idea.
- mike_hearn 1y agoNot a great paper, hence why the "advisories" are so short. All they've done is show that some products meet their advertised threat model. Intel has a solution: upgrade your CPU. AMD do not. Once again Intel are ahead when it comes to confidential computing. The story here is a little complex. Some years ago I flew out to Oregon and met the designers of SGX. It's a good design and it's to our industries shame that we haven't used it much, as tech like this can solve a lot of different security and privacy problems. SGX as originally designed was not attackable this way. This kind of RAM interposer attack was anticipated and the hardware was designed to block it by using memory integrity trees, in other words, memory was not only being encrypted by the CPU on the fly (cheap) but RAM was also being hashed into a kind of Merkle tree iirc which the CPU would check on access. So even if you knew the encryption key, you could not overwrite RAM or play games with it. It's often overlooked but encryption doesn't magically make storage immutable. An attacker can still overwrite encrypted data, delete parts, replay messages, redirect your write requests or otherwise mess with it. It takes other cryptographic techniques to block those kinds of activities, and "client SGX" had them (I'm not sure SEV ever did). This made sense because SGX design followed security best practices, namely, you should minimize the size of the trusted computing base. More code that's trusted = more potential for mistakes = more vulnerabilities. So SGX envisions apps having small trusted "enclaves", sort of like protected kernels, that untrusted code then uses. Cryptography ties the whole thing together. In a model like this an enclave doesn't need a large amount of RAM because the bulk of the app is running outside of the TCB. Unfortunately, at this point Intel discovered a sad and depressing but fundamental truth about the software industry: our tolerance for taking on additional complexity to increase security rounds to zero, and the enclave programming model is complex. The number of people who actually understand how to use enclaves as a design primitive can probably fit into a single large conference room. The number of apps that used them in the real world, in a way that actually met some kind of useful threat model, I'm pretty sure is actually near zero [1]. This isn't the fault of SGX! From a theoretical perspective, it is sound and the way it was meant to be used is sound. But actually exploiting it properly required more lift than the software industry could give. For example, to obtain the biggest benefits (SaaS you can use without trusting it) would have required some tactical changes to web browsers, changes to databases, changes to how such apps are designed and so on. Nobody tried to coordinate such changes and Intel, being a business, could not afford to wait for a few decades to see if anyone picked up the ball on that (their own software engineering efforts were good as far as they went but not ambitious enough to pull off the vision). Instead what happened is that potential customers said to them (and AMD): look, we want extra security, but we don't want to make any effort. We want to just run containers/VMs in the cloud and have them be magically secure. Intel looked at what they had and said OK, well, um, I guess we can maybe run bigger apps inside enclaves. Maybe even whole VMs. So they went away and did a redesign, but then they hit a fundamental physics problem: as you expand the amount of encrypted and protected RAM the Merkle tree protecting its integrity gets bigger and bigger. That means every cache miss has to recursively do a tree walk to ensure the data read from RAM is correct. And that kills performance. For small enclaves the tree is shallow and the costs aren't too bad. For big enclaves, well ... the performance rapidly becomes problematic, especially as the software inside expects to be running at full speed (as we are no longer designing with SGX in mind now but just throwing any old stuff into the protected space). So Intel released a new version gamely called "scalable SGX" which scaled by removing the memory integrity tree. As the point of that tree was to stop bus interposer attacks, they provided an updated threat model that excluded them. The tech is still useful and blocks some attacks (e.g. imagine a corrupted developer on a cloud hypervisor team). But it was no longer as strong as it once was. Knowing this, they set about creating yet another memory encryption tech called TME-MK which assigns each memory page its own unique encryption key. This prevented the kind of memory relocation attacks the "Battering RAM" interposer is doing. They also released a new tech that is sort of like SGX for whole virtual machines, formally giving up on the idea the software industry would ever actually try to minimize TCBs. Sad, but there we go. Clouds have trusted brands and people aren't bothered by occasional reports of global root exploits in Azure. It would take a step change event to get more serious about this stuff. [1] You might think Signal would count. Its use of SGX does help to reduce the threat from malicious or hacked cloud operators, but it doesn't protect against the operators of the Signal service themselves as they control the client.