back to article Asus lets processor security fix slip out early, AMD confirms patch in progress

AMD has confirmed at least some of its microprocessors suffer a microcode-related security vulnerability, the existence of which accidentally emerged this month after a fix for the flaw appeared in a beta BIOS update from PC maker Asus. All we know for now is that the security issue is a "microcode signature verification …

  1. GNU Enjoyer
    Angel

    Doesn't look like a vulnerability

    Considering that the user having the possibility of the slightest bit of control over what should be their computer isn't a vulnerability.

    When it comes to signing schemes, any such scheme where it is not possible for the user to remove the default key(s) and put their own one in simply takes the users freedom without any security benefit.

    But clearly AMD now considers that its customers don't own what should be their computers and that AMD owns them and they should serve AMDs interests first.

    Previously it seems that AMD didn't handcuff their microcode update method - too bad there was no documentation nor free software microcode updates, which would be the decent thing to do and also allow for real security.

    1. Blazde Silver badge

      Re: Doesn't look like a vulnerability

      It think we have to assume microcode updates are now a lot more powerful & interesting than in the unencrypted Athlon 64 days, so this is potentially very interesting.

      Whether it's a vulnerability or not depends purely on your threat model..

      1. Claptrap314 Silver badge
        Facepalm

        Re: Doesn't look like a vulnerability

        AMD 64 had unencrypted microcode updates? Uggh. That was my time, but I didn't know about that. What a mess.

        While I can than fully appreciate the desire of hackers to role back the hood and tinker (I actually brought up the idea of exposing the microcode on the K5 to designers), supporting such a feature would just be too expensive.

        But what you really, really don't want is an attacker gaining access at that level. Really, really, really.

        1. GNU Enjoyer
          Angel

          Re: Doesn't look like a vulnerability

          >AMD 64 had unencrypted microcode updates? >What a mess.

          - No mess has ever resulted from such unencrypted updates.

          - "Security" through obscurity has never worked and will never work.

          - Stopping the good guys from finding vulnerabilities in things (who usually give up when faced with encryption where they cannot acquire the key of), prevents the good guys from finding vulnerabilities and telling you.

          - The bad guys have far more funds and motivation to do malicious things and therefore won't hesitate to decap chips to extract encryption keys and reverse engineer to find vulnerabilities and then use them without telling you.

          >supporting such a feature would just be too expensive.

          Is documenting the update function and instruction set really that expensive?

          You'll probably save a bit of money, as you wouldn't even need to fix many design mistakes as someone would fix it for you (despite the massively increased difficulty of not having the hardware design to reference).

          The handcuffs can even be implemented as usual and a header or trace or pins on the chipset that disables the signature check (pull the header, cut the trace, or bridge these pins to disable the signature check).

          It appears the real reason is how AMD doesn't want people to fix bugs and continue to use such perfectly fine CPUs - AMD wants them to throw them out and buy a new one to get the new "security fixes" - preferably every year, or at least every few years once microcode updates are no longer provided.

          Why doesn't AMD do an experiment on some old, "long obsolete" CPU by documenting the microcode update feature and instruction set and publish the source code of one update under a free software license (remove the part that adds a backdoor of course) and see if a massive cracking spree happens?

          >what you really, really don't want is an attacker gaining access at that level. Really, really, really.

          If an attacker has ring 0 access and can update microcode, you were long gone.

          Microcode updates are actually one of the least risky things as they don't have any kind of power-off persistence - as long as you're sure the SPI chip is free of proprietary malware and other hardware doesn't have the ability to update the microcode, you're looking pretty good.

          1. Anonymous Coward
            Anonymous Coward

            Re: AMD wants them to throw them out

            Ongoing support for the AM4 socket and the projected lifetime for the AM5 socket say otherwise.

            1. Blazde Silver badge

              Re: AMD wants them to throw them out

              Ongoing support

              Price differentiation. There was no technological reason for burning through an entire socket spec so quickly. Don't get me wrong, I'm glad they're taking it to Intel, but sadly they don't do that by being kind to consumers.

    2. IGotOut Silver badge
      WTF?

      Re: Doesn't look like a vulnerability

      @gnu

      So given the fact you didn't know they used signed keys (which has been a thing for a very long time), just shows your are talking utter bollocks about "freedom".

      Clearly, it's something you had no clue about before, so you are bringing it up because....nope no idea

      1. GNU Enjoyer
        Facepalm

        Re: Doesn't look like a vulnerability

        It's amazing how much freedom haters love to comment on things they've failed to do basic research about.

        AMD microcode updates originally just used a header and a checksum and no signature; https://www.usenix.org/system/files/conference/usenixsecurity17/sec17-koppe.pdf

        It appears Intel started handcuffing their CPUs in 1995, while AMD took till 2011 to do so.

        1. Blazde Silver badge

          Re: Doesn't look like a vulnerability

          To be fair Intel changed their microcode format for Core 2 (? ~2006) and only then did it appear to use a strong public-key crypto scheme.

          I'm not aware anyone ever fully cracked the old format but it just had some kind of 16 byte hash/checksum at the end that executed far too quickly to be anything more complicated than maybe MD5, if that. Looks like AMD's was a 4 byte checksum, so considerably weaker to brute force but probably not that much different once you probe inside and understand what the processor expects.

          AMD of course had a lot less money to throw around during 2006 to 2011 so no surprise they were a bit behind shoring up the microcode.

  2. John Robson Silver badge
    Devil

    It might mean "we meant to give the NSA a key, but forgot to put in the code, so their key doesn't work"

  3. Anonymous Coward
    Anonymous Coward

    What it means...

    AMD right now: "ah nuts, someone cracked our microcode's ROT13 encryption, we'll have to move to ROT26."

    Intel right now: standing on street corner holding a hand-written sign, "Spare some change please! wife, kids, fab plants and diminishing number of employees to support"

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Other stories you might like