#Bizwhiznetwork.com Innovation ΛＩ |Technology News
Earlier this week, bombshell news surfaced of 13 supposedly critical security flaws in AMD processors. While at least some of the flaws appear to be real based on independent confirmation from security researchers, the manner and nature of the disclosure lifted a number of eyebrows. A simultaneously released report from a firm trying to short AMD’s stock made the entire affair look particularly shady, especially since the firm in question, Viceroy Research, carried out a nearly identical attack on a German company just a week ago. In that case, Viceroy took a large short position on the German company ProSieben, then accused it of questionable accounting practices. Now, CTS Labs has published a letter from its own CTO, Ilia Luk Zilberman, offering an explanation for its own behavior.
The letter can be divided into two broad sections: Claims about how CTS Labs began and progressed through its investigation of the relevant security flaws, and Zilberman’s own views on the disclosure process.
In the first part of the letter, Zilberman claims that his firm began researching Asmedia devices — the ASM1042, ASM1142, ASM1143 chips, specifically — and that this served as a jumping off point for an overarching investigation into AMD’s overall security practices. On the surface, this makes sense. It’s the kind of inquiry that’s familiar to anyone who’s ever worked in QA or attempted to reproduce and characterize unexpected behavior. But scratch the surface and Zilberman’s framing starts to fall apart.
Cover Your Asmedia
It’s absolutely fair to characterize and test the flaws in AMD’s chipsets. But as CTS Labs’ white paper makes clear, the same Asmedia chips that make up AMD’s Promontory chipset for Ryzen CPUs have been shipping on motherboards, including hundreds of Intel motherboards models, for at least the past six years.
The Asmedia ASM1042 and ASM1142 were and are widely used on Intel motherboards, but CTS Labs neglects to mention that fact in its white paper or letter.
Zilberman tacitly acknowledges this when he writes:
[W]e have started researching ASMedia chips about a year ago. After researching for some time, we have found manufacturer backdoors inside the chip which give you full control over the chips (ASM1042, ASM1142, ASM1143). We wanted to go public with the findings, but then saw that AMD have outsourced their chipset to ASMedia. So we decided to check the state of AMD, we bought a Ryzen computer, and whimsically ran our exploit PoC, and it just worked out of the box.
By its own statements, CTS Labs tested and developed a proof of concept exploit for Asmedia controllers before it was aware these controllers were incorporated into Ryzen chipsets. Where, then, is the website AsmediaFlaws.com? Where’s the notification to tell Intel motherboard customers that the chips on their motherboards can be similarly backdoored and abused? This isn’t a theoretical; I’m writing this article from an Ivy Bridge-E system powered by an Asus X79-Deluxe motherboard with an Asmedia 1042 controller. In its white paper, CTS Labs describes the offending Asmedia controllers as follows:
In our assessment, these controllers, which are commonly found on motherboards made by Taiwanese OEMs, have sub-standard security and no mitigations against exploitation. They are plagued with security vulnerabilities in both firmware and hardware, allowing attackers to run arbitrary code inside the chip, or to reflash the chip with persistent malware.
If CTS Labs has accurately characterized these flaws, the problems in Asmedia controllers affect millions of Intel motherboards worldwide going back six years. In the early days of USB 3.0, before Intel added its own native chipset support, Asmedia was one of the most common third-party providers. Chips like the ASM1142 are still used on Intel motherboards today. When we looked at Newegg, nearly every USB 3.0 PCI Express card we spot-checked used an Asmedia solution — typically the ASM1042 or ASM1142.
If these Asmedia flaws are common to Intel, AMD, and standalone cards, Intel users and expansion card users absolutely should’ve been notified. If they’re unique to AMD users, CTS Labs needed to explain why. It has not. Again, when security researchers describe flaws, they typically describe them across the entire set of hardware on which they are known to occur. Failing that, they at least acknowledge the use of these broken solutions in other contexts. CTS Labs did neither.
Disclosure Policies
Zilberman’s defends giving AMD barely a day to respond to the issues CTS Labs found by arguing it’s better to disclose the broad strokes of the vulnerability immediately and with no warning because the publicity forces the vendor to deal with the problem immediately. This has been a point of general contention in the security industry for years. While working with vendors for a given period of time is the industry norm, the idea that security researchers should publish immediately and damn the consequences is not unique to CTS Labs. There’s also a balance to strike between disclosing more technical details of an attack when vendor solutions are either in-place or will arrive imminently (under the cooperation model), versus describing an issue only in the vaguest terms when you drop it on the market without warning (which is what CTS Labs did).
Where Zilberman errs is when he blames the entirety of the response to CTS Labs’ disclosures on the company’s decision not to provide technical proof of its findings. He writes that his company has been “paying that price of disbelief in the past 24h.”
Except that’s not what actually happened. Few reputable publications have questioned the existence of the flaws themselves, particularly when Dan Guido of TrailofBits declared that he’d validated and confirmed that all 13 exist.
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
While we’re still waiting for AMD or another third party to release more details, it’s clear there’s a real problem here. But the question raised by CTS Labs behavior isn’t whether there are flaws in AMD’s chipsets or Ryzen CPUs. It’s a question of whether those flaws were fairly or accurately characterized given the company’s scaremongering, and a further question of whether the disclosure was targeted and timed as part of a scheme to harm AMD’s stock price, as opposed to a straightforward, good-faith security disclosure.
On these issues, Zilberman is silent.
There’s nothing illegal about paying a security firm to research a product or the manner in which CTS Labs disclosed its findings. But just because something isn’t illegal doesn’t make it a good idea — and we can think of few ideas worse than short sellers and security firms teaming up to weaponize disclosures. Zilberman’s letter may have been intended to clear the air, but it only raises more questions about the nature of the company’s findings and its framing of its work.
