Dubious Research Discovers Ryzen vulnerabilites

[CAT-THE-FIFTH]

The Anandtech article is pretty interesting. It's nice that one of the tech sites is actually doing their job, and doing it damn well.

This story has highlighted just how trash some of the few sites I still read are.

It was not only Ian Cutress but David Kanter,so they came prepared!

 

[gavinh87]

Well thanks I guess for the confirmation.

You see I'm not the person you originally tried to bait into a Vega argument, I am a different person accusing you of trying to derail a thread about a security firm and a share shorting firm apparently trying to leverage information they have about chip flaws.

...and off you go with the private agenda exactly as I accused you.

Glad I didn't disappoint you.
I couldn't care less about CTS in all honesty. Nor about AMD shares.
But the amount of drivel in this thread has made me chuckle a few times. I thought it is only fair that I give back.

 

[humbug]

Ok,I found this video on AT forums which was with Ian Cutress from AT talking with CTS-Labs:

https://www.youtube.com/watch?v=cj3_AILPvU0

A poster on AT forums who watched it said the following:

Ok i'm 10 minutes in and already i'm thinking this child has mental issues laughing at everything like some demented.....

Continuing to watch.... hope he stops laughing like that

 

[Hotwired]

Just read the transscript of the call they made to CTS: https://www.anandtech.com/show/12536/our-interesting-call-with-cts-labs

 

[humbug]

Just read the transscript of the call they made to CTS: https://www.anandtech.com/show/12536/our-interesting-call-with-cts-labs

Yeah you're probably right... thx

 

[humbug]

If you continue to word it that way you will confuse newbies as there are no Intel ASMedia chipsets. There are premium Intel boards which use an ASMedia controller in addition to the Intel chipset but they are not integral so disabling it is relatively pain free.


Knowing Intel's record over the last 12 months or so very little would surprise me in terms of their vulnerabilities.
But surely at the level of secure enclaves which presumably are not bound by x86 compatibility you would need a unique attack for each platform?
Or have security experts being stating categorically that Intel are definitely vulnerable and not theoretically but that proof of concept has been shown?
It's possible that Intel are less or more secure than AMD at this level but it seems too early to say at this stage.

I'll look at the transcript tomorrow, right now i want to respond to this.

There is no ASmedia tech or IP in AMD's or Intel's CPU's, they are separate components adding extra features like USB ports, yes both AMD and Intel use them, hell they are probably the same bloody chips, they can and perhaps do provide an access path to the CPU's secure controller, this is necessary for firmware updates.

How that chip works and the fact that Intel and AMD use the same chips is actually irrelevant, what matters is the fact that the secure controller for any CPU, including Intel can have its instructions to the CPU altered, be it through some ASmedia Chipset or any other means the fact remains, it is for example how AMD have been optimizing, fixing ecte.. Ryzen CPU's, they have been sending out microcode updates which alter the way the secure controller controls the CPU, Intel have and do this too.

That is a vulnerability, a vulnerability CTS-Labs claim credit for finding, its conflated none sense and here is why, which will answer the crocks of your question.

Not only would such an attack have to be different for Intel than it is for AMD, it would also have to be different from one Ryzen or Intel system to another, because 'and this is really important' it requires the motherboards BIOS to be flashed, so you have to have a compatible BIOS for the target PC, so yes if you can get hold of a genuine signed BIOS for my specific motherboard, and i'm stupid enough to grant you elevated access to my computer then yes you can hack into my computer and take control of it, but assuming you have an Intel system i can do exactly the same to you.

So this is not an AMD specific vulnerability, nor is it anything new, this sort of hacking has been in existence for a couple of decades, they are called rout kits, its why we have different levels of user access to our systems, you have to physically grant these accesses to software, like the User Account Control.

Again CTS-Labs it is very clear, no one professional is disputing this, in fact they are the one saying this; are out to hurt AMD, stop giving them an audience let alone any sort of legitimacy.

 

[CAT-THE-FIFTH]

If you read the transcript its not only Ian Cutress but David Kanter too,and the latter is Principal Analyst and Editor-in-Chief at Real World Tech,so AT made sure they were prepared for the interview.

Commentary and Clarification
All processors and chips have flaws – some are critical, others are simple, some can be fixed through hardware and software. There are security issues and errata in some processors that are several years old.

CTS-Labs’ reasoning for believing that AMD cannot patch within a reasonable period, coming from ‘industry experts’, seems off – almost as if they believe that when they enter a responsible disclosure time-frame, they cannot reveal the vulnerabilities until they are fixed. The response to the question about Meltdown and Spectre, if they would have the same attitude to the fact that the industry had several months before publication for a coordinated effort, means that despite offering a unilateral reasoning for 0-day disclosure, they would not apply it unilaterally but on a case-by-case basis. The language used is clearly not indicative of their actual feeling and policy.

Blaming the lack of CVE numbers on them being ‘new’ to it, yet citing repeatedly many years of security experience and in cyber-security is also in opposition. It may be their first public disclosure, even as individuals, but I find it hard to believe they were not prepared on the CVE front. Using our own experts, it can take hours for a well-known company to be issued a CVE number, or weeks for an unknown entity. Had CTS-Labs approached a big security firm, or AMD, then these could have been issued relatively easily. CTS-Labs stated that they are waiting for CVE numbers to be issued to going to be an interesting outcome, especially if they appear and/or the time of submission is provided.

It seems a bit odd for a company looking into ASMedia related flaws to then turn their focus onto AMD’s secure processor, using the chipset vulnerabilities as a pivot point. ASMedia chips, especially the USB host controllers cited by CTS-Labs, are used on literally tens of millions of Intel-based motherboards around the world, from all the major OEMs. For a large period of time, it was hard to find a system without one. The decision to pivot on newer AMD platforms is a weak argument, the wishy-washy language when discussing projects at the start of the company’s existence, and the abrupt ending to the call when asked to discuss the original customer could be construed (this is conjecture here) that the funding for the product was purposefully directional towards AMD.

The discussion about the understanding of how vulnerabilities can be mitigated certainly piqued David’s interest. The number of things that can be done through microcode, or that are undocumented to third-party chip analysts, means that it came across as highly strange that CTS-Labs were fervent in their believe that AMD could not patch the issue in reasonable time to warrant a longer reasonable disclosure period (one of many arguments used). As seen in recent vulnerabilities and responsible disclosures, chip designers have implemented a number of significant methods to enable/disable/adjust features that were not known to be able to be adjusted, such as resetting a branch predictor. All it takes is for the chip company to say ‘we can do this’ and for it to be implanted, so the use of high-impact language was certainly noted. The confusion between microcode and FPGA in the discussion also raised an eyebrow or three.

When approaching the subject of virtualized environments, the short sharp acceptance that these vulnerabilities were less of an issue in VMs and with cloud providers was quickly overshadowed by the doom and gloom message for if a system was already compromised, even when it was stated that analyst expect 10% market share for EPYC by 2020. It was clear that the definitions of enterprise deployments seemed to differ between AnandTech and CTS-Labs, again partnered with amounts of doom and gloom.

Lastly, the legal argument of not being able to share the details outside of Israel, or only to registered security companies outside of Israel, was an interesting one we were not expecting. This being coupled with the lack of knowledge on the effect of an open disclosure led us to reach out to our legal contacts that are familiar with the situation. This led to the line:

“It’s BS, no restrictions.”

Some of our contacts, and readers with security backgrounds, have privately confirmed that most of this is quite fishy. The combination of the methodology and presentation with a new company that both claims to have experience but can’t do CVE numbers is waving red flags.

Opinion
Going back to the two original questions, here is where I personally stand on the issue:

One What are the vulnerabilities, how bad are they, and what can be done?
One, if the vulnerabilities exist: It is very likely that these vulnerabilities are real. A secondary attack vector that could install monitoring software might be part of a multi-layer attack, but offering a place for indiscriminant monitoring of compromised systems can be seen as an important hole to fix. At this point, the nearest trusted source we have that these vulnerabilities are real is from Alex Ionescu, a Windows Internals Expert who works for CrowdStrike, one of the companies that CTS-Labs says has the full disclosure documents. That is still a stage a bit far from us to warrant a full confirmation. Given that Trail of Bits required 4-5 days to examine CTS-Labs work, I suspect it will take AMD a similar amount of time to do so. If that is the case, AMD might have additional statements either on Friday or Monday, either confirming or rebutting the issues, and discussing future action.

Two Who are CTS-Labs, how come their approach to reasonable responsible disclosure differs to other security firms, how come a number of elements about the disclosure are atypical of a security firm, what is thier financial model, and who are their clients?
Two, the status of CTS-Labs: I’m more than willing to entertain the fact that as a first public high-level disclosure, a security company can be out of step with a few of the usual expected methods of responsible disclosure and presentation. A number of new security companies that want to make a name for themselves have to be bold and brash to get new customers, however we have never quite seen it to this extent – normally the work speaks for itself, of the security company will develop a relationship with the company with the vulnerability and earn its kudos that way. The fact that CTS-Labs went with a polished website (with nine links to download the whitepaper, compared to the Meltdown/Spectre websites that had one), and a PR firm is definitely a different take. The unilateral reasoning for a 0-day/1-day disclosure, followed by a self-rebuttal when presented with a more significant issue, shows elements of inconsistency in their immediate judgement. The lack of CVEs ready to go, despite the employees having many years of experience, as well as experience in the Israeli equivalent of the NSA in Unit 8200, does seem as opposites; an experienced security team would be ready. The swift acceptance that cloud-based systems are vulnerable but then going straight into doom and gloom, despite the limited attack surface in that market, shows that they are focusing on the doom and gloom. The reluctance for CTS-Labs to talk about clients and funding, or previous projects, was perhaps to be expected.

The initial downside of this story coming into the news was the foreboding question of ‘is this how we are going to do security now?’. Despite the actions of CTS and their decision to go with a 24-hour period, after speaking to long-term industry experts at high profile technology companies, a standard 90-180 day pre-disclosure period is still the primary standard that manufacturers would expect security companies to adhere with to actively engage with responsible information and verification. We were told that to go beyond/behind this structure ultimately formulates a level of distrust between the company, the security agency, and potentially the clients, regardless of the capabilities of the security researchers or the severity of the issues found; moreso if the issues are blown out of proportion in relation to their nature and attack surface.

 

[humbug]

I'll read it all tomorrow CAT thanks, its getting a bit late.

 

[Rroff]

Just read the transscript of the call they made to CTS: https://www.anandtech.com/show/12536/our-interesting-call-with-cts-labs

They seem pretty cagey whenever the questioning leans towards did someone put them up to it and never deny it then cut off abruptly when pushed on that point heh (or maybe they were just late for lunch).

Not sure I'd put much stock in them struggling at time with things like the nature of enterprise systems as some people have noted elsewhere - even a lot of people who should know better get confused between Corporate/Business, Enterprise and Data Centre systems - I've done it myself and seen a few here who apparently work with such sometimes stumble over it or aspects of it and some of it they were talking at slightly cross purposes to the questioners who thought they were asking one thing but actually asking another in the specific context i.e. the response in respect to lateral elevation through a network.

 

[sideways14a]

What an amateur bunch of retards this lot are.

 

[Silent_Scone]

Just read the Anand piece, they <Anand> rumbled them hard.

 

[DragonQ]

Just read the Anand piece, they <Anand> rumbled them hard.

DK: I think the biggest question that I still have is that ultimately who originated this request for analysis – who was the customer that kicked this all off?

ILO: I definitely am not going to comment on our customers.

DK: What about the flavor of customer: is it a semiconductor company, is it someone in the industry, or is it someone outside the industry? I don’t expect you to disclose the name but the genre seems quite reasonable.

ILO: Guys I’m sorry we’re really going to need to jump off this call but feel free to follow up with any more questions.

Hahaha.

 

[Silent_Scone]

Yeah that's a good way to sign off lol. Although that could be legitimate non-disclosure.

...Everyone knows Intel has a part in this lol.

There are just too many glaring mistakes in that piece to take it seriously and there are a lot of buzz words present that focus on the negative. The vulnerabilities themselves are likely the only legitimate part of all this (on some levels).

 

[humbug]

Why jump off when asked if any semiconductor requests for this, that's suspect.

 

[sideways14a]

Just the end was suspect lol... did you not think the rest of the call was rather dubious to say the least...

Help ma bob... quite what a collection of idiots this lot are, its comically amusing.

 

[N19h7m4r3]

What we found are these backdoors that we have been describing that come built into the chips – there are two sets of backdoors, hardware backdoors and software backdoors, and we implemented clients for those backdoors. The client works on AMD Ryzen machines but it also works on any machine that has these ASMedia chipsets and so quite a few motherboards and other PCs are affected by these vulnerabilities as well. If you search online for motherboard drivers, such as the ASUS website, and download ASMedia drivers for your motherboard, then those motherboards are likely vulnerable to the same issues as you would find on the AMD chipset. We have verified this on at least six vendor motherboards, mostly the Taiwanese manufacturers. So yeah, those products are affected.

https://www.anandtech.com/show/12536/our-interesting-call-with-cts-labs

So why did they specifically target AMD in the report? They state they were originally investigating ASMedia yet their report does not reflect that, should they not report on the flaws found in the ASMedia chipsets then correlate that through to the AMD chipsets and show that in their findings. Their effected products list for Chimera don't mention any ASMedia chipsets at all but they are effected and they even said this during the call.

It seems a bit odd for a company looking into ASMedia related flaws to then turn their focus onto AMD’s secure processor, using the chipset vulnerabilities as a pivot point. ASMedia chips, especially the USB host controllers cited by CTS-Labs, are used on literally tens of millions of Intel-based motherboards around the world, from all the major OEMs. For a large period of time, it was hard to find a system without one. The decision to pivot on newer AMD platforms is a weak argument, the wishy-washy language when discussing projects at the start of the company’s existence, and the abrupt ending to the call when asked to discuss the original customer could be construed (this is conjecture here) that the funding for the product was purposefully directional towards AMD.

So I'm not the only person who noticed that oddity....

The confusion between microcode and FPGA in the discussion also raised an eyebrow or three.

Not kidding, CPUs are not FPGAs but you can update microcode on those so why couldn't you on the chipset.

YLZ: We would love to, but there is one quirk. According to Israel export laws, we cannot share the vulnerabilities with people outside of Israel, unless they are a company that provides mitigations to such vulnerabilities. That is why we chose the list. But look, we are interested in the validation of this – we want people to come out and give their opinion, but we are only limited to that circle of the vendors and the security companies, so that is the limitation there.

Lastly, the legal argument of not being able to share the details outside of Israel, or only to registered security companies outside of Israel, was an interesting one we were not expecting. This being coupled with the lack of knowledge on the effect of an open disclosure led us to reach out to our legal contacts that are familiar with the situation. This led to the line:

“It’s BS, no restrictions.”

Some of our contacts, and readers with security backgrounds, have privately confirmed that most of this is quite fishy. The combination of the methodology and presentation with a new company that both claims to have experience but can’t do CVE numbers is waving red flags.

CTS needs to get better lawyers to properly advise them on what they can actually do, or not do.

 

[Rroff]

Just the end was suspect lol... did you not think the rest of the call was rather dubious to say the least...

Help ma bob... quite what a collection of idiots this lot are, its comically amusing.

IC: It was stated that, and I quote, that ‘this is probably as bad as it gets in the world of security’. These vulnerabilities are secondary attack vectors and require admin level access and they also do not work in virtualized environments (because you can’t update a BIOS or chip firmware from a virtual machine) without having metal access which is typically impossible in a VM environment. What makes these worse than primary level exploits that give admin access?

ILO: I think that this is an important question. I will give you my opinion. I think that the idea that this requires local admin privileges that it doesn’t matter in a sense because the vector already has the access to the files. What I think that is particularly bad about this secondary attack is that it lets put malware in hardware, such as the secure processor, which has the highest privileges in the system. You are sitting there and you can get to all memory sectors and so from there you can stay undetected by antiviruses, and if the user reinstalls the operating system or formats the hard-drive you still stay there.

So if you think about attaching that to the routine attack, a primary attack, this thing can let an attacker stay there and conduct espionage and sit there indefinitely. Now put yourself in the shoes of a person who discovers that an attack was using this tool and they need to decide what to do now, so they are basically guessing which machine to throw out. That’s one I think kind of degree of severity.

The other is the lateral movement issue as you probably read in our whitepaper: the idea that you can break the virtualization of where the credentials are stored, where the Windows Credentials are in Windows 10. From this an attacker can move laterally in the network – I think it that it is obvious that one of the major barriers to lateral movement is breaking the distinction between software and hardware. If you think about this not as a private user but as an organization that is facing an attack, this is very scary stuff to think that hackers can have the tools of this kind. This is why I think the language is not hyperbole.

IC: Most enterprise level networks are built upon systems that rely on virtual machines (VMs), or use thin clients to access VMs. In this circumstance no OS has bare metal access due to the hypervisor unless the system is already compromised…

ILO: Can I stop you there? That is not correct. That is entirely incorrect. We are talking about companies. You know we have a company here – imagine you had a company with four floors with workstations for employees that run Windows and sometimes you have a domain environment on the network….

IC: Those are desktop systems, I specified enterprise.

ILO: Yeah, this is enterprise, this is a company. As I said it has four floors with computers inside. They may be running Ryzen Pro workstations. They may have a Microsoft Windows Domain server, maybe a file server, and what we are talking about here is lateral movement inside corporate networks like this one. This is ABC, this is what happens on TSX all over the world with reports about how Chinese hackers behave when they hack US companies and this is how it looks like.

I think that is the most interesting section of the transcripts - the rest is mostly pretty bland other than the parts where Anandtech try to get something out of them as to whether anyone else put them upto it:

IC: Can you confirm that money changes hands with Trail of Bits?

(This was publicly confirmed by Dan Guido earlier, stating that they were expecting to look at one test out of curiosity, but 13 came through so they invoiced CTS for the work. Reuters reports that a $16000 payment was made as ToB’s verification fee for third-party vulnerability checking)

YLZ: I would rather not make any comments about money transactions and things of that nature. You are free to ask Trail of Bits.

IC: You said that you do not provide flaws to companies that are not the manufacturer of what you are testing. Does that mean that your initial ASMedia research was done with ASMedia as a customer?

ILO: No. So we can audit a product that the manufacturer of the product orders from us, or that somebody else such as a consumer or a third interested party audits from us and then we will provide the part of the description about the vulnerabilities much like our whitepaper but without the technical details to actually implement the exploit.

Actually ASMedia was a test project, as we’re engaged in many projects, and we were looking into their equipment and that’s how it started.

...
YLZ: As much as it is a pleasure talking to you we have time for only a few more questions
...

IC: Did you pre-brief the press before you spoke to AMD?

ILO: What do you mean by pre-brief the press?

IC: We noticed that when the information went live, some press were ready to go with relevant stories and must have had the information in advance.

ILO: Before our announcement you mean?

IC: Correct.

ILO: I would have to check the timing on that and get back to you, I do not know off the top of my head.

DK: I think the biggest question that I still have is that ultimately who originated this request for analysis – who was the customer that kicked this all off?

ILO: I definitely am not going to comment on our customers.

DK: What about the flavor of customer: is it a semiconductor company, is it someone in the industry, or is it someone outside the industry? I don’t expect you to disclose the name but the genre seems quite reasonable.

ILO: Guys I’m sorry we’re really going to need to jump off this call but feel free to follow up with any more questions.

 

[Rroff]

So why did they specifically target AMD in the report? They state they were originally investigating ASMedia yet their report does not reflect that, should they not report on the flaws found in the ASMedia chipsets then correlate that through to the AMD chipsets and show that in their findings. Their effected products list for Chimera don't mention any ASMedia chipsets at all but they are effected and they even said this during the call.

From the transcripts they claim ASMedia was originally a test case for the company which then lead them on to making other discoveries which lead them to AMD when looking at the findings - whether that is the real path of events or someone put them up to it is another matter.

"Actually ASMedia was a test project, as we’re engaged in many projects, and we were looking into their equipment and that’s how it started."

"So I'm not the only person who noticed that oddity...."

One of the differences to Intel (some 3rd party implementations aside) here is that currently AMD have an exposure to being able to circumvent signed code checks when uploading a firmware - this is a bit of a different deal to other companies as AMD have used these controllers as the standard implementation for their south bridge chipset (meaning more potential for getting deeper into the system and closer integration making further exploits potentially easier once you are in) and in the main on the Intel side you need to physically be at the system and plug a cable in to gain access to the secure part of the firmware which supposedly on the AMD side you don't - just need to be able to execute code on the system with admin privileges.

The stuff about the FPGA is a bit of an oddity - I can kind of see what they are getting at but it doesn't make sense that someone with enough knowledge to find these kind of flaws within such a system would struggle with that explanation - though it could be just not that person's relevant area of expertise and someone else at the company actually worked on that.

There is also the following bit:

"I think that it is up to them to announce what kind of workaround is available and how costly it will be in terms of disabling features and in terms of performance or whatnot. I think that as you have a hardware level flaw then it is a serious issue."

Albeit the person who made that statement has more of a background in finance apparently than in tech but still - you'd have a pretty good idea with this level of analysis whether the impact on fixing it would have implications for performance or not, etc. without the doubt and hand waving over the potential for fixes.

 

[Glanza]

Posting this in the Zen thread but the whole thing seems to be trying to manipulate stock.

 

[SiDeards73]

Wonder if its possible to actually bring a criminal case against these morons for deliberate collusion with other organisations with the sole attempt to lower shares prices for personal gain?

If i was these guys id be looking over my shoulder for a long while, if they have indeed been paid by another company with a vested interest in keeping AMD down, that company would no doubt not hesitate to throw this bunch of imbeciles to the wolves if it meant they did not get any grief from the fall out.

That Anand interview was mindblowing, the level of incompetence these idiots showed about Corporate networks etc was unbelievable.