13 Major Vulnerabilities Discovered in AMD Zen Architecture, Including Backdoors

Just when you thought he was smart enough not post on obvious non issues, since these require local access. He then proves you wrong by buying into it.
 
Just when you thought he was smart enough not post on obvious non issues, since these require local access. He then proves you wrong by buying into it.

Local access is not the same as administrative privileges/rights.. any malware disguised as drivers (just as easy example) can run with administrative rights and fool an entire system to run on reboot, Administrative privileges aren't a barrier for a experienced hacker, it's more a temporal setback.. in fact it's easier to achieve administrative rights than open a net port to access the machine itself..

Of course this shouldn't be a issue in properly guarded servers, those with double/triple protections and different administrative key management should be fine, but the issue it's there just not as serious as advertised promoted.
 
Is anyone else bothered by the change in the industry from celebrated meritocracy to corporate cesspool?

Perhaps I'm just getting old... but by 2003 these kinds of BS corporate warfare scenarios started to be more common.
 
So the security flaws are confirmed


And they aren't flaws exploiting complex security holes, but exploiting basic mistakes:

If the whole vulnerability is reliant upon the attacker having localised access to the users main admin account so as to change admin rights and download dodgy drivers then firstly it is not an AMD issue as it can be done on Intel, ARM, IBM and secondly the security problem sits between keyboard and chair.

As for the whole confirmed thing, the only confirmation is that CTS is a scam with no history or track record with a bias tech dosier and affiliation to a company that I am in the process of a law suite against from a affected capitec client that lost a lot of money. Viceroy have a history of stock sabotage that goes beyond what is possible to disclose here.

Kyle Bennett, Steve Burke, Ian Cutress, Hardware Unboxed and I am sure Adored will do something on this matter as it is clearly an attempt at corporate sabotage.
 
Local access is not the same as administrative privileges/rights.. any malware disguised as drivers (just as easy example) can run with administrative rights and fool an entire system to run on reboot, Administrative privileges aren't a barrier for a experienced hacker, it's more a temporal setback.. in fact it's easier to achieve administrative rights than open a net port to access the machine itself..

Of course this shouldn't be a issue in properly guarded servers, those with double/triple protections and different administrative key management should be fine, but the issue it's there just not as serious as advertised promoted.

......what? Please tell me how I can run/install an unsigned driver without elevated privs.

Got any sweet 0-day WIndows 10 privescs?
 
1) It is not true that all the new flaws require local access.
2) Those attacks are exclusive to Zen processors and/or systems integrating ASMedia chipsets. So the idea those flaws affect every ARM, IBM, Intel,... system isn't true.
3) Local access doesn't make this less dangerous. The real problems of those new flaws are their persistence and/or difficulty to be detected:
  • Scenario A: Admin is fired from the company. Before leaving the company he installs a backdoor on the systems where he has access. The new admin cannot detect the backdoor "without extensive analysis" and even if one is detected the persistence property implies the backdoor "could require hardware replacement as a mitigation."
  • Scenario B: Worker builds a new server for another company. Worker builds a new workstation for a customer. He installs backdoors. Admin/user of the build systems cannot detect the backdoor "without extensive analysis" and even if backdoors are detected the persistence property implies the backdoors "could require hardware replacement as a mitigation."
4) I don't care if CTS-labs are new or old, if they have ugly offices or virtual-generated fancy offices. I don't care if CTS-labs gave 24H notice or three-years notice to AMD (they explained why they gave AMD only 24H, but I don't care about this). I care if the flaws are real and dangerous. And they are.
5) I don't care if Viceroy are dirty or not, if they are three guys or three hundred guys. I don't care if they are taken to the court for making something illegal. I care if the flaws are real and dangerous. And they are.
 
Damn. Up until now there was no way for a fired Admin to cause havoc.

Maybe OS mfg's should implement privilege control or something......where only trusted users have admin privs....
 
1) It is not true that all the new flaws require local access.
2) Those attacks are exclusive to Zen processors and/or systems integrating ASMedia chipsets. So the idea those flaws affect every ARM, IBM, Intel,... system isn't true.
3) Local access doesn't make this less dangerous. The real problems of those new flaws are their persistence and/or difficulty to be detected:
  • Scenario A: Admin is fired from the company. Before leaving the company he installs a backdoor on the systems where he has access. The new admin cannot detect the backdoor "without extensive analysis" and even if one is detected the persistence property implies the backdoor "could require hardware replacement as a mitigation."
  • Scenario B: Worker builds a new server for another company. Worker builds a new workstation for a customer. He installs backdoors. Admin/user of the build systems cannot detect the backdoor "without extensive analysis" and even if backdoors are detected the persistence property implies the backdoors "could require hardware replacement as a mitigation."
4) I don't care if CTS-labs are new or old, if they have ugly offices or virtual-generated fancy offices. I don't care if CTS-labs gave 24H notice or three-years notice to AMD (they explained why they gave AMD only 24H, but I don't care about this). I care if the flaws are real and dangerous. And they are.
5) I don't care if Viceroy are dirty or not, if they are three guys or three hundred guys. I don't care if they are taken to the court for making something illegal. I care if the flaws are real and dangerous. And they are.

In both hypothetical the person had local admin access to the system and compromised them from the start, these are possible on Genuine Intel as well, even the threats are seemingly made up and don't really exist as the technical sheets are very spartan at best. In both instances there was a entry and the backdoor BIOS was implanted due to that entry, in this instance you are pretty screwed, it is like giving a begger your credit card and pin and expecting nothing to happen.

The fact that they say they may or may not have monetary interests in this report and their links to Viceroy makes this a corporate sabotage attempt to cause a stock shortage to which both the scam company CTS and Viceroy are hedging on.

David Kanter is the next person to dismiss these threats as real issues as it is possible on all CPU's and the threat is originated from user stupidity. In no way does this remotely cover the same intrusion level of Spectre and Meltdown.
 
1) It is not true that all the new flaws require local access.
2) Those attacks are exclusive to Zen processors and/or systems integrating ASMedia chipsets. So the idea those flaws affect every ARM, IBM, Intel,... system isn't true.
3) Local access doesn't make this less dangerous. The real problems of those new flaws are their persistence and/or difficulty to be detected:
  • Scenario A: Admin is fired from the company. Before leaving the company he installs a backdoor on the systems where he has access. The new admin cannot detect the backdoor "without extensive analysis" and even if one is detected the persistence property implies the backdoor "could require hardware replacement as a mitigation."
  • Scenario B: Worker builds a new server for another company. Worker builds a new workstation for a customer. He installs backdoors. Admin/user of the build systems cannot detect the backdoor "without extensive analysis" and even if backdoors are detected the persistence property implies the backdoors "could require hardware replacement as a mitigation."
4) I don't care if CTS-labs are new or old, if they have ugly offices or virtual-generated fancy offices. I don't care if CTS-labs gave 24H notice or three-years notice to AMD (they explained why they gave AMD only 24H, but I don't care about this). I care if the flaws are real and dangerous. And they are.
5) I don't care if Viceroy are dirty or not, if they are three guys or three hundred guys. I don't care if they are taken to the court for making something illegal. I care if the flaws are real and dangerous. And they are.
Hey it's this guy.

Spinning for the greater good right?
 
Local access is not the same as administrative privileges/rights.. any malware disguised as drivers (just as easy example) can run with administrative rights and fool an entire system to run on reboot, Administrative privileges aren't a barrier for a experienced hacker, it's more a temporal setback.. in fact it's easier to achieve administrative rights than open a net port to access the machine itself..

Of course this shouldn't be a issue in properly guarded servers, those with double/triple protections and different administrative key management should be fine, but the issue it's there just not as serious as advertised promoted.

You can do what you described to any machine with that kind of access even a Intel system, once you have administrative rights you can pretty much do anything. There is a reason why security experts have pretty much dismissed it as nonsense.
 
1) It is not true that all the new flaws require local access.
2) Those attacks are exclusive to Zen processors and/or systems integrating ASMedia chipsets. So the idea those flaws affect every ARM, IBM, Intel,... system isn't true.
3) Local access doesn't make this less dangerous. The real problems of those new flaws are their persistence and/or difficulty to be detected:
  • Scenario A: Admin is fired from the company. Before leaving the company he installs a backdoor on the systems where he has access. The new admin cannot detect the backdoor "without extensive analysis" and even if one is detected the persistence property implies the backdoor "could require hardware replacement as a mitigation."
  • Scenario B: Worker builds a new server for another company. Worker builds a new workstation for a customer. He installs backdoors. Admin/user of the build systems cannot detect the backdoor "without extensive analysis" and even if backdoors are detected the persistence property implies the backdoors "could require hardware replacement as a mitigation."
4) I don't care if CTS-labs are new or old, if they have ugly offices or virtual-generated fancy offices. I don't care if CTS-labs gave 24H notice or three-years notice to AMD (they explained why they gave AMD only 24H, but I don't care about this). I care if the flaws are real and dangerous. And they are.
5) I don't care if Viceroy are dirty or not, if they are three guys or three hundred guys. I don't care if they are taken to the court for making something illegal. I care if the flaws are real and dangerous. And they are.


Scenario A - Any company that fires an Admin and doesn't immediately march him off the grounds, disable his account and change all Service Account passwords deserves everything it gets.
Scenario B - Any company that did this would be sued in court immediately.

Are either possible? Yes

The question is are they likely?

I'll quite happily talk through operational computer security with you that involves real world scenarios, full disclosure I used to be a computer security analyst for a bank.

In order for the AMD stuff to affect the banks business you would have to get into a compound, past security with a door that only operates on a keycard then travel through offices finding a machine that was:

A) Logged on with an Admin Account and left unlocked (disciplinary offence)
B) Not spotted by anyone on the floor (24 hour operation)

It's not Hollywood.
 
Scenario A - Any company that fires an Admin and doesn't immediately march him off the grounds, disable his account and change all Service Account passwords deserves everything it gets.
Scenario B - Any company that did this would be sued in court immediately.

Are either possible? Yes

The question is are they likely?

I'll quite happily talk through operational computer security with you that involves real world scenarios, full disclosure I used to be a computer security analyst for a bank.

In order for the AMD stuff to affect the banks business you would have to get into a compound, past security with a door that only operates on a keycard then travel through offices finding a machine that was:

A) Logged on with an Admin Account and left unlocked (disciplinary offence)
B) Not spotted by anyone on the floor (24 hour operation)

It's not Hollywood.
But but this goes against his agenda that amd sucks!
 
1) It is not true that all the new flaws require local access.
2) Those attacks are exclusive to Zen processors and/or systems integrating ASMedia chipsets. So the idea those flaws affect every ARM, IBM, Intel,... system isn't true.
3) Local access doesn't make this less dangerous. The real problems of those new flaws are their persistence and/or difficulty to be detected:
  • Scenario A: Admin is fired from the company. Before leaving the company he installs a backdoor on the systems where he has access. The new admin cannot detect the backdoor "without extensive analysis" and even if one is detected the persistence property implies the backdoor "could require hardware replacement as a mitigation."
  • Scenario B: Worker builds a new server for another company. Worker builds a new workstation for a customer. He installs backdoors. Admin/user of the build systems cannot detect the backdoor "without extensive analysis" and even if backdoors are detected the persistence property implies the backdoors "could require hardware replacement as a mitigation."
4) I don't care if CTS-labs are new or old, if they have ugly offices or virtual-generated fancy offices. I don't care if CTS-labs gave 24H notice or three-years notice to AMD (they explained why they gave AMD only 24H, but I don't care about this). I care if the flaws are real and dangerous. And they are.
5) I don't care if Viceroy are dirty or not, if they are three guys or three hundred guys. I don't care if they are taken to the court for making something illegal. I care if the flaws are real and dangerous. And they are.

https://www.extremetech.com/computi...ith-amd-security-disclosures-digs-deeper-hole

Care to bash Intel for using Asmedia chips now?

Fucking love how your examples show just how many hoops you have to jump through to try and bash AMD.
 
1) It is not true that all the new flaws require local access.
2) Those attacks are exclusive to Zen processors and/or systems integrating ASMedia chipsets. So the idea those flaws affect every ARM, IBM, Intel,... system isn't true.
3) Local access doesn't make this less dangerous. The real problems of those new flaws are their persistence and/or difficulty to be detected:
  • Scenario A: Admin is fired from the company. Before leaving the company he installs a backdoor on the systems where he has access. The new admin c

He's part of the conspiracy.
 
Isn't the main concern that the exploits, once used, are not detectable?
 
Isn't the main concern that the exploits, once used, are not detectable?

sure, but that goes for the vast majority of security exploits.. the whole problem with this crap is that they tried to specifically tie it to ryzen and ryzen only which is bullcrap, the exploit is specific to chips made by asmedia which are used by damn near every motherboard manufacture over the last 10 years. quite frankly the exploit is childs play compared meltdown and spectre due to the fact that it requires physical access to the system and admin access. the chances of people actually being able to use these type of exploits are few and far between..

just because tv and movies make it look easy doesn't mean it actually is.
 
In both hypothetical the person had local admin access to the system and compromised them from the start, these are possible on Genuine Intel as well, even the threats are seemingly made up and don't really exist as the technical sheets are very spartan at best. In both instances there was a entry and the backdoor BIOS was implanted due to that entry, in this instance you are pretty screwed, it is like giving a begger your credit card and pin and expecting nothing to happen.

The fact that they say they may or may not have monetary interests in this report and their links to Viceroy makes this a corporate sabotage attempt to cause a stock shortage to which both the scam company CTS and Viceroy are hedging on.

David Kanter is the next person to dismiss these threats as real issues as it is possible on all CPU's and the threat is originated from user stupidity. In no way does this remotely cover the same intrusion level of Spectre and Meltdown.

You have ignored what I wrote.

Isn't the main concern that the exploits, once used, are not detectable?

The main concerns are two: they are virtually undetectable and persistent. I.e. even after being detected, there is no way to delete them and changing hardware is the only solution.

The main concern should be if the exploits actually work, that it requires physical access to your equipment.

Physical access is not a requirement for any of those exploits.
 
You have ignored what I wrote.



The main concerns are two: they are virtually undetectable and persistent. I.e. even after being detected, there is no way to delete them and changing hardware is the only solution.



Physical access is not a requirement for any of those exploits.

Then physical access isn't a requirement for these "exploits" on Intel systems either.
 
https://www.extremetech.com/computi...ith-amd-security-disclosures-digs-deeper-hole

Care to bash Intel for using Asmedia chips now?

Fucking love how your examples show just how many hoops you have to jump through to try and bash AMD.

Then physical access isn't a requirement for these "exploits" on Intel systems either.

I already hinted about this in my point 2) above. I will expand on it. There are two kind of attacks reported: those based in ASMedia chipsets and those exclusive to AMD hardware/software. And for the former kind, having a ASMedia chipset is a needed but not enough requirement, because the chipsets can be implemented in a platform with workarounds to mitigate the flaws on the chipsets. There is also a fundamental difference between AMD Zen systems and Intel boards with the ASMedia chipsets, as someone else wrote in another part:

Intel boards don't have the same problems because they use the ASM1142 as a USB controller, not their Security Processor.

For the ASM1142, a USB and PCI interface is added on and you have a USB interface chip. I'm currently working on an ST Micro design that uses an ARM cell as the basis for a USB to serial converter. They use that same ARM cell in the Bluetooth controller attached to the converter. They just add different peripherals to the ARM, more memory, Bluetooth hardware, and encryption hardware for the Bluetooth protocol, etc.

Now what I'm suspecting AMD did was take an ASMedia ARM cell and build their Security Processor around it by adding an encryption engine and other peripherals. But it's that same ARM cell in the middle. And that is where the problem lies. AMD may have left the debug port on the cell open.

Go ahead and read all the articles on the problem again. My theory is consistent with everything that I've been able to find. And is it consistent with CTS finding the problem on Intel boards and AMD. The problem is with the ARM cell, likely the debug port. Its just that on Intel, it's just a USB controller. On AMD, it's the Security Processor with access to everything.
 
Last edited:
I read the transcript of a phone conference over at Anandtech, and while the way they went about releasing the data to the tech media is questionable, it appears the exploits are legit and not FUD as far as the info we have ATM. Physical access is not required, only admin privaliges, and at least some of the exploits can result in malware infecting the hardware on a level that allow it to persist regardless if storage is changed or not. While this could be an issue with other hardware, it is for certain an issue with the AS Media chip and within AMD's layers of t-Base.

While not an issue for the majority of desktop users, I could see this being a nightmare for large networks of servers or workstations in the corporate environment. There would be no way of determining which hardware was infected, at least not without isolating and monitoring each individual unit, and then only if the malware were active at the time.
 
I read the transcript of a phone conference over at Anandtech, and while the way they went about releasing the data to the tech media is questionable, it appears the exploits are legit and not FUD as far as the info we have ATM. Physical access is not required, only admin privaliges, and at least some of the exploits can result in malware infecting the hardware on a level that allow it to persist regardless if storage is changed or not. While this could be an issue with other hardware, it is for certain an issue with the AS Media chip and within AMD's layers of t-Base.

While not an issue for the majority of desktop users, I could see this being a nightmare for large networks of servers or workstations in the corporate environment. There would be no way of determining which hardware was infected, at least not without isolating and monitoring each individual unit, and then only if the malware were active at the time.

Of course the flaws are real, security experts outside CTS-labs have confirmed them using PoCs developed by CTS-labs.

 
I am starting to think Juanrga works for CTS-LABS. Would be funny to find out he also registered AMDFLAWS.com too!

Juanrga Thanks for all the laughs man. Keep trying hard, the tech industry is not behind you on this one LOL.
 
That's not what he tweeted.

This tweet?


This other?


I am starting to think Juanrga works for CTS-LABS. Would be funny to find out he also registered AMDFLAWS.com too!

Juanrga Thanks for all the laughs man. Keep trying hard, the tech industry is not behind you on this one LOL.

Sentiment is reciprocal. I am having same amounts of fun that I had in the RyZen bug thread, when certain people was then negating the existence of the bug (it was all a "media invention", they said then), whereas AMD was already replacing affected CPUs via a RMA procedure.
 
So you need a compromised system/network for these exploits to work, if you have control of a compromised system/network you could potentially do just about anything to that system/network. The exploits are centered around ASMedia chips, the same chips used in many, many AMD and Intel motherboards. The CTS Testing seems to have found this, tested their AMD systems and found they could make exploits that take advantage of the ASMedia chips. What I haven't found is were they also tested Intel systems with ASMedia chips. In any sort of scientific testing, you would think they would at least have a control, but there doesn't seem to be any of that either. Then compound that with the fact that the testing methods and procedures are not also disclosed, so independent confirmation can't be verified, leaves this as a non-issue. This is the definition of fake news and even if this isn't just a giant play to manipulate AMD stocks it is shady as hell done by people looking for any problem to make a specific company look bad.
 
Alex Lonescu is legit. HOWEVER, he stated, "design & implementation issues worth discussing".

It that is a far cry from, "OMG CTS LABS IS 100% SELL AMD STOCK NOW INTEL NUMBAH111111!!!!!!
 
Sorry, but I will side with Linus Torvolds over you. lol Contesting someone who knows his shit and slammed you for good reason.


Who are you anyway? That's right "Feb 22, 2017" Showed up at Ryzen launch out of thin air. Probably one of the returned banned shills I banned from AnandTech years ago with a new IP.


I wish you would have banned some AMD shills that still infest that place.
 
Lots of "experts" here drawing conclusions from scant evidence or no evidence. So ... if this situation benefits Intel, is that proof of Intel's involvement? (In today's parlance ... was there any collusion?) It's easy to jump to conclusions, but the lack of substantiation leaves me cold.

And this: "If a company can’t secure their admin rights they will get hacked whether it’s intel or amd."
Sure, if you can secure your admin rights. But legitimate admins can get in. And, if they can plant permanent, undetectable hacks into the security firmware, they can remain in control even when they've been fired. So ... if these vulnerabilities are real, they're a problem regardless of proper control over admin rights.
 
I am beginning to think these flaws may exist in all hardware, they have just never looked for them before, and now they are going to start finding them concurrently. It's like Pandora's box.
 
Back
Top