• hoyski@lemmy.world
    link
    fedilink
    English
    arrow-up
    7
    ·
    10 hours ago

    The researchers discovered that AMD had been using a publicly available example key from NIST documentation since Zen 1…

    The perils of cut/paste

  • TheGrandNagus@lemmy.world
    link
    fedilink
    English
    arrow-up
    140
    arrow-down
    3
    ·
    edit-2
    2 days ago

    This flaw allows attackers with local administrator privileges to bypass AMD’s cryptographic verification system and install custom microcode updates on affected CPUs.

    If you already have local administrator privileges, you have access to the system and its data anyway. Doesn’t seem that critical a flaw. It doesn’t even survive reboots.

    Regardless, AMD has already issued a fix.

    • Toes♀@ani.social
      link
      fedilink
      English
      arrow-up
      22
      arrow-down
      2
      ·
      edit-2
      2 days ago

      Edit: seems I may be mistaken.

      If I’m understanding this correctly this opens up the door to a serious type of rootkit.

      It’s not a matter of attackers having access to the data. It’s that they have replaced your hardware with malicious hardware.

      Additionally It can be trivial to gain administrative capacity on a personal computer. But in a regular case you can just reinstall the operating system. This would survive that.

      • Dark ArcA
        link
        fedilink
        English
        arrow-up
        24
        ·
        edit-2
        2 days ago

        On some level yes, but reading the article nothing persist between boots. This seems like a vulnerability that’s really only that serious A if you don’t apply AMDs patched micro code and B there’s another vulnerability on your system that lets this persist between operating system reinstall/in the BIOS.

        • pivot_root@lemmy.world
          link
          fedilink
          English
          arrow-up
          4
          ·
          edit-2
          2 days ago

          As far as them being applied, yes. The loaded microcode is volatile.

          They can kind of persist across cold reboots, but it relies on them being applied again at some point. The motherboard vendor can apply microcode updates during platform initialization before POSTing. Or they can be applied from EFI (modern equivalent of BIOS) before handing control to the kernel. Or they can be applied very early in the boot process by the kernel.

    • palordrolap@fedia.io
      link
      fedilink
      arrow-up
      5
      arrow-down
      1
      ·
      2 days ago

      local administrator privileges

      … are used by distro update mechanisms and very few people turn those off, even if they don’t use elevated privileges for anything else.

      Admittedly, it’s unlikely that a distro’s repository will end up with a compromised microcode package, but it’s not impossible (Remember the 7zip debacle?). And if it happens, you can be sure that whoever designs the payload will use the temporary access to install something ugly that has more permanent access.

      But as you say, AMD have issued a fix. And that’d be why.

  • pHr34kY@lemmy.world
    link
    fedilink
    English
    arrow-up
    8
    arrow-down
    1
    ·
    2 days ago

    If making the PRNG on your CPU predictable can compromise your whole system, then your kernel is not doing its job.

  • Limonene@lemmy.world
    link
    fedilink
    English
    arrow-up
    9
    arrow-down
    1
    ·
    2 days ago

    Could this be used to develop homebrew microcode? Could we finally disable the PSP with this?