- Joined
- May 14, 2004
- Messages
- 27,037 (3.71/day)
| Processor | Ryzen 7 5700X |
|---|---|
| Memory | 48 GB |
| Video Card(s) | RTX 4080 |
| Storage | 2x HDD RAID 1, 3x M.2 NVMe |
| Display(s) | 30" 2560x1600 + 19" 1280x1024 |
| Software | Windows 10 64-bit |
Yesterday, we had a very productive phone call with CTS-Labs, the firm behind the "AMD Flaws" critical security vulnerabilities exposé of the "Zen" microarchitecture. Our questions focus on the practicality of exploiting these vulnerabilities, and should provide more insight to the skepticism centered on needing admin privileges, flashing BIOS ROMs, and other localized hacks that would render any machine, not just "Zen" powered, vulnerable. Feel free to follow up with questions in the comments section, if we can help explain something.
TechPowerUp (TPU): Regarding Masterkey. Could you elaborate on the attack vector for this? AMD makes the claim that the on-chip ROM in Secure Processor fully validates the firmware read from NAND. You mention metadata parsing, which I assume is stored in the NAND, so when this is modified in a certain way the hash check gets bypassed? With Secure Processor validation broken, the UEFI signature checks for the main BIOS can be bypassed, too? Or is it additionally required to modify the main BIOS, too, for that to work?
CTS-Labs (CTS): First a small clarification: the BIOS and PSP firmwares, as well as certain non-volatile storage data are typically stored on a single SPI flash chip on the motherboard. When you install a BIOS update, both UEFI and PSP firmwares get replaced. MASTERKEY-1 through MASTERKEY-3 allow three distinct ways of installing malware on the PSP in spite of digital signature verification. The way this process works is: The PSP immutable ROM runs first, and then validates the beginning of the mutable PSP firmware inside the SPI flash. The PSP firmware then loads its other built-in modules, such as fTPM or SEV. This is when MASTERKEY kicks in to allow execution of unsigned code on the PSP's ARM processor. This can happen even before the PSP releases the main CPU from its initial halted state. Secure Boot is defeated from that point on (both UEFI Secure Boot and PSP Secure Boot).
Re-flashing the BIOS, a prerequisite for MASTERKEY, often does not require physical access to the device. We've tested this on motherboards by Tyan, ASUS, MSI, Gigabyte, Biostar, and others. It works by running an EXE.
TPU: Did you use an official flashing software, or create your own method that replicates the commands used by this software?
CTS: We used a modified version of the original BIOS update software. That allowed us to bypass some protections that exist in the original version.
TPU: You mention a few motherboard companies above, do you feel this means that all motherboards are affected, or are some more secure than others?
CTS: On motherboards where flashing is not possible because the BIOS image is encapsulated and signed by an additional layer of OEM-specific digital signature, we think it may still be possible to install a malicious BIOS that exploits MASTERKEY by either: (a) Using RYZENFALL or FALLOUT to achieve code execution on SMM, and disable signature verification that is implemented in SMM, or (b) Use RYZENFALL-4 to achieve code execution on the PSP and then use the PSP to write to the SPI flash. Both of these methods are theories we've been running in our lab. They may work, but we haven't tested them. Results may vary from hardware to hardware.
Previous work on this subject: https://www.mitre.org/sites/default/files/publications/defeating-signed-bios-enforcement.pdf, https://embedi.com/blog/bypassing-intel-boot-guard/
TPU: Do you think it's feasible for users to solder a pull-down wire onto the WP# [write-protect] pin of the BIOS chip? To permanently, physically, engage its write protection.
CTS: Off the top of my head (and of course I haven't tested this) - Turning on Write-Protect for the whole chip would not work, because that would break Non-volatile Storage features that are needed by both UEFI and the PSP.
TPU: Can you elaborate on how the Ryzenfall attack works? Is the Secure Processor exposed as device on the PCI bus? and attacked directly? Or does the attack leverage issues in the CPU's memory controller?
CTS: We don't feel comfortable talking about RYZENFALL at this time.
TPU: To execute the Chimera attack (and others) you mention "vendor supplied driver". Shouldn't any signed kernel mode driver be sufficient as long as it implements IO space access (for PCI config space on CF8) and some method of writing to physical memory, either directly or through memory mapping a specified range to user space?
CTS: You are exactly right. Any signed driver that provides access to IO spaces is sufficient to interact with the backdoors. There is a vendor-supplied driver that does this.
TPU: Are those vendor supplied drivers publicly available for download?
CTS: Yes.
TPU: As far as we know, the BIOS chip is connected to the CPU socket and not to the chipset. This means that Chimera is not able to write to the flash directly and has to write code to system RAM first, which then gets executed, and performs the write into NAND?
CTS: To the best of my knowledge, all Zen architecture chips have an integrated southbridge, but the Promontory chipset is nonetheless used on most (all?) Ryzen and Ryzen Pro workstations. Promontory provides additional USB, SATA, and PCI-E ports to AMD systems. On one laptop that we've tested (ASUS GL702ZC), the USB ports on one side of the machine are routed to the chipset, while others are routed to the CPU. The USB ports connected to the CPU don't support 10 Gb USB 3.1.
The backdoors in AMD Promontory let attackers inject malware into the chip on runtime. We did not attempt to achieve persistency on Promontory. Promontory's firmware is stored inside the BIOS image, and is written into the chipset's 8051 processor by a UEFI module every time the computer boots. If that UEFI module happens to be missing, Promontory will boot from its built-in ROM firmware. So, to clarify, attackers can freely patch the 8051 code memory on runtime.
TPU: Does that mean that users could protect themselves against Chimera-based keyloggers by not using certain USB ports on their system?
CTS: For keyloggers that record USB traffic from within the chipset, I believe so.
TPU: Your whitepaper describes that the ASMedia chip has backdoors both in software and hardware. Could you elaborate on the hardware part, is it patchable somehow?
CTS: The Ryzen chipset is an ASIC chip. What this means is that after fabrication, the chip's structure of logic gates can no longer be changed [unlike on an FPGA]. We have found what we believe to be manufacturer backdoors implemented on the ASIC level. If our understanding is correct, removing these backdoors is impossible. It may still be possible to find a workaround, for example by blocking access to certain IO regions at the hypervisor level.
Other backdoors with similar functionality exist in the chipset firmware as well. These can be removed by a firmware update.
TPU: Do you have any plans to release more details on these vulnerabilities to the public?
CTS: We have no such plans. We've delivered full details of the vulnerabilities to AMD, Microsoft, US-CERT, Dell, HP, Cisco, Symantec, FireEye, and CrowdStrike. Our package includes full technical write-ups, functional proof-of-concept exploits and procedures on how to run the exploits. We will wait for these companies to come out with patches and mitigations before releasing technical details to the public.
Once MASTERKEY is patched and the patches have had time to disseminate, we are thinking of partnering up with libreboot or coreboot to develop a way to shutdown the PSP. Doing this would completely eradicate the attack surface for vulnerabilities such as FALLOUT and RYZENFALL. AMD has recently offered a BIOS option to disable the PSP, but according to our testing that feature merely disables the fTPM... other functionalities remain open, and the Secure Processor remains vulnerable to RYZENFALL or FALLOUT. If there was a real option to halt the PSP's ARM processor, that would be a great security feature.
TPU: Do you think users of other CPU vendors, like Intel, are affected?
CTS: Only if they have a motherboard carrying an ASMedia USB host controller. These controllers are typically found on PC motherboards made by Taiwanese manufacturers. We've looked into quite a few computers made by HP, Dell, Lenovo, etc. and they were not affected.
TPU: A huge number of Intel motherboards uses ASMedia chips, too, mostly for additional USB 3 ports. Does that mean these are affected by vulnerabilities similar to Chimera? Does it make a difference that the chips on Intel motherboards are connected via PCIe? Which chips are we talking about?
CTS: All ASMedia USB host controllers sit on the PCI-E bus. I am talking about ASM1042, ASM1142 and ASM1143. Motherboards that have these chips have the CHIMERA backdoors as well.
TPU: Have you tested whether the Secure Processor in Vega GPUs is vulnerable?
CTS: We haven't looked into that.
TPU: How do you respond to people saying that once an attacker has administrative access, you are f'd anyway? How are the attacks you uncovered more severe?
CTS: This is misleading and incorrect. Attackers think of machines not as individual nodes but as part of a network. Gaining local administrative access on a compromised computer inside an organization is easy for attackers. The challenge is moving laterally from there to other machines, and maintaining access for the future. That is exactly what these vulnerabilities provide.
TPU: Are you in two-way communication with AMD? How are things moving forward, if you can reveal that?
CTS: AMD only sent us a confirmation that they received the materials. We are curious what's taking them so long. It only took CrowdStrike one day to have a good understanding of the vulnerabilities. It took two days for Microsoft Security to be completely on top of it, and Trail of Bits validated our research in its entirety within five days.
TPU: What's your recommendation to users and companies at this time? Should people be scared and disconnect their systems from the Internet?
CTS: I think that high-security organizations, such as banks, that happen to have deployments of vulnerable AMD equipment should certainly be concerned - because of the possibility of APT actors using the vulnerabilities to conduct lateral movement, and malware setting up camp inside the Secure Processor. It is up to each company to conduct its own risk analysis.
TPU: How do you respond to the chaos and cynicism that has erupted because of the manner in which you made your public disclosures?
CTS: We are a small group of security researchers. We have no past experience with making publications, and there is no question we messed this one up. We certainly learned some hard lessons here.
TPU: Thank you for responding to our questions, we'll stay in touch.
CTS: Absolutely. Thank you.
If you have any additional technical questions, or haven't understood something, let us know in the comments section, we will answer what we can by ourselves and forward select questions to CTS for better explanation.
View at TechPowerUp Main Site
TechPowerUp (TPU): Regarding Masterkey. Could you elaborate on the attack vector for this? AMD makes the claim that the on-chip ROM in Secure Processor fully validates the firmware read from NAND. You mention metadata parsing, which I assume is stored in the NAND, so when this is modified in a certain way the hash check gets bypassed? With Secure Processor validation broken, the UEFI signature checks for the main BIOS can be bypassed, too? Or is it additionally required to modify the main BIOS, too, for that to work?
CTS-Labs (CTS): First a small clarification: the BIOS and PSP firmwares, as well as certain non-volatile storage data are typically stored on a single SPI flash chip on the motherboard. When you install a BIOS update, both UEFI and PSP firmwares get replaced. MASTERKEY-1 through MASTERKEY-3 allow three distinct ways of installing malware on the PSP in spite of digital signature verification. The way this process works is: The PSP immutable ROM runs first, and then validates the beginning of the mutable PSP firmware inside the SPI flash. The PSP firmware then loads its other built-in modules, such as fTPM or SEV. This is when MASTERKEY kicks in to allow execution of unsigned code on the PSP's ARM processor. This can happen even before the PSP releases the main CPU from its initial halted state. Secure Boot is defeated from that point on (both UEFI Secure Boot and PSP Secure Boot).
Re-flashing the BIOS, a prerequisite for MASTERKEY, often does not require physical access to the device. We've tested this on motherboards by Tyan, ASUS, MSI, Gigabyte, Biostar, and others. It works by running an EXE.
TPU: Did you use an official flashing software, or create your own method that replicates the commands used by this software?
CTS: We used a modified version of the original BIOS update software. That allowed us to bypass some protections that exist in the original version.
TPU: You mention a few motherboard companies above, do you feel this means that all motherboards are affected, or are some more secure than others?
CTS: On motherboards where flashing is not possible because the BIOS image is encapsulated and signed by an additional layer of OEM-specific digital signature, we think it may still be possible to install a malicious BIOS that exploits MASTERKEY by either: (a) Using RYZENFALL or FALLOUT to achieve code execution on SMM, and disable signature verification that is implemented in SMM, or (b) Use RYZENFALL-4 to achieve code execution on the PSP and then use the PSP to write to the SPI flash. Both of these methods are theories we've been running in our lab. They may work, but we haven't tested them. Results may vary from hardware to hardware.
Previous work on this subject: https://www.mitre.org/sites/default/files/publications/defeating-signed-bios-enforcement.pdf, https://embedi.com/blog/bypassing-intel-boot-guard/
TPU: Do you think it's feasible for users to solder a pull-down wire onto the WP# [write-protect] pin of the BIOS chip? To permanently, physically, engage its write protection.
CTS: Off the top of my head (and of course I haven't tested this) - Turning on Write-Protect for the whole chip would not work, because that would break Non-volatile Storage features that are needed by both UEFI and the PSP.
TPU: Can you elaborate on how the Ryzenfall attack works? Is the Secure Processor exposed as device on the PCI bus? and attacked directly? Or does the attack leverage issues in the CPU's memory controller?
CTS: We don't feel comfortable talking about RYZENFALL at this time.
TPU: To execute the Chimera attack (and others) you mention "vendor supplied driver". Shouldn't any signed kernel mode driver be sufficient as long as it implements IO space access (for PCI config space on CF8) and some method of writing to physical memory, either directly or through memory mapping a specified range to user space?
CTS: You are exactly right. Any signed driver that provides access to IO spaces is sufficient to interact with the backdoors. There is a vendor-supplied driver that does this.
TPU: Are those vendor supplied drivers publicly available for download?
CTS: Yes.
TPU: As far as we know, the BIOS chip is connected to the CPU socket and not to the chipset. This means that Chimera is not able to write to the flash directly and has to write code to system RAM first, which then gets executed, and performs the write into NAND?
CTS: To the best of my knowledge, all Zen architecture chips have an integrated southbridge, but the Promontory chipset is nonetheless used on most (all?) Ryzen and Ryzen Pro workstations. Promontory provides additional USB, SATA, and PCI-E ports to AMD systems. On one laptop that we've tested (ASUS GL702ZC), the USB ports on one side of the machine are routed to the chipset, while others are routed to the CPU. The USB ports connected to the CPU don't support 10 Gb USB 3.1.
The backdoors in AMD Promontory let attackers inject malware into the chip on runtime. We did not attempt to achieve persistency on Promontory. Promontory's firmware is stored inside the BIOS image, and is written into the chipset's 8051 processor by a UEFI module every time the computer boots. If that UEFI module happens to be missing, Promontory will boot from its built-in ROM firmware. So, to clarify, attackers can freely patch the 8051 code memory on runtime.
TPU: Does that mean that users could protect themselves against Chimera-based keyloggers by not using certain USB ports on their system?
CTS: For keyloggers that record USB traffic from within the chipset, I believe so.
TPU: Your whitepaper describes that the ASMedia chip has backdoors both in software and hardware. Could you elaborate on the hardware part, is it patchable somehow?
CTS: The Ryzen chipset is an ASIC chip. What this means is that after fabrication, the chip's structure of logic gates can no longer be changed [unlike on an FPGA]. We have found what we believe to be manufacturer backdoors implemented on the ASIC level. If our understanding is correct, removing these backdoors is impossible. It may still be possible to find a workaround, for example by blocking access to certain IO regions at the hypervisor level.
Other backdoors with similar functionality exist in the chipset firmware as well. These can be removed by a firmware update.
TPU: Do you have any plans to release more details on these vulnerabilities to the public?
CTS: We have no such plans. We've delivered full details of the vulnerabilities to AMD, Microsoft, US-CERT, Dell, HP, Cisco, Symantec, FireEye, and CrowdStrike. Our package includes full technical write-ups, functional proof-of-concept exploits and procedures on how to run the exploits. We will wait for these companies to come out with patches and mitigations before releasing technical details to the public.
Once MASTERKEY is patched and the patches have had time to disseminate, we are thinking of partnering up with libreboot or coreboot to develop a way to shutdown the PSP. Doing this would completely eradicate the attack surface for vulnerabilities such as FALLOUT and RYZENFALL. AMD has recently offered a BIOS option to disable the PSP, but according to our testing that feature merely disables the fTPM... other functionalities remain open, and the Secure Processor remains vulnerable to RYZENFALL or FALLOUT. If there was a real option to halt the PSP's ARM processor, that would be a great security feature.
TPU: Do you think users of other CPU vendors, like Intel, are affected?
CTS: Only if they have a motherboard carrying an ASMedia USB host controller. These controllers are typically found on PC motherboards made by Taiwanese manufacturers. We've looked into quite a few computers made by HP, Dell, Lenovo, etc. and they were not affected.
TPU: A huge number of Intel motherboards uses ASMedia chips, too, mostly for additional USB 3 ports. Does that mean these are affected by vulnerabilities similar to Chimera? Does it make a difference that the chips on Intel motherboards are connected via PCIe? Which chips are we talking about?
CTS: All ASMedia USB host controllers sit on the PCI-E bus. I am talking about ASM1042, ASM1142 and ASM1143. Motherboards that have these chips have the CHIMERA backdoors as well.
TPU: Have you tested whether the Secure Processor in Vega GPUs is vulnerable?
CTS: We haven't looked into that.
TPU: How do you respond to people saying that once an attacker has administrative access, you are f'd anyway? How are the attacks you uncovered more severe?
CTS: This is misleading and incorrect. Attackers think of machines not as individual nodes but as part of a network. Gaining local administrative access on a compromised computer inside an organization is easy for attackers. The challenge is moving laterally from there to other machines, and maintaining access for the future. That is exactly what these vulnerabilities provide.
TPU: Are you in two-way communication with AMD? How are things moving forward, if you can reveal that?
CTS: AMD only sent us a confirmation that they received the materials. We are curious what's taking them so long. It only took CrowdStrike one day to have a good understanding of the vulnerabilities. It took two days for Microsoft Security to be completely on top of it, and Trail of Bits validated our research in its entirety within five days.
TPU: What's your recommendation to users and companies at this time? Should people be scared and disconnect their systems from the Internet?
CTS: I think that high-security organizations, such as banks, that happen to have deployments of vulnerable AMD equipment should certainly be concerned - because of the possibility of APT actors using the vulnerabilities to conduct lateral movement, and malware setting up camp inside the Secure Processor. It is up to each company to conduct its own risk analysis.
TPU: How do you respond to the chaos and cynicism that has erupted because of the manner in which you made your public disclosures?
CTS: We are a small group of security researchers. We have no past experience with making publications, and there is no question we messed this one up. We certainly learned some hard lessons here.
TPU: Thank you for responding to our questions, we'll stay in touch.
CTS: Absolutely. Thank you.
If you have any additional technical questions, or haven't understood something, let us know in the comments section, we will answer what we can by ourselves and forward select questions to CTS for better explanation.
View at TechPowerUp Main Site
