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

  • arQon
    replied
    Originally posted by mlau View Post
    I can certainly see a patient attacker using this to exfiltrate seldom-changed keys.
    The thing is, there are a LOT of "seldom-changed keys" out there. The monthly/etc password changes that clueless IT depts insist on are actually security theater that does more harm than good, and NIST has advocated against them strongly for a very long time now.

    Similarly, while most encryption methods will let you rewrap a key with a new passphrase, the key itself remains constant, for obvious reasons.

    Luckily, this does seem very much like a purely-academic "threat" right now, and unlikely to be advanceable into something practical, but we'll have to see how things go.

    Leave a comment:


  • justinkb
    replied
    I have serious doubts as to the actual practical exploitability of this. Also, on VMs this should be less of an issue, not more, as is being suggested above me? On VMs there is less correlation between power usages and the happenings inside the specific VM, since whatever is hosting the VM is presumably doing lots of other things too.

    Leave a comment:


  • F.Ultra
    replied
    Originally posted by Termy View Post
    This should mainly affect servers with VMs again, right?
    any other software/user on your system can utilize exploits like this, a full VM is not required but of course they will be far more susceptible to this since they be default are other users running software on your system.

    Leave a comment:


  • carewolf
    replied
    Originally posted by binarybanana View Post

    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".
    I don't think it will be affected by boost either unless constrained by a power limit or thermal envelope. Boosting based on just running CPU bound code for full timeslots. It isn't effected by what instructions are used. To be able to measure the minute differences in power consumption based on variables, you need to be scaling based on power consumption.

    Leave a comment:


  • binarybanana
    replied
    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".

    Leave a comment:


  • bob l'eponge
    replied
    Originally posted by Slartifartblast View Post
    Hertzbleed ?

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

    Leave a comment:


  • Termy
    replied
    This should mainly affect servers with VMs again, right?

    Leave a comment:


  • danielp
    replied
    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

    Leave a comment:


  • danielp
    replied
    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.

    Leave a comment:


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

    Leave a comment:

Working...
X