Announcement

Collapse
No announcement yet.

Hertzbleed Disclosed As New Family Of Side-Channel Attacks Affecting Intel + AMD

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • jeisom
    replied
    My understanding is openssl and libressl use methods to prevent these kind of attacks. Are these findings finding that they need rethought, hardened further or is do other implementations need hardened?

    Leave a comment:


  • Developer12
    replied
    Originally posted by mlau View Post
    I read a bit of the PoC code:
    - it works apparently best when the crypto stuff to be sniffed is the only running task. Windows users should be immune by virtue of the OS being a resource hog
    - It needs root otherwise it can't read the RAPL (energy monitor) registers.
    - It's not fast.

    I can certainly see a patient attacker using this to exfiltrate seldom-changed keys.
    you don't need root in the real exploit as you can measure timing discrepancies and thus infer power consumption and crypto key contents.

    you can measure the timing differences during several rounds between client and server. crypto is slow so a 5% difference can be noticeable.

    writing crypto code to always take the same amount of time is a big deal and this attack cracks that apart.

    Leave a comment:


  • MauganRa
    replied
    This attack is very likely running repeated measurements and building statistical models from that. Or just unleashing machine learning on the data. Of course, the wall-clock time is absolutely meaningless with just one measurement. However, this attack relies on something more subtle: on *differences* between wall-clock times. Sounds even more noisy, but with enough measurements all the noise either coalesces into biases or averages itself out. Modern processors are insanely fast and few users monitor their systems closely enough to notice a malicious attacker doing measurements. And this attack should actually work better if the attacker does *not* cause CPU utilization to peak at 100% for extended periods.

    Leave a comment:


  • erniv2
    replied
    WOOT even if you dont use turbos, you would have to deactivate every kind of power managment, and even then systems run on spread spectrum to be EMI certified.

    So there is allways min. 1 mHz change, i doubt there is realy a way to exploit that thing, this is so highly unlikely, it´s like lightning strike, well some ppl get struck 7 times in the life tho, btw. how high is the chance that earth is hit by a meteor? 100% it happens all the time .
    Last edited by erniv2; 14 June 2022, 03:54 PM.

    Leave a comment:


  • Slartifartblast
    replied
    Hertzbleed ?

    Sounds like a wounded rental car.

    Leave a comment:


  • mlau
    replied
    I read a bit of the PoC code:
    - it works apparently best when the crypto stuff to be sniffed is the only running task. Windows users should be immune by virtue of the OS being a resource hog
    - It needs root otherwise it can't read the RAPL (energy monitor) registers.
    - It's not fast.

    I can certainly see a patient attacker using this to exfiltrate seldom-changed keys.

    Leave a comment:


  • carewolf
    replied
    I guess that only affect laptops? My desktop has enough cooling to run boosted all the time on all cores

    Leave a comment:


  • Guest
    Guest replied
    The one time where tweaking my system for gaming actually improves security I usually disable any kind of frequency scaling and lock it to a multiplier, along with using performance governors/Ultimate Power Plan.

    The problem seems to be with the CPU changing it's frequency with certain conditions, but it would sound like disabling scaling altogether would prevent that?

    Leave a comment:


  • ddriver
    replied
    If they are throwing that wall time issue in the summary, it should come with some context. What relies on that value being consistent? How is it even remotely possible for it to be consistent?

    And if we narrow the scope to some scenario where you are only issuing single clock instructions on register operands - everything is there and is guaranteed to execute in a single clock, and you are guaranteed no cache misses, and you are guaranteed to not have the thread execution suspended by the os or by a hardware interrupt. Oh and ignore scheduling and out of order execution altogether...

    Even in that super niche scenario, you could still count persistently via the actual clock cycles counter if you care about consistency that much. Then your count will be independent from the actual running clock speed.

    Maybe someone can elaborate the actual reasons?

    Leave a comment:


  • birdie
    replied
    Originally posted by gururise View Post
    Damn, so encrypted communications and transactions are potentially compromised unless one disables turbo-boost?
    Not just turbo boost, dynamic CPU frequency scaling from what I've understood. This one is so extremely difficult to exploit, it's just worth forgetting altogether. It also requires a system where only a crypto algo is running which is a rarity nowadays. I might be totally wrong - hopefully someone with more knowledge will chime in.

    Leave a comment:

Working...
X