Dubious Research Discovers Ryzen vulnerabilites

[TrixP10]

Rumors of AMD's demise is apparently exaggerated.

Last time I checked they are still trading. Glad I'm not a short seller .

 

[Rroff]

So... "if someone is able to screw with your machine, they can use these to enable them to screw with your machine" **** I guess we're all screwed then... /sarcasm.
Clearly dodgy, you're about the only one here swallowing it.

You are missing the point - in say a business environment with reasons for security such as trade secrets normally if someone somehow breaches local user restrictions there are limits to what they can do - most malware can't stay resident in this case - but this vector allows malware to remain persistent and won't be detected by normal security audits for things like rootkits - AFAIK the same kind of breach hasn't been demonstrated to that degree on Intel - only able to read information currently in flight and meddle with realtime operation but not stay resident surviving a reboot and requires a physical connection with another computer connected up to accomplish it.

It hasn't been discredited only confirmed - which is noted so in links above - that to take advantage of it would require a huge amount of resources - but that is the kind of angle state sponsored hacking groups would try to exploit who'd be looking to get into large corporations to steal information or disrupt operation.

 

[humbug]

TrixP10 quote this back at him ^^^

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.

And the link https://seekingalpha.com/article/41...g93:9b71e336d4ff0e58d5bef892486dff5f&uprof=55

 

[CAT-THE-FIFTH]

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.

Apparently in the US you can get away with it:

https://threatpost.com/researchers-...-precedent-with-st-jude-medical-short/120266/
https://www.bloomberg.com/news/arti...fights-st-jude-lawsuit-over-pacemaker-reports

Look how rarely the US fights patent trolling effectively??

 

[hyperseven]

AMD Security Flaw Narrative Falls Flat.

https://seekingalpha.com/article/41...g93:9b71e336d4ff0e58d5bef892486dff5f&uprof=55

At last, sanity prevails!

• CTS-labs narrative on AMD security issues is now discredited by the security company CTS hired to evaluate the exploit.
• CTS-labs methods, motives, and processes are called into question by interviewers at AnandTech and RealWorldTech.
• The security flaw driven short story has now fallen flat.

Thank you sanity.

You know this was posted just 3 posts before this, why the need to post again? Just sayin...

 

[TrixP10]

Is this so rrroff

The negative brand implications resulting from a false positive can be massively adverse. "This is especially true if the false positive is widely proclaimed. Also, CTS faces the risk of finding themselves at the receiving end of collateral brand damage, resulting from their rush to report their AMD findings."

 

[Rroff]

Is this so rrroff

The negative brand implications resulting from a false positive can be massively adverse. "This is especially true if the false positive is widely proclaimed. Also, CTS faces the risk of finding themselves at the receiving end of collateral brand damage, resulting from their rush to report their AMD findings."

What false positive? Dan Guido has confirmed these vulnerabilities are real even if they aren't an immediate risk to users as they were originally represented and not in the same class as the likes of Meltdown which could be utilised effectively as the initial vector for remote intrusion.

But that isn't really a big revelation - as much was inferred by myself and others on page one of this thread and nothing I've posted since is in conflict with the first two posts I made in this thread.

 

[humbug]

What false positive? Dan Guido has confirmed these vulnerabilities are real even if they aren't an immediate risk to users as they were originally represented and not in the same class as the likes of Meltdown which could be utilised effectively as the initial vector for remote intrusion.

But that isn't really a big revelation - as much was inferred by myself and others on page one of this thread and nothing I've posted since is in conflict with the first two posts I made in this thread.

They make it pretty clear it effects Intel as much as it does AMD and yet he is still sticking to the same narrative the now discredited CTS-Labs tried to push, He hasn't read it all or he's sticking his fingers in his ears to those things inconvenient to his arguments or he knows exactly what he is doing.

Sticking ones fingers in ones ears BTW is why he has me on ignore.

 

[TrixP10]

What false positive? Dan Guido has confirmed these vulnerabilities are real even if they aren't an immediate risk to users as they were originally represented and not in the same class as the likes of Meltdown which could be utilised effectively as the initial vector for remote intrusion.

But that isn't really a big revelation - as much was inferred by myself and others on page one of this thread and nothing I've posted since is in conflict with the first two posts I made in this thread.

Can't remember your first two posts but to clear things up a little
https://seekingalpha.com/article/41...g93:9b71e336d4ff0e58d5bef892486dff5f&uprof=55

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

For me that sums up quite a lot. Enough said.

 

[humbug]

nah ha! ^^^^ thx, now lets see....

 

[Rroff]

Can't remember your first two posts but to clear things up a little
https://seekingalpha.com/article/41...g93:9b71e336d4ff0e58d5bef892486dff5f&uprof=55

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

For me that sums up quite a lot. Enough said.

Nothing there goes against what I've said.

It isn't unusual for a fledgling security firm to test their tools and procedures against a given target and ASMedia controllers aren't an unusual choice as they are widely used. If they discovered some issues and then looked into where those controllers were used to find problems then that would lead them to both Intel and AMD - but on the Intel side so far no one has discovered an issue of this nature but if you are looking around for uses of these controllers then that quickly leads you to AMD's Promontory chipset which is one of the most recent big uses of them and critically ties them deeper into system integration than you normally find in the Intel side giving more potential for deeper system intrusion.

However that would only satisfy one part of the picture - that in itself wouldn't lead them to the other part of the disclosure (Ryzenfall, etc.) concerning the AMD Secure Processor which runs on ARM Cortex - they mention working on "other" projects for AMD also but there is no further explanation there as to how they started to look into this group of issues or why.

The reason they've not (also) targetted Intel is that similar issues to the AMD Secure Engine have already been discovered and patched in things like the Intel Management Engine and/or don't affect Intel to the same level due to differences in how they have implemented things. (EDIT: Actually the issues with Intel's ME than what we are talking with Ryzenfall/Masterkey are worse but they've already been discovered and dealt with a year ago - as per my link here https://www.theregister.co.uk/2017/05/01/intel_amt_me_vulnerability/).

 

[humbug]

Wow, he's ignoring whats right in from of him in plain text.. does he work for CTS-Labs?

 

[TrixP10]

Nothing there goes against what I've said.

It isn't unusual for a fledgling security firm to test their tools and procedures against a given target and ASMedia controllers aren't an unusual choice as they are widely used. If they discovered some issues and then looked into where those controllers were used to find problems then that would lead them to both Intel and AMD - but on the Intel side so far no one has discovered an issue of this nature but if you are looking around for uses of these controllers then that quickly leads you to AMD's Promontory chipset which is one of the most recent big uses of them and critically ties them deeper into system integration than you normally find in the Intel side giving more potential for deeper system intrusion.

However that would only satisfy one part of the picture - that in itself wouldn't lead them to the other part of the disclosure (Ryzenfall, etc.) concerning the AMD Secure Processor which runs on ARM Cortex - they mention working on "other" projects for AMD also but there is no further explanation there as to how they started to look into this group of issues or why.

The reason they've not (also) targetted Intel is that similar issues to the AMD Secure Engine have already been discovered and patched in things like the Intel Management Engine and/or don't affect Intel to the same level due to differences in how they have implemented things. (EDIT: Actually the issues with Intel's ME than what we are talking with Ryzenfall/Masterkey are worse but they've already been discovered and dealt with a year ago - as per my link here https://www.theregister.co.uk/2017/05/01/intel_amt_me_vulnerability/).

Christ! - you were right all along.

I can't believe I got it so wrong. Thanks for putting me right.

Nurse!

 

[Rroff]

Christ! - you were right all along.

I can't believe I got it so wrong. Thanks for putting me right.

Nurse!

Right all along in that there isn't much to see here.

Let me remind people of my first two posts in this thread and that everything I've posted since has been in the light of those two:

Most of them are only really exploitable via some kind of social engineering but a couple of them probably explain why AMD has been very cagey with the wording of some of its press releases over the previous exploits (as in the whole disclosure thing).

While for the typical home user most are only exploitable once you've already given them admin/super user privileges for whatever reason a couple of them are potentially concerning in a corporate environment or other networked environment where relatively low level privileges could allow for compromise of higher level ones.

Neither of these are at odds with anything that has come out since:

There is no immediate risk of exploitation of these vulnerabilities for most users. Even if the full details were published today, attackers would need to invest significant development efforts to build attack tools that utilize these vulnerabilities. This level of effort is beyond the reach of most attackers

Notice that it doesn't say these exploits don't exist or are wrong but that they require a significant investment to make use of in any kind of useful way and so only really a concern for a limited set of circumstances as I noted.

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. In contrast, the recent Meltdown and Spectre flaws required previously unknown techniques and novel research advances to discover and exploit.

Again because other such, relatively mundane, breaches exist doen't change that these exist and present a potential security risk should someone exploit them.

 

[Stanners]

Either discuss or leave the thread instead of childish exchanges.

 

[humbug]

Ok then to sum up these vulnerabilities are born out of the already existing specter exploit, this applies to both AMD and Intel.

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.

As it turns out this ^^^^ was bang on, the problem was likely found with the original Spectre discovery on Intel system's, CTS-Labs realizing that both AMD and Intel use the same ASmedia Chip-Sets and tested AMD's systems for the same issue.
What they then did with this is what got them discredited, they made it out to be an AMD only issue, based on other evidence the likely reason for this was to drive AMD's share price down so they and / their sponsors could profit from it.

As for the actual exploits, on both Intel and AMD you would have to play a hand allowing access to you BIOS, for this reason its not of public concern or a real threat, it is only in technical terms because it simply exists, i suspect this is what CTS-Labs were counting on, and it worked for a while but the security firm they hired eventually realized what was going on and to save thier own reputation quickly clarified their position and publicly discredited CTS-Labs.

 

[Rroff]

"I don't care to discuss the topic, so I thought I'd just troll this thread".

He is right about the amount of drivel though.

Unlike some are trying to make out above these issues although related to wider spread problems are largely manifestations of problems specific to AMD here - for instance the same oversight/bug used to bypass signed code checks can't be used to upload a custom firmware to ASMedia controllers on the Intel side - this flaw lies in the custom work and integration with the whole chipset AMD have done on top of the inherent issues with the controller.

The fact that there are wider spread problems doesn't deflect from the fact they are problems.

People are thinking too small scale - someone with the resources to create the code, etc. to take advantage of these flaws say for instance managed to get a remote desktop session by brute force or social engineering, etc. could utilise them to ensure a persistent entry point to a larger network and then lateral elevation to gain access to things they shouldn't be able to - unlike some are implying most of these exploits don't require physical BIOS access. Sure it isn't the only way to accomplish this but currently it is one of the most promising for people who have the resources to make it work for persistence and staying hidden.

 

[humbug]

Roff these finding likley originated on Intel's ASmedia Chip-Sets and for that reason tested for on AMD, because they use the same Chip-Set, sure enough yes the same problem exists.

However try and actually use that to your advantage, its almost impossible, the difficulty of it makes it a none issue, no one has said the problem doesn't exits, its just massively exaggerated and used to try an damage one of the effected vendors.

 

[smilingcrow]

There's a strong sense of Déjà vu reading this thread as there are many similarities to the way in which the Meltdown and Spectre thread turned into yet another thread where fanboys promoted facts that supported their team and ignored or downplayed those that didn't.
Come on United.
City. City.
Away the lads/fanboys.

 

[Mercutio]

You are missing the point - in say a business environment with reasons for security such as trade secrets normally if someone somehow breaches local user restrictions there are limits to what they can do - most malware can't stay resident in this case - but this vector allows malware to remain persistent and won't be detected by normal security audits for things like rootkits - AFAIK the same kind of breach hasn't been demonstrated to that degree on Intel - only able to read information currently in flight and meddle with realtime operation but not stay resident surviving a reboot and requires a physical connection with another computer connected up to accomplish it.

It hasn't been discredited only confirmed - which is noted so in links above - that to take advantage of it would require a huge amount of resources - but that is the kind of angle state sponsored hacking groups would try to exploit who'd be looking to get into large corporations to steal information or disrupt operation.

Why would you bother with an AMD specific malware? If you have root/admin ANY ****ing root kit is clearly fine. You'd pick one that wasn't so specific so it'd catch more folks out.

Everything you're suggesting is a major issue for AMD applies to most platforms. The only bit in this is there's now some AMD specific ways to stay screwed if you get screwed and they don't want to use something generic to keep you screwed.

How is "screw machine, get admin, install AMD rootkit" different to "screw machine, get admin, install rootkit"? You're clearly pushing an agenda here.

As has been stated and re-stated, none of the actual dangers from this are AMD specific. They either apply evenly to both or only to Intel (or bulldozer/piledriver if we're interested).

It went "these AMD attacks". "But you need root" (thus making them generic)
"Ahh but then AMD rootkits" ... vs rootkits (thus making them generic)

Your goal posts keep moving, you keep having your points proven to be verging on the ridiculous, maybe give it a rest?

If you have a point that is, perhaps make it and leave all the attempted mud-slinging out?