AMD

Ilia Luk-Zilberman, the Chief Technical Officer (CTO) of CTS Labs, the company behind yesterday's disclosure of 13 vulnerabilities affecting AMD processors, has published an open letter today, explaining his company's controversial actions that managed to enrage a huge portion of the tech and security research communities.

CTS Labs faced a massive backlash yesterday, on a scale rarely seen in the security industry, for the way it decided to approach the process of "vulnerability disclosure" of 13 AMD CPU flaws collectively known under four codenames —RyzenFall, MasterKey, Fallout, and Chimera.

CTS Labs criticized for disclosing too quickly

According to an AMD spokesperson, CTS Labs gave the chip maker less than 24 hours to read a technical report, verify, reproduce, and prepare patches, a deadline that many security researchers found impossible to abide with.

The Tel Aviv-based CTS Labs then moved forward to publicly disclose the 13 vulnerabilities via an embargoed press release shared with selected news agencies, with greenscreened YouTube videos, a fancy website, and a whitepaper that lacked any technical details.

The security community tore into the company, who quickly became a subject of jokes and ridicule. Discussions on social media quickly moved to theories that CTS Labs was trying to short AMD stock using "manufactured" vulnerabilities in an attempt to buy shares at lower values.

AMD flaws independently verified by two credible sources

Those theories were short-lived because a few hours after CTS Labs took a beating on social media and some infosec blogs, Dan Guido, the CEO of Trail of Bits —another security company— came forward to confirm that the CTS Labs report was real and contained actual vulnerabilities.

Yaron Luk, the CFO of CTS Labs, confirmed to Bleeping Computer yesterday via email that the company had asked the Trail of Bits team to run an independent review of their findings, a fact that Guido confirmed on Twitter.

Furthermore, earlier today, Alex Ionescu, one of the most respected figures in the security research community, also confirmed that, he too, had seen the technical report that CTS Labs sent AMD, and that it contained "legit design & implementation issues."

AMD flaws can turn bad hacks into worse hacks

Ionescu also addressed another major criticism directed at CTS Labs —the fact that many security researchers derided the Israeli company because all of the 13 flaws required an attacker to gain admin rights before they could be exploited.

Ionescu disagreed that some security researchers were dismissing the severity of CTS Labs' findings just because the flaws required admin access.

"Admin-level access and persistance are legitimate threats in multi-tenant IaaS [Infrastructure-as-a-Service] and even things such as VTL0/1 (Credential Guard) when firmware and chipset trust boundaries are broken," Ionescu said on Twitter today.

As the dust settled after yesterday's overly-cosmeticized vulnerability disclosure, many security researchers are now not so dismissive of CTS Labs' findings, and the conspiracy theories about shorting AMD stock are starting to be replaced by warnings that the AMD flaws "could turn bad hacks into worse hacks."

This was because experts started realizing that attackers could use these AMD vulnerabilities to gain post-reinstall persistence by leaving malicious code in secure areas of the CPU. Areas where security software can't scan or reach, and where malicious attackers wouldn't normally be able to reach, admin access or not.

CTS Labs proposes a new type of "vulnerability disclosure"

It was these issues that Luk-Zilberman attempted to address in an open letter today, with a large part of the letter dedicated to the company's decision to disclose the flaws right away, without giving AMD the time to prepare patches. According to Luk-Zilberman, this was intentional.

I know this is an extremely heated topic for debate, where everyone has a strong opinion. Unfortunately, I also have a strong opinion on this topic.

I think that the current structure of “Responsible Disclosure” has a very serious problem. If a researcher finds a vulnerability, this model  suggests that the researcher and the vendor work together to build mitigations, with some time limit (30/45/90 days), at the end of which the researcher will go out with the vulnerabilities. The time limit is meant to hasten the vendor to fix the issues.

The main pro blem in my eyes with this model is that during these 30/45/90 days, it’s up to the vendor if it wants to alert the customers that there is a problem. And as far as I’ve seen, it is extremely rare that the vendor will come out ahead of time notifying the customers – “We have problems that put you at risk, we’re working on it”. Almost always it’s post-factum – “We had problems, here’s the patch – no need to worry”.

The second problem is - if the vendor doesn’t fix it in time – what then? The researcher goes public? With the technical details and exploits? Putting customers at risk? How we have accepted this mode of operation is beyond me, that researchers advertise at the end of the time limit the technical details of the vulnerabilities “because” the vendor didn’t respond. Why should the customers pay for the vendor’s lack of actions. I understand – this is the model today and people follow suit, but I think we can do better.

Instead, the CTS Labs CTO proposes something altogether new for the vulnerability disclosure process.

I think that a better way, would be to notify the public on day 0 that there are vulnerabilities and what is the impact. To notify the public and the vendor together. And not to disclose the actual technical details ever unless it’s already fixed. To put the full public pressure on the vendor from the get go, but to never put customers at risk.

Some will agree with Luk-Zilberman's proposal, albeit some security experts will remain set in their ways.

Looking back at CTS Labs' recent disclosure, the company did abide by this principle, notifying both AMD and the public about the flaws, but only providing in-depth technical details to AMD's staff and a few selected researchers.

At the time of writing, in-depth technical details about the 13 flaws are not public. If we are to believe Luk-Zilberman's open letter, CTS Labs never intends to share these details in the open. The company hopes these flaws could never be weaponized into malware by attackers, something that usually happens after every vulnerability disclosure as malicious actors are always looking to stay one step ahead of security vendors.

All in all, Luk-Zilberman said he regrets not contacting more third-party validators before disclosing the vulnerabilities. Doing so would have made it less likely that their research would have been doubted like it was yesterday with RyzenFall, MasterKey, Fallout, and Chimera.

Related Articles:

AMD Flaws Pose No Immediate Risk of Exploitation, Says Independent Reviewer

AMD Investigating RyzenFall, MasterKey, Fallout, and Chimera CPU Vulnerabilities

AMD Confirms RyzenFall, MasterKey, Fallout, and Chimera Vulnerabilities

AMD Releases Spectre v2 Microcode Updates for CPUs Going Back to 2011

Here We Go Again: Intel Releases Updated Spectre Patches