[HN Gopher] Fault Injection Attacks Against AMD's Secure Encrypt...
___________________________________________________________________
Fault Injection Attacks Against AMD's Secure Encrypted
Virtualization
Author : sevest
Score : 151 points
Date : 2021-08-12 08:15 UTC (14 hours ago)
(HTM) web link (arxiv.org)
(TXT) w3m dump (arxiv.org)
| spdy wrote:
| With our findings, we prove that SEV cannot adequately protect
| confidential data in cloud environments from insider attackers,
| such as rouge administrators, on currently available CPUs.
|
| ---
|
| It is an interesting attack but is the above goal ever
| achievable? To protect against adversaries from the inside.
| JustFinishedBSG wrote:
| > rouge administrators
|
| It's not important but come on, if your field is cyber security
| at least make sure _rogue_ is spelled correctly.
| [deleted]
| [deleted]
| dgellow wrote:
| I would guess the GP is using French locales + autocompletion
| from a mobile device
| JustFinishedBSG wrote:
| I'm not talking about GP though, it's not important to make
| that mistake here. But the mistake is present in the
| _paper_.
| onlinejk wrote:
| Thanks, I was worried I had red that wrong
|
| _ducks_
| throwaway420y wrote:
| Are you sure they aren't talking about these admins ?
| https://en.wikipedia.org/wiki/Wikipedia:Rouge_admin
| swiley wrote:
| One day, when I'm retired or homeless, I'd love to pull
| apart and try to understand the weird cultures of
| wikipedians.
| doubled112 wrote:
| If you're retired AND homeless, will you do the same, or
| will you have bigger problems?
|
| Just trying to figure out where you've drawn the line.
| dnautics wrote:
| it's distinguish from bleu team administrators!
| wizzwizz4 wrote:
| A rogue admin is acting alone, but rouge admins are part of
| the shadowy cabal and thus have access to many times more
| resources.
| markenqualitaet wrote:
| They meet at the _Mole in Rouge_ , blowing off the tension
| of secrecy by mansplaining each other _Das Kapital_.
| dnautics wrote:
| does anyone actually use SEV in cloud environments? My
| impression was that its lineage (my understanding it's
| basically AMD's intel-SGX) is to enable DRM for stuff like
| netflix. I know for a time there was a lot of talk about using
| SGX in the cloud, but I was under the impression that the trust
| in SGX has been eroded over time to the point where no one
| thinks it's a good idea.
| benlivengood wrote:
| I've only spun up a SEV instance for the novelty but am
| considering using it for things like hashicorp vault where
| performance isn't critical but extra privacy assurance is
| nice.
|
| Fundamentally, though, system security hasn't caught up with
| the promise of SEV. It's far more likely that a VM will be
| compromised by 0-day attacks than insiders at the cloud
| companies. But if you really need to run a secure kernel on
| someone else's machine then SEV is the way of the future.
| This includes using SEV on-premises against hardware attacks.
| I've wanted hardware RAM encryption for a decade or two to
| avoid coldboot attacks and similar hardware vulnerabilities.
| theevilsharpie wrote:
| SEV is completely different from SGX, and doesn't (currently,
| to my knowledge) have an equivalent on Intel chips that are
| currently on the market. Google Cloud's confidential compute
| feature makes use of SEV under the covers.
| wmf wrote:
| Specifically, I think SEV is lacking attestation that would
| be needed for DRM.
| dnautics wrote:
| thanks for clearing that up!
| landr0id wrote:
| While its goals are a bit different from confidential
| computing, people saying "no" here have apparently never heard
| of the Xbox One. More generally, securing a device against its
| physical owner is notoriously difficult. Tony Chen gave a talk
| about how the Xbox One was secured against physical attack:
| https://www.youtube.com/watch?v=U7VwtOrwceo
| monocasa wrote:
| Chen makes it very clear that their threat model only
| includes attacks costing less than the attach rate of the
| system (about $600). He doesn't consider it an achievable
| goal in the general case.
| phire wrote:
| Well, that's the explicit goal of SEV.
|
| That the CPU should be able to cryptographically prove that a
| VM has been setup without any interference from an inside
| attacker who controls the hardware.
|
| At the very least, SEV massively raises the barrier to such
| attacks. It's now beyond the ability of a rogue administrator
| or technician, requiring complex custom motherboards. But a
| well-funded inside attacker can target something with high
| enough value.
| londons_explore wrote:
| > It's now beyond the ability of a rouge administrator or
| technician, requiring complex custom motherboards
|
| The end of the abstract explicitly refutes this. It is
| claiming that a software-only solution, using keys derived
| with this technique, can pretend to be a suitable target to
| migrate a secure VM to, which then allows the rogue admin to
| inspect or modify anything in the VM.
| floatboth wrote:
| A bit unclear from the abstract whether the keys they
| learned how to derive (and the secret material they're
| derived from) are per individual chip or for all chips ever
| produced. If it's the former, that means the rogue admin
| still needs to electrically mess with the hardware once.
| phire wrote:
| Though, that means you just need one modified
| motherboard.
|
| Put each CPU in, extract the keys, deploy in a regular
| motherboard.
| nine_k wrote:
| This still excludes wide ranges of possible rogue admin
| attacks.
|
| As a minimum, it takes shutting down and powering down
| the physical machine, then starting it up, which would
| not go unnoticed in highly controlled environment where
| SEV makes most sense.
| simcop2387 wrote:
| it does mean though that a system integrator could
| extract the keys ahead of time, likely without any way to
| know this has happened. adding a way to generate a new
| key or otherwise rotate the key material should fix that
| issue though.
| toast0 wrote:
| One potential use of SEV is to provide a secure
| environment to run a VM at an untrusted provider. That
| provider could do lots of things with funky motherboards
| and forced migrations without notice by their clients.
|
| If it's an insider attack on company owner and operated
| hardware, there's always some reason to have a long
| downtime, and you can piggyback on that to attack the
| CPUs... Or just put it in a new system and use the
| migration setup.
|
| Suggested downtimes, organic or sabotage up to attacker's
| timeline:
|
| HVAC failure: have to shut down many/most/all servers to
| manage temperatures until HVAC techs can fix.
|
| Automatic transfer switch failure: these things love to
| fail at the same time as a utility failure, and aren't
| always easy to bypass.
| nieve wrote:
| The part about "without requiring physical access to the
| target host" would seem to imply that they only need
| access to a machine on their end for some attacks.
| BeefWellington wrote:
| > It is an interesting attack but is the above goal ever
| achievable? To protect against adversaries from the inside.
|
| Yes. To expand: to a function on the CPU an administrator is
| just another user. The Operating System is responsible for
| managing those designations.
|
| These trusted computing pieces across all kinds of CPUs are
| _specifically aimed at protecting against people with host-
| root_ , so it would seem like it's a goal they've set for
| themselves and should be reasonably achievable.
| michaelt wrote:
| _> It is an interesting attack but is the above goal ever
| achievable? To protect against adversaries from the inside._
|
| People have gotten very close to achieving _similar_ goals.
|
| For example, modern games consoles' anti-piracy measures guard
| against the device owner who has physical control and unlimited
| time. [1]
|
| iPhone activation locks likewise prevent stolen phones from
| being used, even by thieves with physical control and unlimited
| time.
|
| And neither of the systems rely on the clunky 'brick the device
| if the case is opened' methods of yesteryear.
|
| (Of course there have also been a great many failed attempts -
| almost every console since the dawn of time has eventually been
| hacked, as have things like TPMs and TrustZone, many versions
| of the iPhone were rooted, etc etc)
|
| [1] https://www.youtube.com/watch?v=quLa6kzzra0
| steelframe wrote:
| There's a significant asymmetry in motivation and resources
| available to compromise hardware between Jimmy and his Xbox
| vs. Google and their cloud infrastructure.
| michaelt wrote:
| Yes, someone with an xbox hack has tens of millions of
| potential customers who can save $60 a game, with complete
| physical access to the hardware and no chance of getting
| fired or arrested.
|
| Whereas someone with a Google cloud infrastructure hardware
| fault injection attack has only a tiny number of spy
| agencies or rogue admins as potential customers, the
| servers are all locked up in data centres, and anyone who
| got caught making an attack would get fired and/or
| arrested.
| monocasa wrote:
| Jimmy is only willing to spend less than he'd spend in
| the cost of games. Even with a large amount of Jimmys
| there might not be market without getting the cost of an
| individual attack low enough.
|
| On the other hand, there for sure is a market for cloud
| based attacks, and nation states that can apply a stick
| to go along with the carrot of millions of dollars in
| "consulting fees".
| Taek wrote:
| Especially as we move more key infrastructure into the
| cloud. If people start trusting these sorts of remote
| systems with things like financial data, the payoff of a
| clandestine compromise could be hundreds of billions of
| dollars.
|
| Doubly true when you consider the history of Google
| working with the USG.
| Cyph0n wrote:
| My understanding is that this is part of the threat model of
| TEEs (Trusted Execution Environment). Whether or not this will
| ever be achievable is a different story.
| baybal2 wrote:
| > It is an interesting attack but is the above goal ever
| achievable? To protect against adversaries from the inside.
|
| No, safe execution of untrusted code is impossible by the very
| definition, not without undoing 40 years of IC design
| practices.
|
| It's an almost physical limitation which makes it very hard to
| compute something without some electromagnetic leakage from/to
| the die.
|
| Take a look on secure CPUs for credit cards. They have layer,
| upon layers of anti-tampering, anti-extraction measures, and
| yet TEM shops in China do firmware/secret extraction from them
| for $10k-$20k
| MayeulC wrote:
| >> It is an interesting attack but is the above goal ever
| achievable? To protect against adversaries from the inside.
|
| > No, safe execution of untrusted code is impossible by the
| very definition
|
| I think this is more about data processing while hiding the
| data from whoever operates the hardware. Homomorphic
| encryption could be a partial answer to that.
| baybal2 wrote:
| > Homomorphic encryption
|
| Explain please to me how homomorphic encryption will
| protect someone from basic laws of physics.
| evancox100 wrote:
| What is a TEM shop? Curious about this topic, the threat
| model for some chips in the secure payments space assumes a
| secret value much higher than $10k for something like a root
| encryption key that blows open the payment processing
| security of multiple cards.
|
| Also, just because something is physically possible, doesn't
| mean that the barriers to doing so are irrelevant. If it
| costs you $10k to unbrick a locked & stolen iPhone, then
| those countermeasures have likely succeeded at their intended
| purpose. This is why threat models try to quantify the time
| and/or monetary value of what they're protecting.
| baybal2 wrote:
| Tunneling electron microscope
|
| A single facility for TEM comes with $10,00,000+ pricetag,
| and usually they amount to few dozens per a developed
| country, in use in places like universities, and research
| institutes.
|
| China has probably more of them than the rest of the world
| combined.
| formerly_proven wrote:
| It is very hard to perform a physical process while making it
| impossible to observe it. Similarly it is very difficult to
| have some object with permanent physical properties that you
| (the chip) can measure yourself, but no one else can, like a
| cloud of electrons trapped on an island, or a metal
| connection between two places.
| lima wrote:
| > _It is an interesting attack but is the above goal ever
| achievable? To protect against adversaries from the inside._
|
| Achievable in any circumstances? No. Within a well-defined
| threat model, definitely.
| swiley wrote:
| Except that the threat model the crippled SEV defends against
| is the same one the SU command does, making it irrelevant.
| DSingularity wrote:
| Do you mean "adversaries from the inside" could be more
| detailed to create reasonable limitations on access and
| resources as imposed by external systems (eg cameras, guards,
| searches) securing the machines?
| jlourenco27 wrote:
| It's not plug-and-play. It still needs a custom firmware:
| "(...)The presented methods allow us to deploy a custom SEV
| firmware on the AMD-SP, which enables an adversary to decrypt a
| VM's memory.(..)"
| londons_explore wrote:
| InstallRogueFirmware.exe. _double-click_.
|
| This is about protecting a VM from people who have admin
| rights and hardware access outside the VM.
| floatboth wrote:
| Voltage glitching is no double-click. It would be a huge
| embarrassment to AMD if just double-click defeated the
| secure processor's firmware authentication. This requires
| electrically messing with the power supply of the
| processor.
| api wrote:
| So this means the secure VM feature is secure up to the
| threat model of someone able to crack open the hardware.
|
| Honestly that's kind of what I would have expected. Just
| making it almost impossible to get VM memory _remotely_
| by owning the hypervisor is pretty good and reduces your
| attack surface to people who can get into the data center
| and have electronics expertise.
| creamytaco wrote:
| "rouge administrators" ?
| xarope wrote:
| I guess that physically proves they are on the red team? /j
| bashwizard wrote:
| HEHEHEHEHE!!!11!11!one
| smcl wrote:
| One of the more commonly misspelled words. In this case it's
| just a little easily fixable typo in an article online, but
| I've seen a few _businesses_ where people wanted "rogue" and
| had "rouge" instead which is kinda mindblowing. When you've
| registered a business, setup branding and signage etc all the
| while repeatedly messing up the same word each step of the way.
| Boy, that's embarrassing.
| evancox100 wrote:
| Wow, this is just really basic stuff in the secure IC world that
| you need to monitor the supply voltage for glitch attacks [0].
| The glitch they are injecting is in the 20 us range which isn't
| even that fast. Whatever part of the chip you want to keep secure
| (the SP in this case I guess) probably needs a dedicated voltage
| regulator, preferably an on-chip LDO w/ a droop monitor on the
| output. I only skimmed the paper, but it seems like there is no
| supply monitoring being done that would cause the SP to bail out
| of its hash checking.
|
| [0] https://ieeexplore.ieee.org/document/4595799
| mindslight wrote:
| I'd like to imagine that the engineers tasked with developing
| these systems are aware of management's evil endgame, and leave
| in whatever obvious bugs they can to slow down the loss of
| computational freedom. The spec for the next version will
| include an on chip regulator, and they'll have to sabotage it a
| different way.
| titzer wrote:
| Uh, this is completely unethical behavior from an engineer.
| In no way, shape, or form is the insertion of a deliberate,
| hidden flaw that breaks the intended security properties of a
| system an acceptable form of protest.
| mindslight wrote:
| It wouldn't be a "protest". Rather, it would be directly
| preserving individual human autonomy against emergent
| entities. Would you also consider it "unethical" for a farm
| animal to break out of its pen?
|
| The true ethics violation here is creating devices to be
| "sold" while retaining control over their new supposed
| owner. Unfortunately, the digital/software engineer's main
| recourse to ethical violations is to quit, and someone else
| will just take their place. As the digital honeymoon wears
| off and we become keenly aware of communications
| technology's authoritarian potential, I hope there is a
| different type of resistance forming within all of these
| systems of control.
| jlawer wrote:
| From a skim through the article, it seems to require soldering
| onto the power line between the voltage regulator and the
| processor to trigger the voltage drop. I don't believe the VR
| circuitry could be caused to glitch in the desired way by
| software / easily accessible physical components (i.e. plugging
| into USB).
|
| Someone might be able to develop a method of causing this to
| occur by targeting a draw elsewhere, but this will likely by
| motherboard specific (or even entire platform specific).
|
| It definitely means that SEV isn't going to save you if your
| vendors conspire against you, but unless your dealing with a
| determined state level actor, I doubt there is much risk to most
| of us. Internal actors (rogue staff) are likely to compromise in
| a simpler way.
|
| However this is great research, I imagine in CPU designs that are
| being planned now, there will be some work to ensure the Secure
| processor is protected, likely by making the processor fault when
| SP input voltage drops. Alternatively they might be able to move
| some power regulation onto the processor package providing
| buffering against voltage manipulation.
| anonymousDan wrote:
| Similar attacks have already been demonstrated for other TEEs so
| nothing majorly new here (although the details are obviously
| different). The first work I'm aware of is an attack paper called
| CLKSCREW on ARM Trustzone. There were also some similar attacks
| published subsequently on SGX (Plundervolt). It's a hard problem
| to solve I think. One of the major dividing lines is whether the
| attack can be performed remotely (i.e. software only using OS
| power management APIs), or whether it requires physical access.
| The former obviously has more impact but most likely is much
| easier to mitigate than physical attacks.
| no_time wrote:
| Good. I hope this allows me to extract the fTPM keys from the
| hardware I own.
| tzs wrote:
| What benefit would you get from having the fTPM keys? I don't
| own any PCs with TPM or fTPM as far as I know, so am not very
| familiar with what having it does as far as user experience is
| concerned and what having the keys would do to improve that.
| no_time wrote:
| It would allow me to fake any measured boot attestation.
| Right now this infrastructure is only provided to companies
| looking to secure their network[0] but if you look at
| Android's SafetyNet and the trends in IT, companies may force
| you to only use software they approve of to use their
| services.
|
| On android it's already a choice between banking apps or a
| device you fully control. I fear that this will include all
| internet connected devices in the future.
|
| [0] https://docs.microsoft.com/en-us/windows-
| server/security/dev...
| mmastrac wrote:
| Oh god yes. I don't want a device where I have to choose
| between full services and full control (for myself). The
| introduction of SafetyNet really annoyed me for those
| reasons.
| [deleted]
___________________________________________________________________
(page generated 2021-08-12 23:01 UTC)