9 ms·
Plundervolt: Software-Based Fault Injection Attacks Against Intel SGX [pdf]
- ddtaylor 7y agoDoes anyone have a ELI5 explanation?
- taspeotis 7y agohttps://arstechnica.com/information-technology/2019/12/scientists-pluck-crypto-keys-from-intels-sgx-by-tweaking-cpu-voltage/ https://arstechnica.com/information-technology/2019/12/scien...
- xucheng 7y agoIntel SGX is a Secure Enclave embedded in Intel CPU, which aims to provide secure and trust computation environment. For example, storing and processing cryptography secret keys, etc. It is similar to the enclave in Apple A chips used in Touch ID/Face ID. Currently, there is no wide adoption of SGX in the production environments, mainly due to the attacks like this. In this attack, the researchers found that by adjusting the voltage and clock frequencies of the CPU, they are able to generate errors inside SGX enclave and recover the secret keys inside.
- mehrdadn 7y ago> Currently, there is no wide adoption of SGX in the production environments, mainly due to the attacks like this. How long have these attacks been around? I only started hearing about them maybe like... in the past week or so? Nothing remotely close to explaining why these aren't used in production.
- saagarjha 7y agoThere are other attacks (https://arxiv.org/pdf/1802.09085.pdf https://arxiv.org/pdf/1802.09085.pdf), but I doubt they’re the major driving force behind lagging adoption.
- Legogris 7y agoIME lack of adoption is more due to lack of tooling and integration with popular languages and libraries. Also, the domains that have the most to benefit from SGX (heavily regulated ones like healthcare) tend to be very slow adopters of new technology. I guess there is definitely some level of concern for sidechannel attacks, given Intel's track record, but I don't think that's whats been holding back adoption.
- saagarjha 7y agoHow could healthcare benefit from SGX?
- Legogris 7y agoStrengthened protection for patient data.
- throwaway2048 7y agoIt also requires a very expensive license from intel, and to allow them partial control of your code via codesigning.
- thu2111 7y agoNo it doesn't. Getting a whitelisted code signing key just requires you to agree that you won't distribute malware. You pay nothing for it and Intel don't see the code you sign. Please don't make things up because they "sound right".
- dboreham 7y agoAre there non-Intel remote attestation servers now?
- thu2111 7y agoOnly Intel know what chips they've manufactured and what microcode patch levels are currently considered secure, so that wouldn't make much conceptual sense. But the new DCAP feature lets you run some of the RA infrastructure yourself, yes.
- Legogris 7y agoSGX is Intel's TEE (Trusted Execution Environment) platform, where an isolated memory address space (aka enclave) can host applications which give certain guarantees: * No outside code can gain access to any part of it - not even the host OS * Applications run precisely as executed (binaries need to be chryptographically signed) You could generate cryptographic keys inside the enclave and ensure that the private key is never seen in cleartext outside it. Let's say you're building a SaaS product to host sensitive data and expose an API. Using SGX, the remote endpoint can be ensured of the above. Root keys are signed by Intel (and recently delegated to cloud providers) - so there is some element of trust there. This attack uses power management interfaces to the hardware to induce faults in computations in the enclave, leading to data leaks. In the example above, the machine operator (or someone who gained privileged access on their machine) could abuse this to get access to sensitive data that's supposedly only inside the enclave. In any case and even in the absence of these threat vectors, SGX and similar solutions should be used as a layered security approach, not something to rely solely upon.
- josh2600 7y agoYeah, this is exactly correct. Sgx is not a silver bullet, at all. It’s a part of a security story.
- ljhsiung 7y agoIntel SGX is an enclave, or a hardware supported mechanism to store keys/do protected operations (most often implemented as essentially a co-processor). For example, if you want to run some AES operation, you would send it off into the enclave. More on faults-- A "fault attack" (I like to call them active attacks) is an attack where someone actively tampers with a device to "force" it into an "unreachable" state. An example of an "unreachable" state might be, for a single cycle, cutting off the voltage to a flip-flop to prevent a bit from being written. Contrived example, but enough to get the idea of "fault" in your head hopefully. Intel SGX is heavily advertised as being fault-resistant (although in recent years, time and time again it has shown to not be the case!). This is especially crucial because some crypto algorithms (e.g. RSA-CRT and AES in general) heavily rely on zero/minimal faults due to the nature of how these algorithms are constructed. RSA-CRT, for example, only needs a single fault in its algorithm for the private key to be compromised. CPU design today will also typically employ frequency or voltage scaling based on workload as a power saving metric-- say, if the CPU is idle. They will also make this ability software-visible, as it's quite handy for general uses as a whole. The researchers here exploit this ability to "cut the voltage" from software in the CPU to directly affect SGX as well, resulting in faults in the underlying operations. While fault attacks (especially timing ones) on SGX are nothing new, the shocker frankly is how they did the fault attack. Typically, in my experience, whenever someone says "power fault attack" you might envision someone with physical access to the chip "glitching" the clock or VCC to bypass some verification step, maybe in a lab or using a ChipWhisperer. This is obviously not the case here-- this is the first case of software power glitching I've seen (note that software clock glitching was done a few years back, but not on Intel machines I believe). I feel the need to point out that this isn't a fault (pun intended) of Intel's design-- OK maybe it is a little bit since this does fall under the SGX-type threat model, but I feel like this would more be an industry wide issue for any system with an actual hardware enclave (looking at you Apple), so Intel is unlikely alone in the blame, in the same way that speculative execution was (and still is, in my opinion!).
- anonymousDan 7y agoIt's not particularly novel to be honest. Someone already did a very similar attack a few years ago on ARM Trustzone (see a paper called "CLKSCREW: Exposing the Perils of Security- Oblivious Energy Management"). It was pretty well known that type of attack is likely possible on SGX too.
- someguyorother 7y agoI wonder, with formal verification being a thing, could you formally verify that a chip would be resistant to all types of power attacks according to the current laws of physics? Such a proof can never be final, because the laws of physics aren't either. But just because it's not perfect doesn't mean it wouldn't be good.
- q3k 7y agoAn Intel CPU is a pretty large design. I'm not sure it's feasible to run all formal verification benchmarks on a full RTL design of the entire chip, including caches, memory controllers, etc. Not to mention - these sort of fault injection attacks are way past issues in high-level RTL, and instead are in the post-synethesis, analog/metastable domain specific to a given target process. Simulating those effects sounds prohibitively expensive, and I'm not sure there is any existing formal verification suite that can even do that. Unless someone modeled at a higher-level that modifying an MSR can cause undervolting, and then this undervolting can in turn cause bitflips to occur, this wouldn't have been caught. And if they did model it, they would have probably thought of this attack anyway :).
- kyboren 7y ago> An Intel CPU is a pretty large design. I'm not sure it's feasible to run all formal verification benchmarks on a full RTL design of the entire chip, including caches, memory controllers, etc. Agreed. It's still possible to verify smaller components of the design, though. > [...] These sort of fault injection attacks are way past issues in high-level RTL. [...] Simulating those effects sounds prohibitively expensive, and I'm not sure there is any existing formal verification suite that can even do that. It's possible to have a "high-level RTL" design that inherently resists some types of fault injection attacks. TMR is a trivial example: https://en.wikipedia.org/wiki/Triple_modular_redundancy https://en.wikipedia.org/wiki/Triple_modular_redundancy In fact, there is a wide body of literature studying the application of formal verification to side-channel and fault-injection analysis. Some systems can even synthesize a fault-injection resistant design. Unfortunately it is not realistic to be resistant to "all types of [fault injection] attacks according to the current laws of physics". We can, however, make different models of fault attacks and then prove (or synthesize) that some design is resistant to attacks in that model. If you're interested, look for publications in CHES, TCAD, FMCAD, DAC, DATE, etc. with keywords like "DFA", "DFIA", "SAT", "fault injection", etc.
- baybal2 7y agoThere is no such thing as a "trusted" computing. The very same DFVS is also possible to exploit for side channel attacks. Say, one branch makes the processor kick in in a higher gear, and over millions of branches, you can reliably deduce branch result for operation behind the MCU barrier.
- baybal2 7y agoDon't you think Intel's "fix" of disabling DVFS amounts to a post-release product downgrade?
- the_pwner224 7y agoAll their security fixes are. My 2 year old laptop feels noticeably slower in day-to-day usage now. I haven't tested it, but I would bet a small sum of money that it would go back to its original 2-year-ago performance with mitigations=off specified to Linux. If I can't undervolt anymore, then my laptop will be unable to run the CPU at 100% without thermal throttling. Not Intel's fault that Dell used a shitty cooling system and a too-high default voltage, but it's yet another penalty that I have to take because Intel failed.
- undersuit 7y agoIntel is playing a dangerous game if you ask me. AMD lost a class action lawsuit because someone was disappointed in the performance of an AMD chip even though all the performance metrics were available for them to research[1]. Intel is still selling hyper-threaded processors. You cannot buy an Intel laptop that isn't pre-configured to be vulnerable to Zombieload[2], unless you find one of the 4 obscure Intel chips like the Core i5-8500B Processor in a laptop [1] https://www.theverge.com/circuitbreaker/2019/8/28/20837336/amd-12-million-false-advertising-class-action-lawsuit-bulldozer-chips https://www.theverge.com/circuitbreaker/2019/8/28/20837336/a... [2]https://zombieloadattack.com/ https://zombieloadattack.com/
- wmf 7y agoI doubt they're disabling DVFS completely.
- xioxox 7y agoTerrible for those of us who use undervolting to keep their laptop as cool as possible. I hope they allow it enabled in the bios settings.
- jotm 7y agoFWIW, SGX is in Skylake and later. Time for AMD to shine I guess
- baq 7y agothe paper mentions TrustZone has (had?) similar issues: > In 2017, Tang et al. [65] discovered a software-based fault attack, dubbed CLK screw. They discovered that ARM processors allow configuration of the dynamic frequency scaling feature, i.e., overclocking, by system software. Tang et al. show that overclocking features may be abused to jeopardize the integrity of computations for privileged adversaries in a Trusted Execution Environment (TEE). Based on this observation, they were able to attack cryptographic code running in TrustZone. They used their attack to extract cryptographic keys from a custom AES software implementation and to overcome RSA signature checks and subsequently execute their own program in the TrustZone of the System-on-Chip (SoC) on a Nexus 6 device. it further notes though: > However, their attack is specific to TrustZone on a certain ARM SoC and not directly applicable to SGX on Intel processors. (ARM TrustZone is what AMD has in their chips)
- antpls 7y agoI did a quick search on the paper, didn't find "google" nor "titan", which is the secure chip made by Google. Would it be vulnerable too?
- qiqitori 7y ago> (ARM TrustZone is what AMD has in their chips) Well, I'll be damned: "The PSP itself is an ARM core inserted on the main CPU.[6]" (https://en.wikipedia.org/wiki/AMD_Platform_Security_Processor https://en.wikipedia.org/wiki/AMD_Platform_Security_Processo...) I'd imagine that the ARM core on the AMD CPU doesn't support changing the clock rate or anything much though.
- rasz 7y agoisnt Netflix using SGX for DRM?
- jotm 7y agoIntel just keeps getting kicked in the nuts, huh There is no way to get the most performance out of your Intel chip without undervolting - especially on mobile, they run really hot under constant load and often throttle. Manufacturers using barely capable heatsinks doesn't help. Time to switch to AMD when the new Zen mobile chips arrive.
- bayindirh 7y agoHonestly, I was considering to return to AMD while getting a new system. This is the final nudge for switching back. Thanks Intel, you really tried and succeeded.
- missosoup 7y agoThese kinds of brownout/undervolt attacks have been used in console cracking for decades. Surely someone involved would have known about that. I wonder what chain of events led to the creation of a secure enclave with such well understood flaws.
- baybal2 7y ago> Surely someone involved would have known about that. I wonder what chain of events led to the creation of a secure enclave with such well understood flaws. Don't you think that most engineers will just laugh the idea off, and do just enough to make their PMs happy? Such nebulous concepts as "secure enclave" only exist in imagination of MBA types. Even the name "enclave" sounds like it was picked by a seasoned talkshop person.
- HoochTHX 7y agoNaw. It's just the same age old issue of someone writing the design specs with the illusion it will be followed. Instead of designing it so that they can't not be followed.
- bradstewart 7y agoWhile the premise is similar, this is much different from the decades old brownout attacks. The researchers are causing the undervolt with software, not by manipulating the supply lines to the chip.
- missosoup 7y agoYes but not really? Intel just made it easier than oldschool hardware attacks: > adversary abuses an undocumented Intel Core voltage scaling interface Instead of having to buy hardware to mess with the power rail in a controlled manner, you can now just do it with a code snippet!
- bradstewart 7y agoAnd you can do it remotely. But the certainly made it easier because this is (presumably) behind the brownout detectors and other circuitry usually attached to the supply lines to combat this sort of stuff.
- eyegor 7y agoImportant caveats, for the lazy: - SGX is disabled by default, it has to be enabled for this exploit to be relevant - POC requires privileged execution, at which point you can safely assume all is already lost Anyone who has spent time around digital logic circuits will know that messing with voltages will cause errors. If the power lines are too low some transistors will not be able to switch their load. Or too high and you will cause parasitic losses or capacitance in unexpected places. This is actually a really nice attack to show off to people with an interest in computer/electrical engineering because it demonstrates how a basic design constraint can cascade in unexpected ways.
- xucheng 7y ago> SGX is disabled by default, it has to be enabled for this exploit to be relevant This is an attack on SGX. If you are not using it, it is irrelevant regardless of whether it is enabled. > POC requires privileged execution, at which point you can safely assume all is already lost For SGX, this is different. The threat model behind SGX is that anything outside SGX (including OS, BIOS, motherboard, etc.) is untrusted. The whole motivation behind SGX is to create a trusted environment in an untrusted host.
- throwawaymath 7y agoThose aren't caveats at all. First, this is explicitly a vulnerability compromising SGX itself, so saying SGX has to be enabled is tautological. It's not a vulnerability attacking Intel processors generally, and it's not being billed that way either. Second, securing memory against untrusted privileged execution is a defining characteristic of SGX, so it's likewise unsurprising that it would be required. That is quite literally the intended purpose of SGX. The design thesis of SGX is to prevent "all hope is lost" from being true in the context of privileged execution.
- ulrikrasmussen 7y agoAt this point, I really don't understand how people can still believe that SGX is ever going to work. The threat model is so incredibly hostile that it is basically impossible to create something that isn't vulnerable through some kind of side channel or physical manipulation such as this. When it is compromised at just one site, then the whole security model topples. In the end, you will only be able to "securely" deploy it in environments where you trust the parties to not tinker too much with it. But in that case, why not just go for something a lot simpler when you already rely on trust?
- panpanna 7y agoThe idea behind sgx is that you don't need to trust your cloud provider. There are already simpler solutions for local execution.
- tasty_freeze 7y agoI understanding how screwing with the voltage can cause execution errors. If a random flop somewhere in the design flips state (or fails to when it should) the resulting behavior could be anything, including hanging the chip. How does such a random event get turned into an exploit?
- panpanna 7y agoThere are a bunch of different methods but the old school method was mainly to make a control point to make an incorrect decision.
- segfaultbuserr 7y agoMost comments simply missed the point. Power analysis attack and power glitch attacks are well-known in cryptography and electronics. The classic technique is to monitor the Vcc voltage and current on an oscilloscope and try deducing the internal operation of the chip and extract the secret, or to inject a glitch by on the Vcc rail to induce a fault. A classic side-channel attack, but these attacks required complete physical control over the hardware, and you need to put a dozen of probes on the motherboard in a lab with an elaborate setup, so it was typically not a concern unless it's a crypto key or something (if so, it would be done on a separate security chip with physical defense internally). But this attack showed that, since every CPU and SoC now has builtin dynamic voltage scaling and power management, by using these features, you can use the CPU to launch a power analysis attack against itself, and you don't even need to touch even a single trace on the PCB, the attack can be launched remotely, and all you need is root access! This is frightening. Who knows what is going to be the next.