See more
See less

Researchers Who Found AMD CPU Flaws Explain Chaotic Disclosure


  • Researchers Who Found AMD CPU Flaws Explain Chaotic Disclosure

    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.

    Dan Guido@dguido

    So this business... CTS Labs asked us to review their research last week, and sent us a full technical report with PoC exploit code for each set of bugs.

    Dan Guido@dguido

    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.

    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."

    Alex Ionescu@aionescu

    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.
    8:05 AM - Mar 15, 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.

    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.

    It's very hard to argue against Luk-Zilberman's proposal, which makes sense, at least on paper, 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.

    source: bleepingcomputers

      Posting comments is disabled.



    Article Tags


    Latest Articles


    • Beelink S2: A Ideal Mini PC For Work, Gaming and Entertainment With Intel Gemini Lake

      Under the Beelink brand, here is an optimum Mini PC which will be used for casual office, games, and home entertainment and it is equipped with the Windows 10 OS and it has the relevant system activation code. This Ideal Mini PC name is S2 and it is the next generation of S1.

      The Beelink S2 is an evolution of a model that we’ve been seeing for a while, the S1 model that runs under Celeron N3450, but which switches to a Celeron Gemini Lake N4100 that will provide more performance.
      04-23-2018, 21:01
    • WIN WIN WIN 7 years of Freaktab, thank you all WIN WIN WIN

      Thanks to our Users, Sponsors, Devs and Mods:

      Click to win:

      What prizes do we have exactly in the Giveaway in order to win?

      1. OUKITEL WP5000

      2. PROBOX2 AVA

      3. ZIDOO H6 PRO

      4. UGOOS AM3

      5. UGOOS AM3

      6. UGOOS AM3

      7. RKM MK22
      04-15-2018, 13:45
    • New Android TV dongle passes through the FCC with Google Logo, Assistant enabled remote and Oreo on board

      If you’re a keen watcher of the US Federal Communications Commission (FCC), then a new device from Shenzhen SEI Robotics Co., Ltd. labelled a ‘4K ATV Stick’ will probably have piqued your interest, with the external photos showing off a HDMI dongle, with Google Logo running the latest version of Android TV and with a Google Assistant enabled voice remote.

      As you can see from the images the dongle is extremely reminiscent of the Chromecast dongles that have been massively popular
      04-10-2018, 15:16
    • Google removes ‘Kodi’ from search autocomplete in anti-piracy effort
      Google has banned the term “Kodi” from its autocomplete feature, meaning those who look for information on the set-top box will have to type out the full term in order to search, as reported by TorrentFreak. Google has been increasing its anti-piracy efforts in recent years, banning terms from autocomplete and making changes to its search algorithms in order to demote copyright-infringing material.

      While Kodi is legal software in a set-top box for streaming, it supports a myriad of
      03-29-2018, 14:06
    • Google starts blocking its apps on uncertified Android devices
      If you're fond of loading custom ROMs on your Android phone, life just became complicated. Google has quietly started blocking access to its apps on uncertified devices whose firmware was built after March 16th. If you're affected, you'll get a warning that a device is "not certified" and can't sign into a Google account. This won't prevent you from loading ROMs, but you'll have to register your device IDs on a white list every time you undergo a factory reset -- when there's a 100-ID...
      03-26-2018, 14:42
    • AMD Responds To CPU Security Flaw Report
      AMD has finally issued a full response to CTS Labs’ report that Ryzen and EPYC processors contain a total of 13 security flaws. Here’s the short version of the chipmakers’ response:
      • Exploitation of the vulnerabilities requires admin access
      • The vulnerabilities have to do with firmware and chipsets, not the x86 architecture
      • Patches are coming in the form of BIOS updates and firmware patches only--no microcode updates are required--via OEMs and ODMs
      • All issues will be addressed within “weeks,”
      03-20-2018, 13:37