Thursday, March 16th 2017

CTS-Labs Responds to a TechPowerUp Technical Questionnaire

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.
Add your own comment

64 Comments on CTS-Labs Responds to a TechPowerUp Technical Questionnaire

#1
IceScreamer
This was nicely detailed and technical enough, for me at least, to understand. What I'm also surprised by is the Asmedia chip situation. So basically some of these vulnerabilities could possibly spill over to Intel (correct me if I'm wrong).

Thhe biggest question for me is will it be possible to effectively patch these vulnerabilities (not the ones connected to the Asmedia chip MBOs), and if there will be a trade off to the performance/usability?
Posted on Reply
#2
xkm1948
Acknowledged all AsMedia based USB chipsets are vulnerable, yet still targeting just one specific company. If there is any concern it should be Intel MoBo which has way higher market share and they got 0 mention. Fishy AF.

CTS can spin this whatever they want. At least this end user is not buying into their BS.

Security experts, including Linus, weighs in on the situation after thr anandtech phone call.

https://www.realworldtech.com/forum/?threadid=175139&curpostid=175169


Lets see what they say after TPU phone call
Posted on Reply
#3
kruk
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.
LOL, unbelievable. Meltdown and Spectre were an great example how to properly disclose a HW vulnerability, but I guess they somehow missed it. I guess the news didn't give those vulnerabilities enough coverage ... Oh, wait ... :banghead:
Posted on Reply
#4
Aldain
Stop giving these frauds coverage..

p.s If the AsMedia is also at fault then Intel is also most liley affected.. But I do not see www.http (what kind of "security" company does not use HTTPS) IntelFlaws.com
Posted on Reply
#5
Kaotik
"We're 16 year veterans in information security but we don't have experience on stuff like this" - yeah, that sounds about right :rolleyes:
Posted on Reply
#6
EarthDog
xkm1948 said:
Acknowledged all AsMedia based USB chipsets are vulnerable, yet still targeting just one specific company. If there is any concern it should be Intel MoBo which has way higher market share and they got 0 mention. Fishy AF.
Is it "all" though???
W1zzard said:
I am talking about ASM1042, ASM1142 and ASM1143. Motherboards that have these chips have the CHIMERA backdoors as well.
There are many ASMedia USB controllers out there. Without looking at reviews, I know most USB 3.1 G2 are ASM3142 or 2142 chips. Those listed at 3.1 G1 and I believe two generations old?
Posted on Reply
#7
Shamalamadingdong
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
So they don't know how processors have been patched previously? The recent industry-wide Spectre patches escaped their notice?
Posted on Reply
#8
qubit
Overclocked quantum bit
Ok, I haven't had a chance to properly read this yet, but the takeaway seems to be that regular users like us don't need to be concerned and that AMD is taking an unusually long time to get on top of this. I can only imagine that they're looking at the problem from a deeper perspective than the likes of Microsoft, since they designed the CPU.
Posted on Reply
#9
R-T-B
Shamalamadingdong said:
So they don't know how processors have been patched previously? The recent industry-wide Spectre patches escaped their notice?
Processors have microcode. Chipsets don't. And hardcoded backdoors are very different from spectre.
Posted on Reply
#10
phanbuey
What I am confused about is the response to:

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.

How do these vulnerabilities allow 'moving laterally from there to other machines', if the you don't have access Admin access to the other machines on the network? Once you have admin access to a machine you can install a whole host of malware that will maintain access... but wouldn't these specific vulnerabilities still be useless for moving across the network?

I'm a local admin on my machine, it would be very, very difficult for me to install a driver or flash a bios across the network on a machine where my local admin account doesn't exist.... and once you have domain admin you have access to the whole network... so am I missing something?
Posted on Reply
#11
dyonoctis
https://blog.trailofbits.com/2018/03/15/amd-flaws-technical-summary/
There is no immediate risk of exploitation of these vulnerabilities for most users. Even if the full details were published today, attackers would need to invest significant development efforts to build attack tools that utilize these vulnerabilities. This level of effort is beyond the reach of most attackers (see https://www.usenix.org/system/files/1401_08-12_mickens.pdf, Figure 1)

These types of vulnerabilities should not surprise any security researchers; similar flaws have been found in other embedded systems that have attempted to implement security features. They are the result of simple programming flaws, unclear security boundaries, and insufficient security testing. In contrast, the recent Meltdown and Spectre flaws required previously unknown techniques and novel research advances to discover and exploit.
If those guys would have just done like any other cybersecurity company and try to work closely with AMD, the situation would have been better.
But no, they had to play "herald of justice" and bring chaos all over the place.
Those guys apparently worked in the equivalent of the NSA in Israel, but they really didn't see just how many things were wrong with the way they did it ?
Posted on Reply
#12
R0H1T
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.
This doesn't sound genuine at all, they just wanted their 2 minutes of fame &/or a shorting opportunity :rolleyes:
Posted on Reply
#13
ZeppMan217
qubit said:
regular users like us don't need to be concerned and that AMD is taking an unusually long time to get on top of this
Regular users should pay attention so that the next "CTS-Labs" wouldn't be able to bait people into end of the world stock sale. And why the cheap stab at AMD? Intel had 9 months to fix their shit and did nothing until it became public knowledge, as is indicated by the poor initial implementation of patches, yet you and "16 years of experience" with no experience expect the fixes yesterday?
Posted on Reply
#14
R0H1T
phanbuey said:
What I am confused about is the response to:

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.

How do these vulnerabilities allow 'moving laterally from there to other machines', if the you don't have access Admin access to the other machines on the network? Once you have admin access to a machine you can install a whole host of malware that will maintain access... but wouldn't these specific vulnerabilities still be useless for moving across the network?

I'm a local admin on my machine, it would be very, very difficult for me to install a driver or flash a bios across the network on a machine where my local admin account doesn't exist.... and once you have domain admin you have access to the whole network... so am I missing something? How would these help in breaking into a network
Yes, somehow they're making it sound like compromising a workstation (desktop) is the same as getting unrestricted access to one's (main) servers. Unless of course the local network allows root access from any & every system on it, in which case you're o_O
Posted on Reply
#15
thesmokingman
Why you no ask them how much they are getting paid and whom do they work for? Why you no ask them how they get password to run their special bios flasher? W/o admin how do they run their exploits?
Posted on Reply
#16
phanbuey
R0H1T said:
Yes, somehow they're making it sound like compromising a workstation (desktop) is the same as getting unrestricted access to one's servers. Unless of course the local network allows root access from any & every system on it, in which case you're o_O
They worded it carefully, but what they're essentially saying is "it will help an attacker maintain access" the part before it about the network looks like fluff.

The most dangerous exploits are the ones that GIVE privileges (a la spectre/meltdown) , once you have privileges I can download a few dozen tools just by googling to maintain access and try to move.
Posted on Reply
#17
oxidized
thesmokingman said:
Why you no ask them how much they are getting paid and whom do they work for? Why you no ask them how they get password to run their special bios flasher? W/o admin how do they run their exploits?
I can answer that! Intel and nvidia are paying them a sh*tload of money.
/s
Posted on Reply
#18
R0H1T
phanbuey said:
They worded it carefully, but what they're essentially saying is "it will help an attacker maintain access" the part before it about the network looks like fluff.

The most dangerous exploits are the ones that GIVE privileges (a la spectre/meltdown) , once you have privileges I can download a few dozen tools just by googling to maintain access and try to move.
I'd agree with the sentiment but spectre & meltdown don't need privileged access AFAIK, that's why they're the worst thing to happen to the computing landscape in over 2 decades.
Posted on Reply
#19
the54thvoid
Can you ask about the clearly stated 'interest' in the financial side of things and the almost instant review of their work by Vicereroy (and it's scathing financial review of AMD)? The piece by Gamers Nexus clearly established a link to investment funds and it is this which woried people the most about the vericity of the CTS-Labs report. Can you ask if they can explain how Viceroy created such a rapid response (https://viceroyresearch.files.wordpress.com/2018/03/amd-the-obituary-13-mar-2018.pdf) to the piece and why the piece they wrote was so heavily invested in non-technical 'fear mongering' language.

The concern to me and many like me is the association this report has with possible stock manipulation. For Viceroy Research to produce a near instant 25 page PDF report on the CTS-Lab report is worrying when Viceroy remain an anonymous group and specialise in short selling.

As potentially harmful (with a heck of a lot of work) these exploits are (that require pre-installation of malware to work), it is the work behind the scenes that worries me and others regarding how the private investment world is seemingly seeking to manipulate stock value.
Posted on Reply
#20
EarthDog
qubit said:
Ok, I haven't had a chance to properly read this yet, but the takeaway seems to be that regular users like us don't need to be concerned and that AMD is taking an unusually long time to get on top of this. I can only imagine that they're looking at the problem from a deeper perspective than the likes of Microsoft, since they designed the CPU.
Or, as was already mentioned in some articles (TPU included - I believe I posted it here as well in one of the threads), that 3rd party verification took ToB 4-5 days. If AMD was notified on Tuesday, this would be the 4th day. I wouldn't expect anything until Monday.


I gotta say though the delivery was quite possibly the worst ever, my focus is on the vulnerabilities...regardless if they are fairly innocuous to us as end users (cloud providers on the other hand...).
Posted on Reply
#21
the54thvoid
As a pretty damning follow up to this story concerning the ASMedia issues:

https://www.extremetech.com/computing/265695-cts-labs-responds-allegations-bad-faith-amd-security-disclosures-digs-deeper-hole
By its own statements, CTS Labs tested and developed a proof of concept exploit for Asmedia controllers before it was aware these controllers were incorporated into Ryzen chipsets. Where, then, is the website AsmediaFlaws.com? Where’s the notification to tell Intel motherboard customers that the chips on their motherboards can be similarly backdoored and abused? This isn’t a theoretical; I’m writing this article from an Ivy Bridge-E system powered by an Asus X79-Deluxe motherboard with an Asmedia 1042 controller. In its white paper, CTS Labs describes the offending Asmedia controllers as follows:

In our assessment, these controllers, which are commonly found on motherboards made by Taiwanese OEMs, have sub-standard security and no mitigations against exploitation. They are plagued with security vulnerabilities in both firmware and hardware, allowing attackers to run arbitrary code inside the chip, or to reflash the chip with persistent malware.
This flaw absolutely affects Intel as well as AMD. It actually (as Extremetech points out) should have had its own website, ASMediaflaws.com
Posted on Reply
#22
qubit
Overclocked quantum bit
EarthDog said:
Or, as was already mentioned in some articles (TPU included - I believe I posted it here as well in one of the threads), that 3rd party verification took ToB 4-5 days. If AMD was notified on Tuesday, this would be the 4th day. I wouldn't expect anything until Monday.


I gotta say though the delivery was quite possibly the worst ever, my focus is on the vulnerabilities...regardless if they are fairly innocuous to us as end users (cloud providers on the other hand...).
Yeah, I'd give it at least a week for AMD to give a proper response. Seems reasonable to me.
Posted on Reply
#23
dyonoctis
the54thvoid said:
Can you ask about the clearly stated 'interest' in the financial side of things and the almost instant review of their work by Vicereroy (and it's scathing financial review of AMD)? The piece by Gamers Nexus clearly established a link to investment funds and it is this which woried people the most about the vericity of the CTS-Labs report. Can you ask if they can explain how Viceroy created such a rapid response (https://viceroyresearch.files.wordpress.com/2018/03/amd-the-obituary-13-mar-2018.pdf) to the piece and why the piece they wrote was so heavily invested in non-technical 'fear mongering' language.

The concern to me and many like me is the association this report has with possible stock manipulation. For Viceroy Research to produce a near instant 25 page PDF report on the CTS-Lab report is worrying when Viceroy remain an anonymous group and specialise in short selling.

As potentially harmful (with a heck of a lot of work) these exploits are (that require pre-installation of malware to work), it is the work behind the scenes that worries me and others regarding how the private investment world is seemingly seeking to manipulate stock value.
Anandtech tried to question them about that, they didn't really got an answer :
"
IC: Did you pre-brief the press before you spoke to AMD?


ILO: What do you mean by pre-brief the press?


IC: We noticed that when the information went live, some press were ready to go with relevant stories and must have had the information in advance.


ILO: Before our announcement you mean?


IC: Correct.


ILO: I would have to check the timing on that and get back to you, I do not know off the top of my head.

"
Posted on Reply
#24
RejZoR
The "we had no past experience" is such BS when it comes to questioning how they released the info and gave vendor next to no time. You don't just drop into the security scene without knowing at least basics how it works. I'm no vulnerability specialist and even I bloody know how it works. Saying they didn't know is just distilled horsepiss.
Posted on Reply
#25
Shamalamadingdong
R-T-B said:
Processors have microcode. Chipsets don't. And hardcoded backdoors are very different from spectre.
Are you saying the PSP (which is a processor) can't receive microcode updates? The majority of the exploits pertain to the PSP. It was only the ASMedia chipset that was said to have a hardware backdoor. No information given indicates the PSP is unpatchable.
Posted on Reply
Add your own comment