• Spedwell@lemmy.world
    link
    fedilink
    English
    arrow-up
    2
    ·
    edit-2
    8 months ago

    Wow, what a dishearteningly predictable attack.

    I have studied computer architecture and hardware security at the graduate level—though I am far from an expert. That said, any student in the classroom could have laid out the theoretical weaknesses in a “data memory-dependent prefetcher”.

    My gut says (based on my own experience having a conversation like this) the engineers knew there was a “information leak” but management did not take it seriously. It’s hard to convince someone without a cryptographic background why you need to {redesign/add a workaround/use a lower performance design} because of “leaks”. If you can’t demonstrate an attack they will assume the issue isn’t exploitable.

    • Killing_Spark@feddit.de
      link
      fedilink
      English
      arrow-up
      1
      ·
      edit-2
      8 months ago

      So the attack is (very basically, if I understand correctly)

      Setup:

      • I control at least one process on the machine I am targeting another process on
      • I can send data to the target process and the process will decrypt that

      Attack:

      • I send data that in some intermediate state of decryption will look like a pointer
      • This “pointer” contains some information about the secret key I am trying to steal
      • The prefetcher does it’s thing loading the data “pointed to” in the cache
      • I can observe via a cache side channel what the prefetcher did, giving me this “pointer” containing information about the secret key
      • Repeat until I have gathered enough information about the secret key

      Is this somewhat correct? Those speculative execution vulnerabilities always make my brain hurt a little