This site may earn affiliate commissions from the links on this page. Terms of use.

AMD-HBM

Last week, a heretofore unknown security company, CTS Labs, published bombshell allegations of what it declared were 13 disquisitional security flaws that impacted AMD'southward Ryzen CPUs and chipsets. It quickly became articulate the entire disclosure process was unusual, to put it mildly, and there's skillful reason to think the unabridged thing was orchestrated by a firm hoping to make a quick cadet shorting AMD stock. AMD has now responded to CTS Labs' initial findings, kicking the legs out from one of the visitor's defenses for its own deportment in the procedure.

All xiii of the flaws identified by CTS Labs require administrative admission to exploit. While this fact does not excuse any given security consequence, it does put the problems into context — if you have administrator access to a system, yous factually tin can compromise it using whatsoever number of attacks. AMD then breaks down the 3 major vulnerability families and provides an updated timeline for when fixes are expected in-market.

AMD-Ryzen-Flaws

Of detail interest is AMD's statements that solutions for all three sets of vulnerabilities are expected to go far in a matter of weeks. That'due south meaning, given CTS Labs' stated rationale for its ain disclosure practices.HowLongBeforeFix

CTS Labs doubled downwards on its timeline statement in an interview with Anandtech, when its CFO, Yaron Luk-Zilberman, said: "I judge it will exist many many months before AMD is able to patch these things. If we had said to them, let's say, 'y'all guys have 30 days/90 days to do this' I don't call back information technology would matter very much."

CTS is, and was, completely incorrect on this point. Reasonable people can disagree on how security disclosures should exist handled or how much time, if whatever, should be provided to the manufacturer to gear up its problems. In this example, notwithstanding, CTS Labs' failure to discuss its own findings with AMD take undercut its ain stated reasons for the manner and nature of its disclosure. It will non take "many months" to prepare these problems and they do not put lives at stake — which was one of CTS Labs' other justifications for why it used the linguistic communication it did in its initial disclosure:

AMD-Security-Lives

No reckless exaggeration here.

TrailofBits, which performed a third-political party assay and verification of the bugs CTS located, writes:

At that place is no immediate risk of exploitation of these vulnerabilities for most users. Fifty-fifty if the full details were published today, attackers would need to invest meaning development efforts to build attack tools that employ these vulnerabilities. This level of effort is beyond the attain of nearly attackers…

These types of vulnerabilities should not surprise whatever security researchers; like 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 exercise not represent a cataclysmic security failure. They certainly practice not represent the company-ending apocalypse that CTS Labs' suspected partner-in-crime, Viceroy Research, said they did. Meanwhile, in that location's no sign of whatever endeavour by CTS Labs to accost 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, beginning to finish, appears to have been an attempt to weaponize security disclosures and harm a visitor in the name of earning coin for unscrupulous investors. It's a textbook example of why security assay and disclosure must be handled carefully. Just none of this changes the fact that these security issues shouldn't take existed in the first place.

Both AMD and Intel have asked estimator users to take 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 ain Quark CPU. Both companies take resisted calls to provide documentation and/or open source lawmaking for these solutions, and notwithstanding the security of both has repeatedly been plant wanting. As devices go more tightly integrated and the number of components and IP blocks integrated into SoCs rises, it's increasingly important manufacturers follow all-time security practices from commencement to cease. Both Intel and AMD have more than work to do in this regard.