Slashdot Mirror

← Back to Stories (view on slashdot.org)

After Intel ME, Researchers Find Security Bug In AMD's SPS Secret Chip-on-Chip (bleepingcomputer.com)

Posted by EditorDavid on from the in-the-chips dept.

An anonymous reader writes: AMD has fixed, but not yet released BIOS/UEFI/firmware updates for the general public for a security flaw affecting the AMD Secure Processor. This component, formerly known as AMD PSP (Platform Security Processor), is a chip-on-chip security system, similar to Intel's much-hated Management Engine (ME). Just like Intel ME, the AMD Secure Processor is an integrated coprocessor that sits next to the real AMD64 x86 CPU cores and runs a separate operating system tasked with handling various security-related operations.

The security bug is a buffer overflow that allows code execution inside the AMD SPS TPM, the component that stores critical system data such as passwords, certificates, and encryption keys, in a secure environment and outside of the more easily accessible AMD cores. Intel fixed a similar flaw last year in the Intel ME.

13 of 76 comments (clear)

  1. Not the same? Not an actual backdoor? by Futurepower(R) · · Score: 5, Informative

    Quote from a complaining comment about the Bleeping Computer story: "Garbage FUD probably hired by Intel, and it wouldn't be surprising. In order to exploit AMD's TPM (which is an easy BIOS fix) the hacker needs physical access to the motherboard... at that point the hacker may as well have armed forces hijack the data center."

    1. Re:Not the same? Not an actual backdoor? by Anonymous Coward · · Score: 4, Informative

      This AMD PSP vuln requires prerequisite physical access.

    2. Re:Not the same? Not an actual backdoor? by guruevi · · Score: 2

      Both Intel ME and AMD's SPS require access to the system to enable in the first place, so yes, you need at the very least an account on the computer. It doesn't require physical access (as in, you don't need to attach wires to the bus or push buttons).

      Given that AMD's SPS flaw sits in a certificate validation routine, it may actually be possible to trick the computer into the exploit by using some DRM shenanigans (eg. an evil Netflix site) whereas from what I could compile from a cursory look on the Intel link, you actually already need to have the Intel ME enabled and have some privileges into Intel ME's in order to elevate your permissions.

      --
      Custom electronics and digital signage for your business: www.evcircuits.com
    3. Re:Not the same? Not an actual backdoor? by BlueCoder · · Score: 3, Interesting

      No it isn't the same. Until you show me that it can be used through a network attack. While it is a security bug it's relevant to a TPM boot chain.

      Who is using TPM? I've considered getting one at home just to play around with it.
      To me TPM has been in perpetual development because of bugs. And honestly until there are BIOS setting which enable ME to manage all of it's keys then I will never trust it.

    4. Re:Not the same? Not an actual backdoor? by serviscope_minor · · Score: 3, Insightful

      Because buffer overflows are only usable with physical access?

      doesn't that depend on what the buffer overflow exploit is in?

      I have not RTFA because this is slashdot, but buffer overflows are not de-facto remote exploits. If the buffer is accessible via the network, you're in the crap. If it's only available locally then it's only a local exploit.

      Of course local priviledge elevation is bad because that's only one remote unpriviliged exploitation away from being a remote root access. No idea what this one is.

      Either way though, that obnoxious bastard Stallman was fucking right again[*].

      Can't see the source, can't fix it, can't trust it.

      [*]Part of his obnoxiousness is consistently being right about paranoid, inconvenient things.

      --
      SJW n. One who posts facts.
  2. Re:Make up your damn mind. by Lunix+Nutcase · · Score: 2

    It’s both and neither depending on if the cat is dead in the box or not.

  3. Info: Intel CPU backdoors by Futurepower(R) · · Score: 2

    What we know about Intel CPU backdoors so far (June 2017)

  4. hmmm.... by Tsolias · · Score: 2, Interesting

    the real AMD64 x86 CPU cores"

    softpedia yesterday was telling us about AMD Radeon Processors
    now we get real AMD64 x86 CPU cores
    you know that intel doesn't have money to buy at least an educated shill, when they shop from junior CS classes... and I even doubt that, I believe that they just hire SJWs for everything nowadays.

    0.02 shekels have been deposited to your account

  5. Luckily it can be officially disabled... by HalAtWork · · Score: 4, Informative

    ...at least when mainboard makers support the option in UEFI.

    https://www.phoronix.com/scan....

    --
    Twinstiq, game news
    1. Re:Luckily it can be officially disabled... by UperPoti · · Score: 2

      AGESA is proprietary again since 2014. Even if AGESA was open source, or AMD released the BKDG and someone paid the $$$ for a coreboot port, the simple fact is the signed PSP is still needed for the platform to boot. Therefore, libreboot can never happen, and you don't really have full control over the machine. And that's assuming this isn't just an option to limit the UEFI firmware from talking to the PSP during boot. Best case is that the PSP still runs during boot but is somehow shut off after the BIOS loads. Worst case: AMD is simply making the BIOS not talk to the still active and still dangerous PSP. Even in the best case scenario, the PSP is still active and still has control of your machine for at least a limited time window as AGESA has to bootstrap the ARM TrustZone. If it's disabled, it hopefully simply isn't booted. Or, perhaps, the CPU would prevent PSP from accessing memory, effectively disabling it (and all of ring 0 code, in fact). But, there would be no way to know that it was truly deactivated short of AMD releasing the source code showing that it does in fact shut down. If it shuts down then theoretically there should be no AMD / third party IP required, so AMD should be able to release stripped-down source code and binaries sans the third party IP. If they aren't willing to do that, don't just blindly take a nebulous BIOS option as evidence of security. Disabling could be fully accomplished by preventing address translation, though the end user has no such capability. With Ryzen, PSP is likely a client of the IMC directly, attached via the infinity fabric. A single flag should be able to disable that link - or, more exactly, prevent it from being initialized. This would be the easiest way to disable the PSP, but isn't necessarily how this BIOS option works. Disabling the link is an option. However, only AMD can do that and AMD is on record as stating the PSP is mandatory and that they will not support it being disabled or allow anyone else to disable it. Given ASRock's description, this particular [BIOS] option appears to disable the driver as a debug option intended to fix / work around boot problems related to the UEFI firmware's PSP driver, and has no bearing on the PSP core operation.

  6. Re:iRONY by DontBeAMoran · · Score: 3, Interesting

    It seems that particular AMD bug can by disabled/bypassed by a BIOS/UEFI update, so the suggestion is still valid.

    --
    #DeleteFacebook
  7. we need to stop accepting these as accidents by Anonymous Coward · · Score: 2, Interesting

    the fact that over, and over, and over, systems prove to have obscure vulnerabilities that allow an attacker to spy on everything the user is doing.... seems like it might be deliberate. i.e. the government gave up on the clipper chip, and cracking down on encryption.... why?

    The era of "oh the government doesnt care" or "it would never spy" is gone. they do spy. they feel like its their job, their purpose in life, the necessity of a stable government, they believe they have a god given right to all of your information. Because 9/11. Because Hitler. Because China. Because because because.

    Look at these situations. These are the leading US tech companies, all of which have huge relationships with many secret govt agencies, all have revolving doors between themselves and the congress and the bureaucracy that regulates and profits from these tools... for example Cray wouldnt exist without NSA secretly bailing them out. You dont need to be a conspiracy theorist, just read a few history books about the actual NSA and CIA by people who worked there. They dont even apologize because they dont think they did anything wrong.

    Look at the Russian or Chinese or Turkish or UK or any other government and how they exploit Info tech to spy on people. Realize the US is not really that different. These are all deliberate backdoors built by governments to spy on their people. These are not security bugs. These are security features.

    Maybe.

  8. Need to connect wires to microscopic TPM traces by raymorris · · Score: 2

    > Is the TPM protected from writing? If not, I assume the certificate can be modified/replaced via software.

    No, you cannot write directly to TPM nvram from the OS. The spec says the endorsement key is supposed to be permanently burned in at the factory, but some manufacturers instead support CreateEndorsementKeyPair, which asks the TPM to create a key for itself, if it doesn't already have one. If it already has a key, as it should, CreateEndorsementKeyPair does nothing but return an error code.

    To put your own malicious endorsement key in the TPM, you'd need to directly access its NVRAM. The most direct way to do that would be to pull out your scanning electron microscope and connect to the nvram traces on the chip. If some *other* vulnerability allowed full write access to TPM NVRAM, that would be a game changer.