Gideon
2[H]4U
- Joined
- Apr 13, 2006
- Messages
- 3,555
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.
Follow along with the video below to see how to install our site as a web app on your home screen.
Note: This feature may not be available in some browsers.
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.
So the security flaws are confirmed
And they aren't flaws exploiting complex security holes, but exploiting basic mistakes:
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.
Jesus Christ what pack of hyenas they have over there.Just saw this over at TPU:
https://www.techpowerup.com/242328/...d-in-amd-zen-architecture-including-backdoors
First two paragraphs:
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:
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.
- 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."
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.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:
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.
- 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."
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.
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.
Yup, I got chewed up and spit out before over there, I try not to post on their forums much these days.Jesus Christ what pack of hyenas they have over there.
Blood thirsty for any chink in AMDs armour.
I bet half of them are shills.
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:
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.
- 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."
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.
But but this goes against his agenda that amd sucks!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.
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:
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.
- 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."
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.
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
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?
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.
Isn't the main concern that the exploits, once used, are not detectable?
The main concern should be if the exploits actually work, that it requires physical access to your equipment.
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.
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.
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.
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.
So all your evidence comes from the same shady as fuck company that released the shady as fuck report
that is funny. he must be so proud.So all your evidence comes from the same shady as fuck company that released the shady as fuck report, which they even put a disclaimer on their website saying it's their opinion and not statements of fact.... wow
Oh, and fucking lol
https://www.realworldtech.com/forum/?threadid=175139&curpostid=175168
Of course the flaws are real, security experts outside CTS-labs have confirmed them using PoCs developed by CTS-labs.
That's not what he tweeted.
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.
Of course the flaws are real, security experts outside CTS-labs have confirmed them using PoCs developed by CTS-labs.
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.