Just let Rroff Backpeddle and leave it at that.......................no need to take it any further.
-
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
- Thread starter jwilliamson47
- Start date
Just let Rroff Backpeddle and leave it at that.......................no need to take it any further.
Where have I back peddled?
It would be nice if people read the actual information and put some comprehension in - the only hard facts is that someone has attempted to gain from this - so far evidence pointing at CTS Labs is entirely circumstantial.
PS: These issues can't be both discredited as being actual issues and at the same time affect companies other than AMD if that was the case have some sense people.
Last edited:
You certainly set yourself up by wanting to play devils advocate.
Most of this thread you've been at it.
Maybe you like it or maybe you feel trapped into defending the minority position after putting yourself there.
The good that comes from the exploits of CTS and company is such small beans that you're on your own.
Most of this thread you've been at it.
Maybe you like it or maybe you feel trapped into defending the minority position after putting yourself there.
The good that comes from the exploits of CTS and company is such small beans that you're on your own.
Problem is people are just parroting information as fact from media sources which is actually opinion or the best fit the article author could come up with when other possibilities do exist and in some cases very poor understanding of what the author is actually saying.
Obviously no one here has actually gone away and compared the AMD Promontory chipset diagrams to Intel's PCH or they wouldn't be still trying to draw comparisons in the way they are and so on.
Just the firm CTS-Labs hired and the rest of the industry, Intel and AMD use the same ASmedia Chip-Set, it was found in the Intel side and as a result tested for on the AMD side.
The problem is this company could have some credence to their claims but the way they have gone about highlighting them has been shonky, shady and amateur at best. I mean the whole "the company shares are worth 0" etc. What is that other than a complete attempt to try and besmirch AMD. They way to do this kind of thing is the way its been done before. Intel, AMD etc were given 6 months for the last exploits and although there was moaning about why they had sat on it that long it wasn't as much as the moaning regarding fixing it/getting new code and drivers out there. Despite this, this company seem to have decided that their lesser threat that they are making out to be a bigger threat required no time for AMD to react and went public with it. Did you know about these "threats" before these guys put them out there? I know i didn't.. So what harm would giving them 6 months to take a look at it do? That's right, they weren't trying to help it was purely a case of trying to affect AMD as a business and therefore its value. (As happened with Intel, albeit its bounced back from then i think??)
@humbug as people keep relaying your posts as you've asked them to apparently - the same controllers are present but notice that on the Intel side the external controllers performance generally is inferior to Intel's whatever the brand (and people reccomend using the Intel ports) while with Zen AMD managed to get performance broadly on par with Intel even when using the same ASMedia controllers ergo they are more directly tied to the main system on AMD's latest chipsets which opens up a different security situation.
Just having a controller with those issues isn't enough you need access to them to exploit those issues in the first place (it is relatively easy to debug them on an Intel system to find the flaws but as noted on the Intel system you don't just get the same read/write access) and then to be able to use those issues to attack the main system.
Just having a controller with those issues isn't enough you need access to them to exploit those issues in the first place (it is relatively easy to debug them on an Intel system to find the flaws but as noted on the Intel system you don't just get the same read/write access) and then to be able to use those issues to attack the main system.
So from what I read... Basically if anyone is able to do half this stuff on a machine, they also could have done half a million other things as well... You know.. like on ANY machine where you have elevated access already.
What a bizarre report.
What a bizarre report.
What makes this one a little different to your average rootkit, etc. is that it enables persistence of access deep into a system in a similar fashion to the supposed NSA hdd backdoor: https://www.theregister.co.uk/2015/02/17/kaspersky_labs_equation_group/
Again its verified in concept, albeit requiring significant resources but whether it fully checks out when looked at by AMD is another matter.
At least now you're debating me instead of pretending you have me on ignore.
You're repeating the CTS-Labs lie, you're the only one on the planet still doing it, the very people CTS-Labs hired have said this is likely born out of security flaws found with ASmedia Chip-Set's accessing chip controllers on Intel system. no paper thin defense of CTS-Labs can get around that.
I've only read about 3 of your posts (including this one which I assumed was a follow up so read it) - due to people sending them to me.
You are misunderstanding the claims made (and so is some of the media). Being able to debug a controller on an Intel platform (which often requires a physical connection to the board) is a completely different story (normally you only get the ability to read and maybe modify some registers in flight) to being able to gain full read/write and store control - let alone then make use of that controller once you have hijacked it to do something useful.
It isn't enough just to have a controller with flaws on a board - you need to be able to access those flaws to take control of the controller and then make use of that compromised controller to do something else like write into system memory that you aren't supposed to be able to.
Take the X79 platform for instance - the PCH uses Intel C6xx/X79 controllers for everything bar USB 3.0 which uses an external controller (which might be ASMedia in some cases) the controller has to talk to the chipset which then interfaces with the main system on its behalf - even if you find a way to compromise the controller in any kind of useful way (which hasn't been demonstrated to date and bare in mind these controllers have been used like this a LONG time before Promontory) you still don't have a direct connection to the system. In some cases there are front panel USB 3.0 connections on a separate controller where the controller is connected to the CPU directly but it doesn't have the same kind of access to the system as the chipset does.
This is where Promontory comes in because AMD outsourced the controllers inside the chipset which is directly interfaced to the system - check the controller location and they are sitting on PCI 0, Device <n> while external controllers will be like PCI 6, Device 0, etc.
EDIT: Possibly a similar kind of way of using the exploited controllers will be found on other systems down the road who knows, that doesn't make it less of a problem - but that AMD's Promontory chipset is the most recent big use of the chipset and that apparently its not so hard to make use of to attack the system directly compared to other uses of the controller once you've compromised it makes for a good reason in that respect why they have focussed on it.
Last edited:
You're quite obviously reading my posts now tho......
You have yet to explain how built in software access to Intel's Chip Controller negates access to Intel's Chip Controller.
Fine I'll entertain this bit.
First off you are confusing two different things here the secure processor is related to the so called "Ryzenfall" exploit which makes use of the "Masterkey" (though some aspects of it are possible without) vulnerability when using a customised BIOS to upload a compromised firmware to the PSP allowing it to work around signed checks - this is fully unrelated to ASMedia controllers. Once exploited this is one avenue (again this is only in concept) for hiding malware in the system which offers a level of persistence and obscurity not normally achievable with software malware - similar (sort of) and infact worse exploits have been found on the Intel side as I've noted before - but they've been fixed the only other known similar vulnerability on the Intel side has not yet been proven to be possible beyond sniffing what is going on inside when physically connected which is bad but largely a non-issue due to the requirements and limited impact https://www.theregister.co.uk/2017/11/09/chipzilla_come_closer_closer_listen_dump_ime/
As for the "Chimera" part the theory is that you can use the lacking mitigation against attacks of the ASMedia controllers to compromise the chipset and in turn either launch a man in the middle attack manipulating data that flows between external devices connected to the controller and the system (theoretically this is possible with external controllers as well) or to attack the system directly (this isn't so feasible due to being much harder/impossible to escalate the compromise to direct memory access, etc.) - the crucial aspect here is that on AMD's Promontory chipset they've used these controllers internal to the chipset itself - unlike older AMD systems and Intel systems where the controllers either hang off the chipset and have the chipset work on their behalf to handle the main system or have a more direct connection to buses on the main system themselves (a slightly less common setup) but these buses don't have the same access to the main system as the chipset does. Because these controllers are sitting inside the chipset things like this are potentially possible:
As once you are inside the chipset you can potentially escalate to compromising features like its access to system memory - the vulnerabilities in the controllers potentially give you a path to compromising the chipset in a way that isn't possible when they work through the chipset rather than inside it.
It isn't coincidence that AMD have managed to substantially increase peripheral IO performance with Ryzen and they've done that by bringing the controllers more tightly integrated with the system and unfortunately it seems those controllers are ones that apparently have some weaknesses on the security side.
I'll repeat again that at this point it isn't actually proven as possible by AMD themselves or anyone with the resources to actually build and test the full working theory but the proof of concept has been verified by 3rd parties and limited testing has shown that it at least partially works.
EDIT: End of the day this isn't a competition of who is worse affected that aspect it immaterial a security vulnerability is a security vulnerability even if someone else has it the same or worse - and it isn't that noteworthy that they've concentrated on AMD here as some of this stuff has already been discovered and patched on the Intel side and/or is much harder to compromise if it is possible i.e. the Promontory chipset and some flaws in the way signed code checks work specific to AMD has made it a bit easier for a fledgling company to find issues within the AMD system whereas even assuming they are also exploring Intel options it will likely take them a lot longer and central to this seems to be a fledgling security company trying to make a name for itself and going off half-cocked at the first "big" vulnerability they found.
First off you are confusing two different things here the secure processor is related to the so called "Ryzenfall" exploit which makes use of the "Masterkey" (though some aspects of it are possible without) vulnerability when using a customised BIOS to upload a compromised firmware to the PSP allowing it to work around signed checks - this is fully unrelated to ASMedia controllers. Once exploited this is one avenue (again this is only in concept) for hiding malware in the system which offers a level of persistence and obscurity not normally achievable with software malware - similar (sort of) and infact worse exploits have been found on the Intel side as I've noted before - but they've been fixed the only other known similar vulnerability on the Intel side has not yet been proven to be possible beyond sniffing what is going on inside when physically connected which is bad but largely a non-issue due to the requirements and limited impact https://www.theregister.co.uk/2017/11/09/chipzilla_come_closer_closer_listen_dump_ime/
As for the "Chimera" part the theory is that you can use the lacking mitigation against attacks of the ASMedia controllers to compromise the chipset and in turn either launch a man in the middle attack manipulating data that flows between external devices connected to the controller and the system (theoretically this is possible with external controllers as well) or to attack the system directly (this isn't so feasible due to being much harder/impossible to escalate the compromise to direct memory access, etc.) - the crucial aspect here is that on AMD's Promontory chipset they've used these controllers internal to the chipset itself - unlike older AMD systems and Intel systems where the controllers either hang off the chipset and have the chipset work on their behalf to handle the main system or have a more direct connection to buses on the main system themselves (a slightly less common setup) but these buses don't have the same access to the main system as the chipset does. Because these controllers are sitting inside the chipset things like this are potentially possible:
As once you are inside the chipset you can potentially escalate to compromising features like its access to system memory - the vulnerabilities in the controllers potentially give you a path to compromising the chipset in a way that isn't possible when they work through the chipset rather than inside it.
It isn't coincidence that AMD have managed to substantially increase peripheral IO performance with Ryzen and they've done that by bringing the controllers more tightly integrated with the system and unfortunately it seems those controllers are ones that apparently have some weaknesses on the security side.
I'll repeat again that at this point it isn't actually proven as possible by AMD themselves or anyone with the resources to actually build and test the full working theory but the proof of concept has been verified by 3rd parties and limited testing has shown that it at least partially works.
EDIT: End of the day this isn't a competition of who is worse affected that aspect it immaterial a security vulnerability is a security vulnerability even if someone else has it the same or worse - and it isn't that noteworthy that they've concentrated on AMD here as some of this stuff has already been discovered and patched on the Intel side and/or is much harder to compromise if it is possible i.e. the Promontory chipset and some flaws in the way signed code checks work specific to AMD has made it a bit easier for a fledgling company to find issues within the AMD system whereas even assuming they are also exploring Intel options it will likely take them a lot longer and central to this seems to be a fledgling security company trying to make a name for itself and going off half-cocked at the first "big" vulnerability they found.
Last edited:
That looks like a Copy and Paste from CTS-Labs explanations.
The Secure Controller, which for AMD is ARM Cortex IP resides on the Ryzen CPU its self, not on the ASmedia Chip-Set. here is an example of this.
That embedded ARM IP isn't even volatile, it cannot be flashed or programed.
Its just one example where CTS-Labs, and there in you are factually wrong, you started out very doggedly trying to legitimize CTS-Labs right from the very start and even now that they have been debunked and discredited you are carrying on with that as if it never happened.
Which is exactly what my post above says.
If you look at the documentation it shows how using the exploited BIOS you can attack the boot loader to strap parts of the firmware at runtime and upload code to the secure processor.
That looks like a Copy and Paste from CTS-Labs explanations.
The Secure Controller, which for AMD is ARM Cortex IP resides on the Ryzen CPU its self, not on the ASmedia Chip-Set. here is an example of this.
That embedded ARM IP isn't even volatile, it cannot be flashed or programed.
Its just one example where CTS-Labs, and there in you are factually wrong, you started out very doggedly trying to legitimize CTS-Labs right from the very start and even now that they have been debunked and discredited you are carrying on with that as if it never happened.
You know what, i'll expand on this, CTS-Labs claim this renders EPYC useless "IE server people don't but them" EPYC doesn't even have a Chip-Set, i'll say that again: EPYC has no Chip-Set.
The Chip-Set on Ryzen are just there to provide extra USB 3 and For X370 boards extra lanes for multiple M.2 Raid.
In fact my £75 ASRock has M.2 Raid, on Intel platforms you only get that on X299 after an extra £200 to unlock it.
You mean the exact thing they show in the diagram on their website?
Notice no Chimera noted for EPYC Server.
You mean the exact thing they show in the diagram on their website?
Notice no Chimera noted for EPYC Server.
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 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 rather what it actually illustrates, replace the AMD text with Intel and then its completely accurate.
I might do that later, the power of pictures...
