Stories
Slash Boxes
Comments

SoylentNews is people

posted by takyon on Sunday January 07 2018, @06:36PM   Printer-friendly
from the end-of-trusted-computing dept.

Submitted via IRC for TheMightyBuzzard

AMD has fixed, but not yet released BIOS/UEFI/firmware updates for the general public for a security flaw affecting the AMD Secure Processor.

[...] Cfir Cohen, a security researcher with the Google Cloud Security Team, says he discovered a vulnerability in the Trusted Platform Module (TPM) of the AMD Secure Processor. The TPM is a component to store critical system data such as passwords, certificates, and encryption keys, in a secure environment and outside of the more easily accessible AMD cores.

"Through manual static analysis, we've found a stack-based overflow in the function EkCheckCurrentCert," Cohen says. The researcher claims that an attacker could use specially-crafted EK certificates to get remote code execution rights on the AMD Secure Processor, allowing him to compromise its security.

Cohen said that some basic mitigation techniques such as "stack cookies, NX stack, ASLR" were not implemented in AMD's Secure Processor, making exploitation trivial.

takyon: This bug is unrelated to Meltdown and Spectre. And you might be interested in this:

Coincidentally, on Reddit [1, 2], some users reported seeing a new option to disable AMD PSP support, but it's unclear if this new option is related to the patches AMD was preparing to roll out for Cohen's findings.

Source: Security Flaw in AMD's Secure Chip-On-Chip Processor Disclosed Online


Original Submission

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 0) by Anonymous Coward on Sunday January 07 2018, @07:42PM (5 children)

    by Anonymous Coward on Sunday January 07 2018, @07:42PM (#619258)

    But go read up on who is running the Intel ME project now, and who lead designers were on the speculative execution for the PPro, and while unlikely, may the same holds true with AMD's implementation.

    Personally, judging by the requirements to trigger AMD's exploit it sounds like a perfect security flaw for end users and maybe the NSA/FBI, while not being a great flaw for remote hackers.

    Assuming you have write protection on the bios, it is impossible to exploit without rebooting the system, disabling write protection, installing the rogue certificate, rebooting the system again, booting into the OS and generating a new key utilizing the stack smashing certificate already installed to nvram (read: flash, not rtc nvram) in order to inject arbitrary code. And you still need to know enough about the internals of the fTPM and TrustZone OS/Kernel to be able to take this exploit and turn it into shell access, or personal code running inside the Secure Processor.

    Once you HAVE however, it sounds like it could be pretty dope for all kinds of things, including pulling out authentication keys for specific applications tied to the tpm/hardware, whether for backup or piracy purposes.

  • (Score: 3, Interesting) by frojack on Sunday January 07 2018, @08:33PM (3 children)

    by frojack (1554) on Sunday January 07 2018, @08:33PM (#619267) Journal

    Personally, judging by the requirements to trigger AMD's exploit it sounds like a perfect security flaw for end users and maybe the NSA/FBI, while not being a great flaw for remote hackers.

    The fact that Google researchers are heavily involved in finding (and releasing) these exploits suggests they see this as a serious exploit, and have probably seen unexplained penetration on some of their cloud servers.

    Or did they...?

    They found this bug through manual static analysis. What the hell is that? pouring over core dumps trying to figure why the machine crashed? Detailed execution tracing of a known exploited machine to find out what was running?

    NO, nothing of that level of sophistication.

    Manual Static Analysis turns out to be mostly painstaking source code reviews. I guess when you are Google you can get access to AMD's source code. As could just about any other state level actor.

    --
    No, you are mistaken. I've always had this sig.
    • (Score: 2) by frojack on Sunday January 07 2018, @08:35PM (1 child)

      by frojack (1554) on Sunday January 07 2018, @08:35PM (#619268) Journal

      Note horrible quoting mess in above post provided free of charge, and unhindered by the thought process. Keep the change you filthy animals.

      --
      No, you are mistaken. I've always had this sig.
    • (Score: 0) by Anonymous Coward on Monday January 08 2018, @04:04AM

      by Anonymous Coward on Monday January 08 2018, @04:04AM (#619398)

      Manual static analysis includes ASM, reversed and decompiled code, FYI.

  • (Score: 2) by Runaway1956 on Sunday January 07 2018, @09:57PM

    by Runaway1956 (2926) Subscriber Badge on Sunday January 07 2018, @09:57PM (#619298) Journal

    And you still need to know enough about the internals

    Are you sure about that? When I first discovered the script kiddies, I was contemptuous of them, like almost everyone else. But, SOMEONE developed the exploits that the script kiddies used. In this case, it will take a pretty smart individual to set the script up, but once the script is built, the script kiddy needs understand diddly. He gains access to a machine, boots, flashes, reboots, and watches shit happen automagically. The brighter kiddies may customize the script, to some extent.