Dubious Research Discovers Ryzen vulnerabilites

[jigger]

We already know you are trying very hard to legitimize CTS-Labs, its the only thing you've done in the last week, literally that is all that's occupied your time here so you posting one of their slides, again, doesn't suddenly make you or them right, do you seriously believe if you repeat their debunked and discredited slides enough it will stick?

They actually use the image from and Intel CPU's in that, have you noticed that? given that real computing security firms have said this is actually something found on Intel CPU's the truth is not what they say it is but what it actually illustrates, replace the AMD text with Intel and then its completely accurate.

I might do that later, the power of pictures...

Rroff is part of the Nvidia focus group. I wouldn't take what he says seriously Pal.

 

[Rroff]

We already know you are trying very hard to legitimize CTS-Labs, its the only thing you've done in the last week, literally that is all that's occupied your time here so you posting one of their slides, again, doesn't suddenly make you or them right, do you seriously believe if you repeat their debunked and discredited slides enough it will stick?

They actually use the image from and Intel CPU in that, have you noticed that? given that real computing security firms have said this is actually something found on Intel CPU's the truth is not what they say it is but what it actually illustrates, replace the AMD text with Intel and then its completely accurate.

I might do that later, the power of pictures...

So rather than admit you haven't actually read what they claim and came out with something that they've never even claimed... you come out with that rubbish.

CTS-Labs might be a bunch of muppets and possible one of their "employees" has acted in bad faith - though most of the appropriation and weaponising of the information seems to have come from a media company they've worked with - but that doesn't mean everything they've said is based on rubbish.

Rroff is part of the Nvidia focus group. I wouldn't take what he says seriously Pal.

This thread is a hoot. The amount of clown posts rather than debating the subject at hand reflects poorly on the pro-AMD crowd. At least humbug is trying to debate the facts even if his interpretation of them has been skewed by the echo chamber that some of the pro-AMD circles he obviously frequents has become - as he is largely just parroting what is going around there.

 

[humbug]

No they are just as you say a bunch of muppets, factually wrong with what is clearly third hand misunderstood knowledge of the subject.
Its like they read "CPU architecture for dummies"

Rroff is part of the Nvidia focus group. I wouldn't take what he says seriously Pal.

I know he is but that doesn't explain his mission here.

 

[jigger]

No they are just as you say a bunch of moppets, factually wrong with what is clearly third hand misunderstood knowledge of the subject.



I know he is but that doesn't explain his mission here.

To take as big a dump on AMD as possible. One of the reasons I suspect it's Nvidia that setup Craptastic Labs.

 

[Rroff]

factually wrong with what is clearly third hand misunderstood knowledge of the subject

No offence but clearly and including myself our knowledge here is 3rd hand but also you are accusing them of multiple instances of things that as I pointed out they absolutely do not claim on their web-site - again those are claims that have gone around in certain circles so I suspect you've read them there but its really easy to cross check - they have never ever claimed that EPYC server is vulnerable to the Chimera parts of the exploit as you claimed.

EDIT: I take that back slightly - though they didn't have Chimera on the diagram originally for EPYC server their original whitepaper alluded to the on-die USB 3.0(3.1 gen 1) chipset also being ASMedia which it actually isn't but they never actually made that claim in black and white so it might just have been misinterpretation of the wording.

 

[humbug]

hhmmm..
-----

Roff they have EPYC on that idiotic slide you posted.

 

[Rroff]

Roff they have EPYC on that idiotic slide you posted.

Yes - but you made a point of saying their claim was idiotic (which it might or might not be) on the premise that the EPYC platform doesn't have a chipset:

EPYC doesn't even have a Chip-Set, i'll say that again: EPYC has no Chip-Set.

Their diagram clearly shows that they aren't ascribing the chipset vulnerabilities (Chimera) as being applicable to EPYC Server only some of the other exploits.

I will allow that originally their documentation while not explicitly stating so alluded to the on-die controller possibly being ASMedia so the same problems as Chimera would exist there - which might be why some circles are still talking from that angle - but they removed all of that some time around the point when they published the clarification so either they then found out the on-die controller wasn't ASMedia or the original wording was simply confusing. From the start though their diagram didn't have Chimera on EPYC server and they never explicitly stated it was affected by the chipset vulnerability.

 

[Vince]

I stopped following this a few days ago... Any updates or are we still none the wiser?

 

[Rroff]

I stopped following this a few days ago... Any updates or are we still none the wiser?

Largely still none the wiser - AMD have published no further updates - everyone else is just repeating the first couple of technical articles that used Dan Guido's work and adding a few lines/interpretation of their own.

If it was entirely proof of concept with no possibility to actually put it into practise in any shape or form you'd have hoped AMD would have published a clarification by now.

 

[humbug]

Yes - but you made a point of saying their claim was idiotic (which it might or might not be) on the premise that the EPYC platform doesn't have a chipset:



Their diagram clearly shows that they aren't ascribing the chipset vulnerabilities (Chimera) as being applicable to EPYC Server only some of the other exploits.

I will allow that originally their documentation while not explicitly stating so alluded to the on-die controller possibly being ASMedia so the same problems as Chimera would exist there - which might be why some circles are still talking from that angle - but they removed all of that some time around the point when they published the clarification so either they then found out the on-die controller wasn't ASMedia or the original wording was simply confusing.

So they ain't completely stupid.

Because EPYC has no Chip-Set they draw a diagram of the same thing without the "AMD proprietary Chip-Set" that's actually ASmedia and call it Ryzenfall.

If yer don't need the Chip-Set why is the Chip-Set involved at all? EPYC and Ryzen are the same chips, the only difference is EPYC has 4 Ryzen CPU's, 4x 32 PCIe 3 lanes = 128, EPYC doesn't need a Chips Set because the combination of 4 Ryzen CPU's gives them more than enough ansilery connectivity.

 

[humbug]

I stopped following this a few days ago... Any updates or are we still none the wiser?

The firm who CTS-Labs hired to validate their work have publicly discredited them.

They made the whole thing up to devalue AMD's stock in order to profit from it.

Edit: Roff can't accept that and let it go.

 

[Vince]

@Rroff @humbug cheers gents - will check back in a few days.

 

[Rroff]

So they ain't completely stupid.

Because EPYC has no Chip-Set they draw a diagram of the same thing without the "AMD proprietary Chip-Set" that's actually ASmedia and call it Ryzenfall.

If yer don't need the Chip-Set why is the Chip-Set involved at all on Ryzen? EPYC and Ryzen are the same chips, the only difference is EPYC has 4 Ryzen CPU's, 4x 32 PCIe 3 lanes = 128, EPYC doesn't need a Chips Set because the combination of 4 Ryzen CPU's gives them more than enough ansilery connectivity.

You do realise that this isn't all one exploit or dependant on all parts to work? its 13 different vulnerabilities some of which are interlinked and some not - in theory some parts can be used without other parts and the whole lot can be used in combination for more advanced attacks on the platforms that are vulnerable to the full spread.

The firm who CTS-Labs hired to validate their work have publicly discredited them.

They made the whole thing up to devalue AMD's stock in order to profit from it.

Edit: Roff can't accept that and let it go.

The firm used to validate the results never discredited them in the context you are meaning it - he also verified that they didn't make the whole thing up - what he has done is put these vulnerabilities into their proper context - that of moderately concerning rather than the ground breaking issues that CTS Labs tried to portray them as and called into question their professionalism:

There is no immediate risk of exploitation of these vulnerabilities for most users.

Notice he says there is no immediate danger, that doesn't mean the problem isn't there, from these vulnerabilities and the caveat of most users - meaning there are some potential cases with a higher level of exposure.

These types of vulnerabilities should not surprise any security researchers; similar flaws have been found in other embedded systems that have attempted to implement security features. They are the result of simple programming flaws, unclear security boundaries, and insufficient security testing.

Much of the evidence for CTS Labs themselves intentionally smearing AMD is circumstantial at best - their actions from a technical perspective are far more consistent with them having found what they thought was a big exploit and in a hurry to make a name for themselves went off half-cocked before they'd completed proper testing - if it was just a smear either to see AMD take a hit or to gain financially they'd have little purpose to continue making clarifications and backfilling with additional testing that should have been done before any disclosure and wasn't. It is a case of be careful attributing to malice what can adequately be attributed to incompetence.

Someone has definitely tried to weaponise this information - their CFO has a background in similar stuff (but that is circumstantial although I'd be unsurprised to find a link there) and the media company they worked with initially certainly has acted in bad faith but that doesn't mean the whole thing is made up.

 

[Curlyriff]

@humbug @Rroff Can you guys slow down in your back and forth please. I keep running out of popcorn and having to pop to the shop. Most appreciated.

 

[Rroff]

@Rroff @humbug cheers gents - will check back in a few days.

I'm curious what you make of https://www.mozilla.org/en-US/security/advisories/mfsa2018-08/ though there isn't much information on what is actually possible with the out of bounds memory write. I'm guessing on the kind of systems you were talking about before most likely trying to do anything useful would trip the relevant security software watchdog into taking the nuclear option but it seems potentially quite serious if it manages to write to the right bit of memory.

 

[humbug]

Roff you need to read this.

"It appears that CTS Labs first found vulnerabilities in Asustek’s chipsets and validated them (likely on Intel (NASDAQ:INTC) x86 systems). Then, the Company went to look for those same errors and others in AMD x86-based systems. However, instead of pointing out that security problems existed in tens, if not hundreds, of millions of systems with Intel and AMD chips, CTS decided to target AMD."

That was this firms conclusion and one of many reason they discredited CTS-Labs, IMO you are just continuing on from where CTS-Labs have been debunked, because CTS-Labs are no longer given a platform.

I made this prediction.

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.

 

[Mercutio]

Maybe just leave rroff to punch himself out, there's clearly no reasoning.

 

[Rroff]

That was this firms conclusion and one of many reason they discredited CTS-Labs, IMO you are just continuing on from where CTS-Labs have been debunked, because CTS-Labs are no longer given a platform.

I made this prediction.

You are misunderstanding that quote - the mention of the Intel platform there doesn't have the significance you think it has - the Intel platform was used as a debugging test-bed doesn't mean the same vulnerabilities they found are possible to exploit on that system and the ASMedia problems have nothing to do with Spectre. Just because you can use a tool to look inside something like a controller doesn't mean the system itself is susceptible to the same problem. (This is hardware analysis 101 stuff).

While I'm far from an expert on these system (hah) far from it I do have some experience of working with these kind of controllers:

Spoiler

You are also missing that in the case of older AMD systems and Intel these controllers are hanging off the chipset as a separate component and its far harder to abuse any access path they have to the CPU while with Promontory AMD brought them inside the chipset giving a higher chance (supposedly) of exploiting the chipset and its access paths to the CPU.

Sure it isn't AMD specific but there are several AMD specific twists to this one that either have already been patched long ago on Intel or are much harder to exploit on other/older platforms - if it was the case and they wanted to smear AMD why not go after the whole line up? "Oh you are using a Piledriver FX? yeah that's vulnerable too" - they haven't - there are a lot of places still using previous generation AMD CPUs in servers, etc. if you really wanted to hurt them those lines would be prime target as well.

 

[Vince]

I'm curious what you make of https://www.mozilla.org/en-US/security/advisories/mfsa2018-08/ though there isn't much information on what is actually possible with the out of bounds memory write. I'm guessing on the kind of systems you were talking about before most likely trying to do anything useful would trip the relevant security software watchdog into taking the nuclear option but it seems potentially quite serious if it manages to write to the right bit of memory.

There is not a whole load of info there so more digging would be required. Be it luck, judgement or even lack of proper management tools, we do not allow Firefox on our network as a matter of firm wide policy.

I do agree though that flaws like this that allow for memory writes outside of normal operation are highly risky. My guess is that you are right and this would send our utm/ids features into nuclear mode and the firewall would most likely lock down the source machine. If I could get hold of some source code to test I could sandbox it and see what happens. With anything like this it opens up other attack vectors so potentially alongside something more sinister this could be catastrophic in the right hands.

 

[humbug]

You are misunderstanding that quote - the mention of the Intel platform there doesn't have the significance you think it has - the Intel platform was used as a debugging test-bed doesn't mean the same vulnerabilities they found are possible to exploit on that system and the ASMedia problems have nothing to do with Spectre. Just because you can use a tool to look inside something like a controller doesn't mean the system itself is susceptible to the same problem. (This is hardware analysis 101 stuff).

While I'm far from an expert on these system (hah) far from it I do have some experience of working with these kind of controllers:

Spoiler

You are also missing that in the case of older AMD systems and Intel these controllers are hanging off the chipset as a separate component and its far harder to abuse any access path they have to the CPU while with Promontory AMD brought them inside the chipset giving a higher chance (supposedly) of exploiting the chipset and its access paths to the CPU.

Sure it isn't AMD specific but there are several AMD specific twists to this one that either have already been patched long ago on Intel or are much harder to exploit on other/older platforms - if it was the case and they wanted to smear AMD why not go after the whole line up? "Oh you are using a Piledriver FX? yeah that's vulnerable too" - they haven't - there are a lot of places still using previous generation AMD CPUs in servers, etc. if you really wanted to hurt them those lines would be prime target as well.

Its very clear what the quote is.

It appears that CTS Labs first found vulnerabilities in Asustek’s chipsets and validated them (likely on Intel (NASDAQ:INTC) x86 systems) Then, the Company went to look for those same errors and others in AMD x86-based systems.

The Intel system was not "used as a debugging test-bed" its the platform the problem was originally found on and then tested for on AMD's system.

That is literally exactly what it says and then goes on to criticize them for not disclosing the same issue on the Intel system, how anyone can misconstrue that in any way is beyond me, Roff.

The quote in its entirety, again...

"It appears that CTS Labs first found vulnerabilities in Asustek’s chipsets and validated them (likely on Intel (NASDAQ:INTC) x86 systems). Then, the Company went to look for those same errors and others in AMD x86-based systems. However, instead of pointing out that security problems existed in tens, if not hundreds, of millions of systems with Intel and AMD chips, CTS decided to target AMD."