AMD Responds to CTS Labs Security Allegations, Resolutions Incoming
Last week, a heretofore unknown security company, CTS Labs, published bombshell allegations of what it declared were 13 critical security flaws that impacted AMD’s Ryzen CPUs and chipsets. It quickly became clear the entire disclosure process was unusual, to put it mildly, and there’s good reason to think the entire affair was orchestrated by a firm hoping to make a quick buck shorting AMD stock. AMD has now responded to CTS Labs’ initial findings, kicking the legs out from one of the company’s defenses for its own actions in the process.
All 13 of the flaws identified by CTS Labs require administrative access to exploit. While this fact does not excuse any given security issue, it does put the problems into context — if you have administrator access to a system, you factually can compromise it using any number of attacks. AMD then breaks down the three major vulnerability families and provides an updated timeline for when fixes are expected in-market.
Of particular interest is AMD’s statements that solutions for all three sets of vulnerabilities are expected to arrive in a matter of weeks. That’s significant, given CTS Labs’ stated rationale for its own disclosure practices.
CTS Labs doubled down on its timeline argument in an interview with Anandtech, when its CFO, Yaron Luk-Zilberman, said: “I estimate it will be many many months before AMD is able to patch these things. If we had said to them, let’s say, ‘you guys have 30 days/90 days to do this’ I don’t think it would matter very much.”
CTS is, and was, completely wrong on this point. Reasonable people can disagree on how security disclosures should be handled or how much time, if any, should be provided to the manufacturer to fix its problems. In this case, however, CTS Labs’ failure to discuss its own findings with AMD have undercut its own stated reasons for the manner and nature of its disclosure. It will not take “many months” to fix these problems and they do not put lives at stake — which was one of CTS Labs’ other justifications for why it used the language it did in its initial disclosure:
TrailofBits, which performed a third-party analysis and verification of the bugs CTS located, writes:
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…
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.
The flaws are real, require updates, and need to be dealt with — but they do not represent a cataclysmic security failure. They certainly do not represent the company-ending apocalypse that CTS Labs’ suspected partner-in-crime, Viceroy Research, said they did. Meanwhile, there’s no sign of any effort by CTS Labs to address the backdoors and critical security flaws baked into tens of millions of Intel motherboards courtesy of their onboard Asmedia controllers, even though the ASM1042 and ASM1142 have shipped on Intel products for the past six years.
Bad Faith Doesn’t Excuse Bad Security
CTS Labs entire effort, start to finish, appears to have been an attempt to weaponize security disclosures and harm a company in the name of earning money for unscrupulous investors. It’s a textbook example of why security analysis and disclosure must be handled carefully. But none of this changes the fact that these security issues shouldn’t have existed in the first place.
Both AMD and Intel have asked computer users to accept the presence of black box security implementations in the name of increased security. Intel has its Intel Management Engine, AMD has its TrustZone processor. AMD uses an ARM solution with a Cortex-A5 integrated processor, Intel uses its own Quark CPU. Both companies have resisted calls to provide documentation and/or open source code for these solutions, and yet the security of both has repeatedly been found wanting. As devices become more tightly integrated and the number of components and IP blocks integrated into SoCs rises, it’s increasingly important manufacturers follow best security practices from start to finish. Both Intel and AMD have more work to do in this regard.