Trending Topic! An Israeli security firm -CTS- claimed to have discovered multiple vulnerabilities and exploitable manufacturer backdoors inside AMD’s latest EPYC and Ryzen lines of processors. These vulns could allow attackers to access sensitive data, install persistent malware, and gain full access to the compromised systems. CTS has created a dedicated website1 to publicize its findings.
It could be another ordinary security advisory, but it is not. There is an interesting point in this case: the lack of a coordinated release between the researchers and the vendor. The firm published a whitepaper (and upload a site) at almost the same time as it notified AMD, which means no time for the affected company to investigate, address the findings, and develop a fix. For that reason, CTS didn’t include a technical description or a proof of concept into the disclosed information (these details will be public once the fixes are available).
Responsible Disclosure
The company defends its posture through a letter written by its CTO. What does he say? He doesn’t believe in the current structure of “Responsible Disclosure“. For him, this model presents some flaws. During the embargo time (the time until the vulnerability is solved and disclosed), the customers don´t know about the issue and they could be at risk.
“And as far as I’ve seen, it is extremely rare that the vendor will come out ahead of time notifying the customers. (…) Almost always it’s post-factum”
Moreover, CTO asks himself, what happen if the vendor can’t resolve the problem on time or does not respond?
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?
Based on this analysis, they propose to notify public on day 0 and put all the pressure on the vendor.
Responsible Disclosure vs Coordinated Disclosure
I don’t like the term “responsible” when we talk about release security advisories. Why? Because this word could take several meanings across the different actors. What is responsible for me may not be responsible for you. Thus, the expression “coordinated” would be more appropriate.
In a coordinated release, the researcher and the vendor work together to obtain a solution to the vulnerability in order to protect the customers. Roughly speaking, a typical process starts with an initial notification from the researcher including a technical description and, in some cases, a proof of concept. The vendor verifies the bug, performs its tests, and designs a plan to address the vulnerability. Later, both the vendor and the researcher agree on a release date (with a time limit of 45/60/90/XXX days after the initial communication2. Finally, when the fix is available, the publication is released. It is encouraged that all parties regularly communicate with each during the process.
What is obtained by this model?3
- Vulnerabilities can be identified and eliminated effectively and efficiently by all parties.
- The risk to customers from vulnerabilities that could allow damage to their systems is minimized.
- Customers and security community are provided with sufficient information to evaluate the level of security in vendors’ products.
And, what about the CTS fears?
- The customer isn´t put at risk (There is usually a patch before the publication).
- If a threat appears in the wild before the fix, the researcher and the vendor could work in conjunction to design a workaround or a mitigation.
- If there are delays, time extensions can be negotiated (Not everyone looks for fame. Publication can wait).
Market Manipulation
So, what is the purpose to notify the public about a vulnerability in a product if you don’t propose a mitigation or give a faithful demonstration of the flaw or even some technical information? How do you protect the customer? How can they evaluate the product’s security?
The first thing that comes to my mind is “marketing“. CTS seeks to attract the attention but in the wrong way. As I explained in my last article, I support vulnerability branding. I think marketing certain vulnerabilities is good for building a better cybersecurity industry, but not like this. Why not work together with the vendor if you want to protect the customer?
This case is the perfect example of how not to disclose vulnerabilities.
Should we pay attention to Torvalds’ warning?
Security people need to understand that they look like clowns because of it. The whole security industry needs to just admit that they have a lot of shit going on, and they should use – and encourage – some critical thinking.
Footnotes
1. CTS/AMDflaws.com – Severe Security Advisory on AMD Processors
2. There is not an standard to define a consistent deadline. Some programs, like the Google’s Project Zero, have a 90-day disclosure deadline. Others like the Tipping Point’s Zero Day Initiative allows the vendor 120 days to address the vulnerability with a patch.
3. Based on the IETF draft – IETF Disclosure Process