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.
Regardless of the hype around the release, the bugs are real, accurately described in their technical report (which is not public afaik), and their exploit code works.
— Dan Guido (@dguido) March 13, 2018
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."
On the #AMDflaws — I have seen the technical details and there are legit design & implementation issues worth discussing as part of a coordinated disclosure effort. The media storm and handling around that is sadly distracting from a real conversation around security boundaries.
— Alex Ionescu (@aionescu) March 14, 2018
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.
3) FALLOUT: vendor-supplied *signed* driver allows access to Secure Processor.
— Arrigo Triulzi (@cynicalsecurity) March 13, 2018
Threat level: No shit, Sherlock!
4) CHIMERA¹: outsourced chipset has an internal ucontroller which can be 0wned via digitally signed driver.
__
¹ read about my Chimaera Processor: far sexier stuff.
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 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.
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.
Comments
beggerking - 6 years ago
I don't believe the stupid open letter, its just 100% factual. That Don Guildo guy was paid by the company...
and cynicalSecurity is basically saying "no shit shirlock, ANYTHING with these access requirements means you are screwed, REGARDLESS of which chip"
_LC_ - 6 years ago
Who are these guys that they get this much coverage with their smear campaign? Do they hand out banknotes? Do they drag along free hookers?
I don't get it. :-P
the_moss_666 - 6 years ago
If CTS has actual PoC or evidence, they should go public. To use these vulnerabilities, you already need full control over the system. The whitepaper is amateurish compared to meltdown dislosure, evidence is missing, their "public sources" are either concept definitions or far-fetched accusations (like" ASMedia is a subsidiary of ASUSTeK Computer, which had a problem with some insecure routers in the past, therefor there "is" a backdoor in AMD CPUs). CTS Labs is not even standing behind its own finding! Disclaimer (or rather "Important Legal Disclaimer") says it doesn't provide any recommendations or professional advice and does not contain any statement of fact. (just honest opinion with no guarantee of being true).
I think at least some of these vulnerabilities do exist, but they are not AMD flaws (BIOS manufacturers, OS manufacturers, driver providers and maybe AMD contractors are to blame). These are generic, "what-if level" vulnerabilities.
Bill_R - 6 years ago
I don't buy the rationale in the open letter. The alternative they paint from responsible disclosure is chaos. The point of disclosures is to alert companies so they can protect users from criminal hackers. Giving no time to work on a fix or mitigation is a lot like providing free zero-day exploits. If the problem is silicon-based, remember that fab times for 14nm is ~3 months for hot-lots and production lots can take ~5-6 months... that's once the fix is available and verified (so basically you're screwed if the problem is in non-patchable logic).
Silicon companies are making parts with billions of gates, errors will occur. The question is how to respond. If Si companies ignore researchers then it's on them. If researchers disclose irresponsibly then I would assume lawyers for customers that are damaged may think that the researchers have a share in the liability too, and I'd hate for that to happen.
MadmanRB - 6 years ago
Its still rather scummy, even if these vulnerabilities exist only having one day to address them is stupid.
If these vulnerabilities exist it will take some time and research them to properly patch them.