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

  • #11
    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.

    Comment


    • #12
      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.

      Comment


      • #13
        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.

        Comment


        • #14
          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?

          Comment


          • #15
            "in order to mitigate the Hertzbleed vulnerability, we're disabling cpufreq by default"

            Comment


            • #16
              Originally posted by jeisom View Post
              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?
              https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/technical-documentation/frequency-throttling-side-channel-guidance.html

              Inte
              l's guidance states that mitigating the underlying power side-channel is sufficient to prevent the Hertzbleed attack. According to the openssl security policy:
              Certain threats are currently considered outside of the scope of the OpenSSL threat model. Accordingly, we do not consider OpenSSL secure against the following classes of attacks:
              [...]
              • physical observation side channels (e.g. power consumption, EM emissions, etc)
              I didn't see any mention of power side-channel resistance in a cursory glance at the OpenSSL code, so it might be vulnerable.

              Comment


              • #17
                AMD's security advisory isn't yet public but it's known at least Zen 2 and Zen 3 are affected.
                AMD's security advisory is public:
                https://www.amd.com/en/corporate/pro...in/amd-sb-1038

                Comment


                • #18
                  This should mainly affect servers with VMs again, right?

                  Comment


                  • #19
                    Originally posted by Slartifartblast View Post
                    Hertzbleed ?

                    Sounds like a wounded rental car.
                    So check your mirrors for side channel attacks, dude !

                    Comment


                    • #20
                      Originally posted by carewolf View Post
                      I guess that only affect laptops? My desktop has enough cooling to run boosted all the time on all cores
                      If your CPU is actually locked to full boost frequency then you aren't affected if I understand right. If it scales up dynamically dependent on load (even if it can boost forever), then you're affected. But this seems even more far fetched than all the the previous vulns so I'd expect impact to be limited. So much so that Intel won't even release a "fix".

                      Comment

                      Working...
                      X