• Competitor rules

    Please remember that any mention of competitors, hinting at competitors or offering to provide details of competitors will result in an account suspension. The full rules can be found under the 'Terms and Rules' link in the bottom right corner of your screen. Just don't mention competitors in any way, shape or form and you'll be OK.

Dubious Research Discovers Ryzen vulnerabilites

The firm hired did not conclude it was discovered on an Intel system - that was an assumption by the author of an article covering the deeper dive into it by Dan. It is a huge misunderstanding on your part anyhow that the discovery of a vulnerability on one system means that system is susceptible to it in any way - you can analyse and find a problem with an engine in one car that isn't' affected by it for instance but the way the engine is used in another car does fall foul of the problem.

Just because you might be able to load up a controller in debug mode on an Intel system for instance and peek/poke its operation in flight to see what happens and in doing so identify ways that it might be flawed mean that the system itself in that particular instance is vulnerable to that flaw being used against it.


Who else uses ASMedia Chip-Sets?

Like AMD Intel are right now patching their own BIOS, only Intel are doing it quietly.
 
Like AMD Intel are right now patching their own BIOS, only Intel are doing it quietly.
That's good to hear but strange they would be quiet about a flaw related to a 3rd party optional chipset whilst communicating a lot about their own hardware flaws!
Anybody have any hard data on the Intel side of things and not interested in speculation?
Might be buying a board this week and whilst I don't see this as a major issue I'd still like to know what the current situation is.
I suppose I could disable the ASMedia chipset in the EUFI but not sure that would fully remove the issue!
 
Who else uses ASMedia Chip-Sets?

I say again even if it was Intel (and it could have been an older AMD based system or they didn't want to destroy a production system for potentially destructive live testing) just because a vulnerability was able to be detected on one system doesn't mean that it is possible to exploit it on that system.
 
I suppose I could disable the ASMedia chipset in the EUFI but not sure that would fully remove the issue!

Despite what Humbug says on anything other than Zen, that includes older AMD systems and any other system, there is no known way to make use of these vulnerabilities within the controllers themselves due to the different way they are used - on Intel for instance they are hanging off the chipset and the chipset handles the main system on their behalf making it much harder to use them to exploit the main system even if you do manage to compromise the controller.

For most home users there is nothing to worry about at this stage whether AMD or Intel as you can be more effectively penetrated and exploited by other means - the kind of targets for these kind of vulnerabilities will largely be military, big organisations, etc. that have something worth going to all the effort for.
 
That's good to hear but strange they would be quiet about a flaw related to a 3rd party optional chipset whilst communicating a lot about their own hardware flaws!
Anybody have any hard data on the Intel side of things and not interested in speculation?
Might be buying a board this week and whilst I don't see this as a major issue I'd still like to know what the current situation is.
I suppose I could disable the ASMedia chipset in the EUFI but not sure that would fully remove the issue!

AMD never have been good at PR, they have and still do think its a good idea to confess to absolutely any accusation laid at them, some people even take advantage of them for it, PcPer claimed FreeSync had a problem with ghosting, AMD sprang into action feesing upto it saying they will fix it as soon as they can, it turns out it was a problem with the screen PcPer used, have PcPer corrected that, no, in fact they are still pointing to AMD's apology and promises to fix it to legitimize themselves.

AMD need to take a long hard look at their PR, its clearly not doing its due diligence and is far too trusting of external findings, that combination is always a resipy for PR disasters. honestly its almost as if AMD are looking for things to apologize for. stop it.

I say again even if it was Intel (and it could have been an older AMD based system or they didn't want to destroy a production system for potentially destructive live testing) just because a vulnerability was able to be detected on one system doesn't mean that it is possible to exploit it on that system.

CTS-Labs did not get scorned and discredited for AMD bias unless there was actual bias, which could only mean CTS-Labs had prior knowledge to the issue existing on Intel too, they stopped short of outright saying its absolutely Intel because that could cause undue problems for them, its professional curacy.
 
CTS-Labs did not get scorned and discredited for AMD bias unless there was actual bias, which could only mean CTS-Labs had prior knowledge to the issue existing on Intel too, they stopped short of outright saying its absolutely Intel because that could cause undue problems for them, its professional curacy.

No one has actually proved AMD bias (I'm not saying there isn't) on their part. Everything in that post is speculation on your part. Your conclusions are also flawed due to a misunderstanding on your part of how hardware and software analysis is usually carried out.

Their competence and background has been thoroughly discredited, the extent of the scale of these issues has been thoroughly discredited - but that isn't a surprise we all said so from the start but that these issues are real hasn't only not been discredited but also confirmed.

they have and still do think its a good idea to confess to absolutely any accusation laid at them, some people even take advantage of them for it

And people accuse me of some deluded drivel - that is some insane twisting to try and defend AMD - they might tacitly acknowledge issues so as to look into them but they aren't going to put out a statement like they have today with a breakdown of the issues if there wasn't something real to them - even they aren't that stupid.
 
No one has actually proved AMD bias (I'm not saying there isn't) on their part. Everything in that post is speculation on your part. Your conclusions are also flawed due to a misunderstanding on your part of how hardware and software analysis is usually carried out.

Their competence and background has been thoroughly discredited, the extent of the scale of these issues has been thoroughly discredited - but that isn't a surprise we all said so from the start but that these issues are real hasn't only not been discredited but also confirmed.



And people accuse me of some deluded drivel - that is some insane twisting to try and defend AMD - they might tacitly acknowledge issues so as to look into them but they aren't going to put out a statement like they have today with a breakdown of the issues if there wasn't something real to them - even they aren't that stupid.

This is what they said.

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

As for AMD's PR, I used an example, the example you edited out, why edit my post to quote out of context, Roff? its not as if i made it up, its absolutely true, here

 
This is what they said.

Which was a 3rd party take and an assumption NOT backed up in the original technical article they are referencing.

Also you aren't understanding the implications of "It appears that CTS Labs first found vulnerabilities in Asustek’s chipsets" the means you use to discover a hardware flaw doesn't mean that the system used to discover it is itself vulnerable to that problem - that is a huge misconception on your part which any security professional can back up.

There is a big difference between saying "maybe we have a bug with ghosting" and holding hands up to security issues which aren't actually real - that one could quite likely finish them as a company.
 
Which was a 3rd party take and an assumption NOT backed up in the original technical article they are referencing.

There is a big difference between saying "maybe we have a bug with ghosting" and holding hands up to security issues which aren't actually real - that one could quite likely finish them as a company.

They didn't say maybe, they said "likely" they are also not going to provide technical documentation, you should know and understand that, its extremely irresponsible to do something like that because what you are then doing is saying to the hacking community "here this is how you do it" that is also the reason you're supposed to give the vendor in question 90 days notice before publishing, so to give them a reasonable chance to fix the problem before hackers know it exists.
 
They didn't say maybe, they said "likely" they are also not going to provide technical documentation, you should know and understand that, its extremely irresponsible to do something like that because what you are then doing is saying to the hacking community "here this is how you do it" that is also the reason you're supposed to give the vendor in question 90 days notice before publishing, so to give them a reasonable chance to fix the problem before hackers know it exists.

Likely is not a confirmation and critically it is NOT in the original technical article - the likely Intel bit was added by the author of the article at Seeking Alpha. The author of that article was not working with any technical details themselves just created a report and added their own take around the work done by Dan so the rest of your post is irrelevant.

It is also irrelevant because even if they used an Intel system to confirm existence of such issues that doesn't mean that those issues are a danger on that platform something you seem unwilling to comprehend.
 
Likely is not a confirmation and critically it is NOT in the original technical article - the likely Intel bit was added by the author of the article at Seeking Alpha. The author of that article was not working with any technical details themselves just created a report and added their own take around the work done by Dan so the rest of your post is irrelevant.

It is also irrelevant because even if they used an Intel system to confirm existence of such issues that doesn't mean that those issues are a danger on that platform something you seem unwilling to comprehend.

Well of course they are.
 
Well of course they are.

Utter rubbish - you obviously have no idea of how debugging works.

No, They probably don't even exist.

You do realise that as part of this announcement they've essentially libelled the 3rd party providers they've cited as part of the statement if they've just made this up? for instance:

AMD is working with the third-party provider that designed and manufactured the “Promontory” chipset on appropriate mitigations.
 
Last edited:

Makes some interesting points - however as before I disagree about the requirements of making the videos - the chroma keying, etc. is not particularly that good and nothing beyond the level that the average YouTuber is pumping out at home these days - certainly doesn't require a lot of resources as he implies.

EDIT: Going to address this bit again as it comes up in the video:

xCFvU65.png


It isn't simply enough to have those controllers on a board to be backdoored - you need to be able to access those controllers in the first place to be able to then manipulate them to get to the flaws and then once you've compromised the controller (not an impossible feat on Intel [maybe] but on Zen its made easier by the other abilities to work around signed checks using Masterkey, etc.) you need to be able to access something critical with that controller - on the Asus X79-Deluxe mentioned for instance the ASMedia 1042 is connected to the system through the chipset which "talks" to the system on its behalf (hence why things like Marvell SATA ports tend to trail behind Intel's controllers which sit inside the chipset for performance) rather than the closer integration used on Promontory that potentially gives it more direct access. I'm not saying this is impossible on Intel (but with the differences might be - I wouldn't want to bet on that) but there is a reason why they were able to relatively easily exploit it on Zen. There might be other implementations that are vulnerable as well if they take a similar approach to AMD here but I don't know the full range of products and implementations to say much about that.

Whole thing stank badly from the very first second it appeared, however after a bit of time it now seems to stink while having a bit of a blueish tint to it as well.

The whole thing is very bizarre. I can't rule out Intel but I can't see why Intel would take this approach.

Some of the information Adored TV has dug up might indicate a bigger actor playing this out with enough vision to control both sides of unfolding events - feeding CTS Labs just enough information for them to play their part knowing where they'd go with it and then injecting themselves in the media/PR side they expected to see come out of it.
 
Last edited:
Its hard to think intel would do this, its sloppy and a very high risk attempt if they are actually found out. But even so... you cant help but wonder if they at least had a hand in it.

If so and its proved then i hope AMD rain the biggest load of crap down on them as possible, doubt we will ever find out though.
 
Back
Top Bottom