13 Major Vulnerabilities Discovered in AMD Zen Architecture, Including Backdoors

sounds like you are trying to conjure a demon...

Spectre Petronum

https://blog.trailofbits.com/2018/03/15/amd-flaws-technical-summary/

even to Dan Guido the exploits are very hard to bypass on ordinary usage, and ultimately without the administrator allowing access to malware to start the cycle it is impossible to just get exploited. In a world where people that need secure information have multiple firewalls and gateways, top end security devices that will not even let you upload a photo without it getting nuked this as Dan states is just expensive and time consuming to make plausible, you can get nuked at step 1 repeatedly then it doesnt matter any more.
 
Ooops! When you wrote "Security Experts? Well, that's one" I believed that you had identified to Alex Ionescu and then asking me for more experts. I supposed you were familiar with him being a well-known security expert. It is interesting that you seem so worried by my mistake, when I think my mistake was favoring you, but don't worry, I have edited my post to make clear you didn't acknowledge anything. My post now reads:

Ha, having a strop?

Did you notice that I said that I used to be a Computer Security for a bank?

This means that I'm now not - I'm a Senior DBA on Oracle and SQL Server these days, after upgrading the encryption that ATM traffic runs on and watching my boss and his boss get promotions for it (I got nothing) I left.

However, if I get chance I will get in touch with Fred Piper and see what his thoughts are on it - he is my definition of a security expert, not the person you quoted.
 
You guys still struggling with this one. Wasn't it pretty obvious even to Steve it is :)

 
Last edited:

And as stated in #67, the reply is available here
https://www.realworldtech.com/forum/?threadid=175139&curpostid=175180

However, if I get chance I will get in touch with Fred Piper and see what his thoughts are on it - he is my definition of a security expert, not the person you quoted.

Does him has access to the full materials?
 

Kinda ironic that a guy that owns AMD stock writes a biased article about stock manipulation.

To back up this claim, it has had its findings reviewed by not less than ONE, yes, just one, company, Trail of Bits.

The findings have been reviewed and confirmed by more than one.

To further bolster its claim, it has produced one, yes, just one, screenshot of one affected machine where the boot code in the bottom left coroner was replaced with the number "1337."

That is in the public material. The material sent to security experts and to AMD contains working PoCs for all the vulnerabilities on all the hardware.

These findings caused Viceroy Research, another firm with a questionable reputation, to proclaim in a 25-page report on the matter that:

"AMD must cease the sale of Ryzen and EPYC chips in the interest of public safety."

I am not defending Viceroy tactics/wording, but the above quote form the Viceroy report is related to this:

AMD’s flawed chips are components in government and defense products –AMD is pushing Embedded Ryzen and EPYC chips into government and defense industries– from aerospace through to enterprise servers and laptops –through promotion of “advanced security” of its Secure Processor– the very Secure Processor which CTS has found to be fundamentally flawed and open to hacking

It is totally legit to critizice Viceroy by their tactics/wording, but full quotes and context would be given as part of genuine criticism.

By contrast CTS's white paper, which can be found on amdflaws.com, and yet inexplicably hosted by a blank website safefirmware.com, discusses no methodology at all, and for proof of concepts discussed therein offers just one screenshot of a server with a boot screen with "1337" (hacker slang for LEET which is phonetic shortening of ELITE) added to the bottom right hand corner, purportedly by CTS. Due to the lack of any discussion of methodology or technical details in the white paper, it is impossible to verify the veracity of CTS's claims. That said, let's discuss them at face value anyway and see what the worst-case scenario could be.

CTS-labs explained why the paper is hosted on safefirmware. The public whitepaper lacks technical details. The private whitepaper contains the full details. CTS-labs explained that they eliminated the relevant details from the pubic material: "We did not publish technical details about the flaws, to avoid putting users at risk. Right now the public is aware of the vulnerabilities, AMD has been provided full details and are now working on patches, and security vendors have also been given full details and are now developing mitigations."

The SA author also forget to mention that the CTS claims have been verified by security experts outside CTS-labs.

However, in order to deploy this vulnerability [MASTERKEY], the attacker would have to first get access to the computer, then gain root or administrator privileges, and then finally have the ability to flash (update) the BIOS on the computer.

"RYZENFALL, FALLOUT and CHIMERA do not require physical access to exploit. MASTERKEY requires BIOS re-flashing, but that is often possible by just having local admin on the machine and running an EXE. We've confirmed this works on motherboards by Tyan, ASUS, ASRock, Gigabyte, Biostar, and others."

Further, since the ONLY shred of proof was provided in the Masterkey section, it's not entirely clear if it's even real. To avoid repeating myself, the same goes for Fallout and Chimera.

Working PoCs for all the attacks have been provided in the non-public material and that they work on AMD hardware confirmed by people outside CTS-labs.


Fallout uses the same attack vector of a signed driver as Ryzenfall, but on an EPYC processor by targeting the boot loader, with identical results, and identical dubiousness of the proof of concept.

Idem above. So since they have working code for this vulnerability, one would ask how CTS-labs got a working driver for the attack. They also answer this: "Any signed driver that provides access to IO spaces is sufficient to interact with the backdoors. There is a vendor-supplied driver that does this". CTS-labs also confirmed the needed driver is "publicly available for download?".

Chimera is the most serious sounding "vulnerability." [...] CTS bases this bold supposition NOT on actual testing, or proof of concept, but on the fact that it claimed to have reviewed the code from AMD's subcontractor, ASMedia, and AMD's chipset code and found similarities between the two code bases. ASMedia reused some of its own code while fulfilling a contract for AMD. What a shock?

Another false. Once again. Working PoCs there exist for all the flaws.

Even Dan Guido, the CEO of Trail of Bits, the one and only company hired by CTS to double check its findings, disputes the validity of Chimera in a tweet to reporters.

False again. He has confirmed at least three times that Chimera is real, including this "The CHIMERA vulnerability abuses exposed interfaces of the AMD Promontory chipset to gain code execution in the chipset processor."

Further, ExtremeTech published an article where it shows that the same ASMedia chips accused of housing backdoors by CTS also are widely used on any ASUS motherboards with Intel chips. So, why is this categorized as an AMD flaw when it widely affects, if real, both AMD and Intel?

Joel's article was refuted in the comments section of ExtremeTech. CTS-labs categorized CHIMERA as AMD flaw because the failure is in the promontory chipset from AMD. Intel doesn't have a similar chipset, so there is no Intelflaw. Said this, some mobos for Intel systems use the affected ASMedia chips as USB controller. Those mobos could be vulnerable to chimera-like attacks, but the failure here is on ASMedia or in the motherboard company. It could be named Asusflaw if some Asus mobos are affected but not Intelflaw, because it is not flaw from Intel.

Moreover, CTS-labs checked this on Intel hardware: "We've looked into quite a few computers made by HP, Dell, Lenovo, etc. and they were not affected."

If Fallout and Ryzenfall are indeed real, hopefully AMD will patch them quickly, as those threaten AMD's Secure Encrypted Virtualization system. Chimera just looks like nonsense, unless further proof is provided, and Masterkey requires a BIOS flash. If you can flash the BIOS all bets are off, on ALL systems, from ALL CPU vendors.

All the flaws are real. CTS-labs and consulted external experts shared doubts about the flaws can be patched quickly by AMD. And BIOS re-flashing is possible by simply running an EXE: "We've confirmed this works on motherboards by Tyan, ASUS, ASRock, Gigabyte, Biostar, and others."

Potential technical impact of AMDFlaws
  • Code execution in the PSP and SMM (no visibility to typical security products)
  • Persistence across OS reinstallation and BIOS updates
  • Block or infect further BIOS updates, or brick the device
  • Bypass Windows Credential Guard
  • Bypass Secure Encrypted Virtualization (SEV)
  • Bypass Secure Boot
  • Bypass or attack security features implemented on top of the PSP (e.g., fTPM)

Rather than giving AMD a standard 90-day advance notice adopted by Google, Cisco (NASDAQ:CSCO) and others, or the 200-day-plus notice Google gave Intel, AMD, and others before disclosing Meltdown and Spectre, CTS gave AMD less than a day advance notice.

CTS-labs explained why they don't like the standard disclosure method and advocate for their method.

All the subsequent discussion in the article about green screens, domain creations, or Viceroy tactics/wording ... is simply smoke to divert the attention apart from the security flaws


Finally, It is interesting that the author of the SA article "discuss the credibility, or rather the lack thereof, of CTS Labs", when his own credibility as financial consultant doesn't look very good with a ranking of only 1/2 over 5
 
Linus, unlike a lot of us here, is smart enough to ignore you. But yeah, just like last time, I'll trust Linus over juanrga and his myriad cherry picked links.

So if replying someone is ignoring him/her, then I guess the Linus claim "CTS is a scam" means that the security flaws are real. ;)

As I said in #87 you can trust and side with anyone whom you want. it will not change a bit the fact that all what I said in my reply to him is correct.
 
So if replying someone is ignoring him/her, then I guess the Linus claim "CTS is a scam" means that the security flaws are real. ;)

As I said in #87 you can trust and side with anyone whom you want. it will not change a bit the fact that all what I said in my reply to him is correct.

He replied to someone else who quoted you, then (smartly) ignored your reply, unlike me. Yet you somehow twist that to meaning the security flaws are real. Un fucking believable.
 
keep-calm-and-lets-get-back-to-the-topic.png
 
But does that people has access to the full material?

Those people have links into systems that you have not even heard about.

If it as serious as you say then I am certain that one of them will be consulting with various arms of the UK government about implications and more importantly can it be reverse engineered to be used against foreign nations on any platform.

If it's not serious then they won't be working on it.

Does that answer you?
 
Initial AMD Technical Assessment of CTS Labs Research

https://community.amd.com/community...amd-technical-assessment-of-cts-labs-research

AMD confirms all the flaws: those associated to the Promontory chipset and those associated to the Secure Processor:

The security issues identified by the third-party researchers are not related to the AMD “Zen” CPU architecture or the Google Project Zero exploits made public Jan. 3, 2018. Instead, these issues are associated with the firmware managing the embedded security control processor in some of our products (AMD Secure Processor) and the chipset used in some socket AM4 and socket TR4 desktop platforms supporting AMD processors.

AMD confirms the exploits are affected by persistence and difficult detectability:

Attacker can circumvent platform security controls. These changes are persistent following a system reboot.

Attacker may install difficult to detect malware in SMM (x86).

The only difference between CTS-labs and AMD is that CTS-labs said that mitigations and patches would require "months" and AMD claims only needs "weeks".
 
Initial AMD Technical Assessment of CTS Labs Research

https://community.amd.com/community...amd-technical-assessment-of-cts-labs-research

AMD confirms all the flaws: those associated to the Promontory chipset and those associated to the Secure Processor:



AMD confirms the exploits are affected by persistence and difficult detectability:





The only difference between CTS-labs and AMD is that CTS-labs said that mitigations and patches would require "months" and AMD claims only needs "weeks".
Holy fuck, you can't even quote CTS-labs correctly, they said months or maybe not even a year, which was their justification for not informing AMD and waiting the industry standard time.

Not going to bother rehashing everything else that has been pointed out time and time again, but long story short, CTS are paid for hacks who tried to fuck AMD with these borderline bullshiit exploits that requires access to systems that would impact Intel systems just as bad.
 
Initial AMD Technical Assessment of CTS Labs Research

https://community.amd.com/community...amd-technical-assessment-of-cts-labs-research

AMD confirms all the flaws: those associated to the Promontory chipset and those associated to the Secure Processor:



AMD confirms the exploits are affected by persistence and difficult detectability:





The only difference between CTS-labs and AMD is that CTS-labs said that mitigations and patches would require "months" and AMD claims only needs "weeks".

We still have to see AMD patches for Spectre don't we?
 
We still have to see AMD patches for Spectre don't we?

Right, we have already benched Intel with Meltdown+Spectre patches, but still awaiting AMD to issue the needed microcode to activate the Spectre patches on Windows for AMD hardware.
 
Fixes espected within coming weeks makes the disclosure even more dubious if it was that easy to fix, what CTS wanted was to cash in on stock crashes and by into a cheap short option when there is a recovery. There is no justification for the disclose, it was purely done for their gain as had they worked with AMD the resultant fixes would have been imminently due. The only people here acting out of good faith is CTS and the departure from the accepted norm is shocking. Google had more to lose and offered AMD, INTEL et al enough time to work through.
 
This was blown up so some folks could short the stock. Happens all the time. Security problems are real, but not particularly unusual or large. Patch incoming - no performance hit expected.

In short, no big deal. Except I wish I could have shorted AMD roundabout March 7th. I could've made a clanking fortune.
 
  • Like
Reactions: N4CR
like this
This was blown up so some folks could short the stock. Happens all the time. Security problems are real, but not particularly unusual or large. Patch incoming - no performance hit expected.

In short, no big deal. Except I wish I could have shorted AMD roundabout March 7th. I could've made a clanking fortune.

It is worse then just blown up. It shows flaws in a chipset that is not exclusive to the AMD system. And that is really odd that this happens to AMD and not Intel. And none of the flaws can be exploited without having access to computer and or user/password.
 
Last edited:
I don't think most people that are commenting on this, on this site and others, truly understand the impact this could have. Probably because most are just desktop users and enthusiasts, and have no inclination of the corporate IT realm.

They seem to think just because you need admin level access to an effected machine, that it's not really an exploit.

If the exploits are indeed as described, the problem is in not being able to detect changes to the hardware, and persistence of those changes, regardless of storage on the system.

Think of it this way. I work for a company with several thousands of machines on their network, located all over the eastern US. There are hundreds of employees with us, that have admin access to most of those machines. Any one of them could decide for whatever reason, they want to compromise or otherwise harm the company.

Now without these exploits, the company could go behind the culprit and "clean up" the network, undoing whatever was done, formatting drives and such, thus mitigating or completely reversing the damage done.

However, with these exploits, the company could not determine which machines are infected or compromised, and no amount of storage level manipulation would solve the issues. The hardware itself would need to be replaced, and since we can not know which devices are infected, ALL devices would need to be replaced. Considering this network is responsible in part, for the transportation and logistics involved with that transport, of all classes of hazardous materials, what do you think the impact would be?

You have to have admin access, but admins are not saints, and once these exploits are implemented, there is no mitigating them outside of replacing the hardware, assuming you have discovered they are being used at all.

This is of course assuming they truly cannot be mitigated or fixed through other means, which is still not determined as of yet.

I have a nagging suspicion though, that many other architectures are going to found to have similar exploits, not just ASmedia and AMD. This level of exploitation is where the focus is headed, and I fear the repercussions of that focus on not just the industry as a whole, but society itself.

We have taken for granted a certain level of privacy and security with our technology. What if every device that we trust was compromised? Not just our personal computing devices. What about anything and everything connected to a network. Even your modern automobiles are connected and most are "fly by wire", having all electronic control systems.

This issue should not be dismissed just because of the motives of the parties involved.
 
Last edited:
Your story only validates what "many" of us all already know about security and companies how it is managed. https://linux.slashdot.org/story/18...alls-intel-patches-complete-and-utter-garbage

In reality machines that have several admins prolly have sophisticated methods of logging activity (or it should). When companies do stuff like firing their whole cyber security team (Sony) you can expect things to take a turn for the worst. To make it absolutely clear: how your company runs your IT department is their problem if they do not take precautions it is their fault and theirs alone.

This is normal in the grand scheme of things there has to be a catastrophe before anything on a serious level can happen and to be fair companies that bought Intel and have a huge problem with their systems is of their own making (can't stress that enough in the AMD forum) , but the solution for these problems is not to keep painting a picture about security in general but to take things at face value.

There are flaws but there no problems for a good deal of people whom know what there doing, if at any point in time you stray from the path you end up like Sony.

The facts are the things in the CTS labs saga which makes this whole ordeal weird, even Torvalds and many many others stated that if you are serious about security access to computer and user/password is vital. You don't have to agree with the statement but that also makes it clear on where you stand.

And don't forget that CTS LABS has many disclaimers on their page that they are never obliged to change any content on their website reflecting any changes to the situation. Never mind on all of the false and misleading statements that are on that webpage about this "unfixable" security flaws.
 
Last edited:
.... To make it absolutely clear: how your company runs your IT department is their problem if they do not take precautions it is their fault and theirs alone.
....

Depending on where you live, and how malicious the culprit, it may be YOUR problem.
 
I don't think most people that are commenting on this, on this site and others, truly understand the impact this could have. Probably because most are just desktop users and enthusiasts, and have no inclination of the corporate IT realm.

They seem to think just because you need admin level access to an effected machine, that it's not really an exploit.

If the exploits are indeed as described, the problem is in not being able to detect changes to the hardware, and persistence of those changes, regardless of storage on the system.

Think of it this way. I work for a company with several thousands of machines on their network, located all over the eastern US. There are hundreds of employees with us, that have admin access to most of those machines. Any one of them could decide for whatever reason, they want to compromise or otherwise harm the company.

Now without these exploits, the company could go behind the culprit and "clean up" the network, undoing whatever was done, formatting drives and such, thus mitigating or completely reversing the damage done.

However, with these exploits, the company could not determine which machines are infected or compromised, and no amount of storage level manipulation would solve the issues. The hardware itself would need to be replaced, and since we can not know which devices are infected, ALL devices would need to be replaced. Considering this network is responsible in part, for the transportation and logistics involved with that transport, of all classes of hazardous materials, what do you think the impact would be?

You have to have admin access, but admins are not saints, and once these exploits are implemented, there is no mitigating them outside of replacing the hardware, assuming you have discovered they are being used at all.

This is of course assuming they truly cannot be mitigated or fixed through other means, which is still not determined as of yet.

I have a nagging suspicion though, that many other architectures are going to found to have similar exploits, not just ASmedia and AMD. This level of exploitation is where the focus is headed, and I fear the repercussions of that focus on not just the industry as a whole, but society itself.

We have taken for granted a certain level of privacy and security with our technology. What if every device that we trust was compromised? Not just our personal computing devices. What about anything and everything connected to a network. Even your modern automobiles are connected and most are "fly by wire", having all electronic control systems.

This issue should not be dismissed just because of the motives of the parties involved.
How many of those employees also have the ability to modify firmware or driver code in order to take advantage of these exploits, without crashing the system, before they lose access to the system? IT specialists generally aren't hackers, and the ones who know how to write programs probably don't also know how to modify binaries in such a way that they would still function and be installable without disabling critical security features of the os. Then they could hire someone else to write the exploit, but that person would need to get the modified binary onto the system somehow (usb, cd, remote terminal, etc), which would probably raise flags at any properly secured company.
 
Ok, So I am little late to this thread, but from what I am reading.. Everything, on Every Computer, is Hackable, When Givin Administrator Access. <- Or hacking your way into administrator access, so you can do some of these things, seems pointless.. For that matter, it seems Intel would be susceptible to these kind of attacks aswell.. all boils down to having Administrator Access..
 
These long winded threads are boring.

Because they always turn into an endless bantering bicker about semantics
 
How many of those employees also have the ability to modify firmware or driver code in order to take advantage of these exploits, without crashing the system, before they lose access to the system? IT specialists generally aren't hackers, and the ones who know how to write programs probably don't also know how to modify binaries in such a way that they would still function and be installable without disabling critical security features of the os. Then they could hire someone else to write the exploit, but that person would need to get the modified binary onto the system somehow (usb, cd, remote terminal, etc), which would probably raise flags at any properly secured company.

They don't need to know how to do anything, that's the problem with this new focus on hardware exploits in particular, it's being proliferated. There are videos on how to make bombs from publically available products. There are videos on how to use these exploits. It's a Pandora's box. If you know anything about the security of modern hardware, you know it can be done easily once all the parameters are set, and opportunity arises for code injection. Again the problem is not in the act itself, as much as the stealth and persistence of the act, and no amount of storage manipulation correcting the issues of said act.

Considering what admin accounts are going for in the dark now, it should concern everyone.
 
Tell me again, which security measures they bypassed or disabled without someone being notified? They have to get the exploited binary on the system or they can't do anything with these flaws. Or else, they have to modify the firmware/microcode themselves using a program that's probably not installed by default...
 
Tell me again, which security measures they bypassed or disabled without someone being notified? They have to get the exploited binary on the system or they can't do anything with these flaws. Or else, they have to modify the firmware/microcode themselves using a program that's probably not installed by default...

Are you serious?

Unplug cable, write image, inject code from portable media, rewrite image, plug back in cable. That's only if they are SUPER paranoid. What's worse, you could probably do it from bootable media or NetBIOS.
 
Are you serious?

Unplug cable, write image, inject code from portable media, rewrite image, plug back in cable. That's only if they are SUPER paranoid.
Right, but then you have a notification of the computer being disconnected from the network, an external media being inserted, some weird/unusual binary being copied to the system (it has to be loaded into memory before it runs) or else a weird script being run from portable media. You're telling me nobody would investigate this kind of suspicious activity? The notification doesn't just not happen because the computer was disconnected while the act was in progress.
 
Right, but then you have a notification of the computer being disconnected from the network, an external media being inserted, some weird/unusual binary being copied to the system (it has to be loaded into memory before it runs) or else a weird script being run from portable media. You're telling me nobody would investigate this kind of suspicious activity? The notification doesn't just not happen because the computer was disconnected while the act was in progress.

First off, machines drop off the network all the time, ours do once a week for system maintenance. We are talking thousands of machines over hundreds of thousands of square miles. Anything done to the machine while off network can be erased with the image restore. What's worse is the size of deployments are so small now, it could be done in minutes. Not all networks are the same, you must be thinking of some large workstation deployments.
 
First off, machines drop off the network all the time, ours do once a week for system maintenance. We are talking thousands of machines over hundreds of thousands of square miles. Anything done to the machine while off network can be erased with the image restore. What's worse is the size of deployments are so small now, it could be done in minutes. Not all networks are the same, you must be thinking of some large workstation deployments.
Ah, yeah that could work. I doubt if someone would bat an eye at a system restore as long as you had a good explanation lined up, too. Good system policy might require network access or a secure key to grant system restore powers, but a sysadmin would probably have easy access to such a thing anyway, and requiring network access might be considered overkill (plus could make fixing network issues difficult in some circumstances).
 
Ah, yeah that could work. I doubt if someone would bat an eye at a system restore as long as you had a good explanation lined up, too. Good system policy might require network access or a secure key to grant system restore powers, but a sysadmin would probably have easy access to such a thing anyway, and requiring network access might be considered overkill (plus could make fixing network issues difficult in some circumstances).

Even easier, a portable OS deployment with everything on the media to embed the exploit rapidly, power cycle the machine.....

I don't like talking about this.
 
Well shit, when you put it like that we are all fucked! Every company and person better get rid of their AMD processor since these exploits are so easy to execute and can happen anytime anywhere! :rolleyes:
 
Back
Top