[BUG] AMD security flaws

[Tom_Sand]

Did a search and couldn't see a thread about this so thought I should post.

AMD processors impacted by 13 serious flaws, says CTS Labs
https://m.hexus.net/tech/news/cpu/116174-amd-processors-impacted-13-serious-flaws-says-cts-labs/

Don't know the websites reputation of the website or the research company but sounds pretty bad

 

[MichaelBits]

Doesn't really seem like those are that bad, as he states here:

Due to the limited possibilities of these vulnerabilities being exploited remotely and no evidence of associated malware in the wild one shouldn't worry too much at this time.

 

[Tom_Sand]

That's what I get for skimming the article! Missed that last paragraph

 

[Metanis]

Although if you went to the AMD web site and looked for guidance you'd leave sadly unfulfilled.

 

[phaZed]

Due to the limited possibilities of these vulnerabilities being exploited remotely and no evidence of associated malware in the wild one shouldn't worry too much at this time.

This is potentially devastating for AMD. I sincerely doubt the above statement.

Let's recap:

Take control over Ryzen and EPYC Secure Processors
Take control over Ryzen Chipset
Infect AMD chips with malware
Steal credentials on high-security enterprise networks
Evade virtually all endpoint security solutions
Cause physical damage to hardware

You will notice that three of the four vulnerability classes can only be taken advantage of if an admin runs some malware on the local system.

Ya, cause you know, that never happens.

Exploiting MASTERKEY requires an attacker to be able to re-flash the BIOS with a specially crafted BIOS update.

Well ya, but how hard it is to package a BIOS with the manufacturer's BIOS tool and a script to run it all.

As for "It can't be remotely done", that's BS. Gaining remote access is a totally different hack in itself - what you decide to do after gaining access as Root is totally separate. They are running OS level applications to accomplish these tasks. If the OS is compromised (as is generally the case) via malware etc. then these can be run.

Also: "Not in the Wild" doesn't mean jack. Everybody just learned where to direct their hacking skills and talents.

 

[fencepost]

Perhaps devastating, however a different recap....

A 6-month-old security research firm that is owned by(? Just affiliated or same owners?) a technology hedge fund and which has no other releases to its credit found several security flaws in AMD's security handling that can be exploited by anyone with local administrative rights to the affected system, the most serious of which requires reflashing with a modified BIOS. They created some fancy graphics, came up with catchy names, registered a domain name, hired a PR firm, etc. in late February (amdflaws domain registered 2/22 I believe), then told AMD about the flaws ~24 hours before publicly announcing them almost 3 weeks later. Most or all of the flaws seem like firmware issues that can likely be patched, probably in well under the customary 90 days notice that many use for this kind of disclosure. There is no indication that any of these can be remotely exploited by unprivileged users.

It's not quite a nothingburger, but it seems custom-tailored as a way to try to impact stock prices by hyping difficult-to-exploit problems that haven't been patched because the vendor hasn't even had time to fully evaluate them. Anyway, if someone has local administrator on the box already it seems there are more likely approaches for mischief, though this might allow a state actor to craft something that would persist through a nuke'n'pave.

 

[coffee]

Article is already being debugged on rededit [sp?]. AMD stock was a victim of a short attack. They used this 'cts' as the motivator to get the price down to where they could cover. Low of day was 11.11 briefly and the covering began. This 'cts' has only been around very shortly (2018 domain registration) and was registered at GoDaddy. I will look for the link and post it here when I find it.

BTW - How to run the exploits:
1. Have physical access to the computer/server.
2. Flash the bios.
3. Reboot.

think....

LINK FOUND: https://www.reddit.com/r/Amd/comments/846gpm/how_cts_labs_created_their_offices_out_of_thin_air/

coffee

 

[phaZed]

I care not about the researchers/company/etc.

The only thing that matters... are these vulnerabilities real or not. The consensus is that they are real vulnerabilities.

Everyone keeps saying "They didn't give them 90 days before disclosure!" - The rule was never to give 90 days before disclosing a bug has been found, it has been the custom to give 90 days before releasing and disclosing the vulnerability and inner workings. They have not released the vulnerability. The 90 day thing is just Google Project Zero's official policy.

AMD left backdoors/Dev/Debugging on, on both the ASMedia chip and the Ryzen/et.al processor - both. It can't be turned off without modifying circuitry.

AMD's inherent CPU security is broken at this time.

https://www.wired.com/story/amd-backdoor-cts-labs-backlash/

it did share them privately with New York-based security firm Trail of Bits, which essentially confirmed the central findings. "Regardless of hype, they found vulnerabilities that work as described," says Dan Guido, Trail of Bits' founder. "If you’ve already taken over a computer to a certain extent, they'll allow you to expand that access, or to hide in parts of the processors where you didn’t think malware could be."

So, there's that.

BTW - How to run the exploits:
1. Have physical access to the computer/server.
2. Flash the bios.
3. Reboot.

think....

No, only one of the four vulnerabilities needs a BIOS flash. Even then, so what? It's not hard to flash a BIOS via a service or command prompt without user interaction. It happens right in the OS. You don't need physical access... only remote access.

The other three vulnerabilities only require Administrator Access - not as hard as one may think when dealing with a Windows box (It's fairly easy given the right circumstances and/or OS). Again, It is absolutely possible, and is routine, to gain remote access and then escalate to Root or Admin - everyone that learns Metasploit will do this in the Metasploit 101 classes.

 

[fencepost]

If someone has local administrative access to the machine there are almost certainly much easier and more efficient/effective ways to get secured data. The BIOS flash option may make it easier to retain that privileged access or make it persistent across clean installs, but I'm not sure it'd do much more than that.

Perhaps my thinking is muddled because I'm tired and headachey from not enough caffeine today, but with local admin access couldn't you install your own local root certificate(s) set up something to basically MITM just about all secured traffic that wasn't using certificate pinning? That's basically what most "Internet Security" antivirus packages do to let them inspect web traffic (e.g. Bitdefender on my local machine here). Throw something into the processing stack for network traffic (for more info, see https://en.wikipedia.org/wiki/Windows_Filtering_Platform), massage packets as they go through, and just about the only way anyone's going to notice is if their AV or antimalware software flags it. If you have a fake CA on the machine, you can make just about every human-readable part of the certificate look right.

Also, more info coming out on CTS basically being a short-selling scheme: https://twitter.com/cataclysmza/status/973621504427651072 for some record of involved parties doing this before in Africa.

LINK FOUND: https://www.reddit.com/r/Amd/comments/846gpm/how_cts_labs_created_their_offices_out_of_thin_air/

And wow, quick summary for those not following it: The videos? Guys in front of greenscreens, with stock office footage added in behind them.

 

[coffee]

http://www.zdnet.com/article/linus-torvalds-slams-cts-labs-over-amd-vulnerability-report/

 

[Alexey]

If someone has local administrative access to the machine there are almost certainly much easier and more efficient/effective ways to get secured data.

Yeah, that's it. If someone has local admin, they own the machine. There is no need for fancy hardware hacks, unless in very specific circumstances (e.g. reflash BIOS to make an entry point for later attack and then withdraw). If admin runs malware on the machine, he is pwned regardless of CPU make and model.

Physical damage to hardware is interesting, though, if true.

 

[GTP]

Physical damage to hardware is interesting, though, if true.

Physical damage how?
Over voltage? Overclocking?
if overclocked it would still be governed by the BIOS settings or thermal limits wouldn't it?
If over voltage it would trip the failsafe and shutdown?

 

[Alexey]

Physical damage how?

Don't know. The article mentions it, but no details. As I think the rest of their exploits are hogwash, I suspect we're looking at something like "requires local physical access, requires local administrator to manually destroy something".

 

[fencepost]

I suspect the physical damage would be in the category of "If you have this, you can flash a nonfunctional BIOS and brick the machine."

As for persistent access, for the most part I'd consider that state-level stuff, along with something I vaguely recall from years ago about hard drive firmware designed for espionage. If you have someone state-level throwing serious resources at covertly tracking you, you have problems.

 

[Your PCMD]

Perhaps you should take a look at this instead of getting all worked up.

 

[Alexey]

Perhaps you should take a look at this instead of getting all worked up

Yeah, Youtube is good for something. Thank you.

 

[phaZed]

The physical damage potential is apparent when looking at the ASM1142 Datasheet:
1. Enable/Disable Over current protection.
2. PCIE port power - can be set over spec.
3. The ASM1142 is the Battery charge controller.

The ASM1142 handles Normal and Suspend power regulation, set by flipping some registers. Battery charging can be allowed to overcharge or apply unsafe voltages causing battery swelling or explosion.

On page 27 of the ASM1142 datasheet it implicitly states that setting parameters over recommended will cause permanent damage to the ASMedia host controller.

if overclocked it would still be governed by the BIOS settings or thermal limits wouldn't it?
If over voltage it would trip the failsafe and shutdown?

Nope, the chip that is hacked is the power management/PCIE/USB controller. Failsafes for OVP and OCP are programmable.

Perhaps you should take a look at this instead of getting all worked up.

He kinda screws up though... like the rest of the media.

You can't complain about how shady the outfit is for releasing the news "too quickly" and in the same breath shame them for not having a proof-of-concept or exploit code available as proof of viability (4:15). And really, they do have the source code as they have confirmed it with a reputable security outfit "Trail of Bits" - which he fails to mention.

He misses the whole point about the BIOS (as does his "security friends") It's not that if you just have local Admin access you could flash a BIOS... the BIOS has to be signed and verified by the AMD Platform Security Processor. So, the whole idea is that a malicious BIOS should be prevented by AMD's security... that is now broken. The fact that we can now flash an unsigned malicious BIOS update is the real news. You can contrast the BIOS issue by looking over at LibreBoot where they have been pleading with AMD to release the firmware as open source:

https://libreboot.org/amd-libre.html

As documented in the Libreboot FAQ section, AMD is currently uncooperative in the libre software movement. Specifically, it releases non-free binary-only firmware for its platforms, along with tyrant technologies like the AMD Platform Security Processor.

We in the Libreboot project call on AMD to release source code and start cooperating with our upstream, coreboot (and librecore) for its new Ryzen platform and existing Zen platforms. This includes source code for all initialization firmware (typically referred to as the BIOS or UEFI firmware, by some members of the community), and in particular, the AMD Platform Security Processor, to allow the free/libre software community to use AMD hardware that is entirely freedom-respecting. If it’s not too much to ask, we also would like source code and signing keys, including for the PSP and microcode for the CPU.

So, we should now be grasping the breadth of what is going on with the BIOS part of it. Looks like LibreBoot will be in luck as now even they will be able to craft a BIOS to bypass the AMD PSP .

 

[Your PCMD]

The physical damage potential is apparent when looking at the ASM1142 Datasheet:
1. Enable/Disable Over current protection.
2. PCIE port power - can be set over spec.
3. The ASM1142 is the Battery charge controller.

The ASM1142 handles Normal and Suspend power regulation, set by flipping some registers. Battery charging can be allowed to overcharge or apply unsafe voltages causing battery swelling or explosion.

On page 27 of the ASM1142 datasheet it implicitly states that setting parameters over recommended will cause permanent damage to the ASMedia host controller.


Nope, the chip that is hacked is the power management/PCIE/USB controller. Failsafes for OVC and OCP are programmable.


He kinda screws up though... like the rest of the media.

You can't complain about how shady the outfit is for releasing the news "too quickly" and in the same breath shame them for not having a proof-of-concept or exploit code available as proof of viability (4:15). And really, they do have the source code as they have confirmed it with a reputable security outfit "Trail of Bits" - which he fails to mention.

He misses the whole point about the BIOS (as does his "security friends") It's not that if you just have local Admin access you could flash a BIOS... the BIOS has to be signed and verified by the AMD Platform Security Processor. So, the whole idea is that a malicious BIOS should be prevented by AMD's security... that is now broken. The fact that we can now flash an unsigned malicious BIOS update is the real news. You can contrast the BIOS issue by looking over at LibreBoot where they have been pleading with AMD to release the firmware as open source:

https://libreboot.org/amd-libre.html



So, we should now be grasping the breadth of what is going on with the BIOS part of it. Looks like LibreBoot will be in luck as now even they will be able to craft a BIOS to bypass the AMD PSP .

I'm gonna use that and see what he says.

 

[phaZed]

https://safefirmware.com/Whitepaper+Clarification.pdf

The only thing the attacker would need after the initial local compromise is local admin privileges and an affected machine. To clarify misunderstandings – there is no need for physical access, no digital signatures, no additional vulnerability to reflash an unsigned BIOS. Buy a computer from the store, run the exploits as admin – and they will work (on the affected models as described on the site).

RYZENFALL, FALLOUT - Requirements
Physical access is not required. An attacker would only need to be able to run an EXE with local admin privileges on the machine.
Impact:

• Write to SMM memory, leading to code execution in SMM.
• Reading and/or tampering with Credential Guard VTL-1 memory through the PSP.
• Ryzenfall-4, which achieves code execution inside the PSP, leads to all the attacker capabilities described above, as well as the capability to tamper with the PSP and its security features.
• An attacker can use RYZENFALL or FALLOUT to bypass Windows Credential Guard, steal network credentials, and then use these to move laterally through Windows-based enterprise networks.

MASTERKEY - Requirements:

• Physical access is not required. An attacker would only need to be able to run an EXE with local admin privileges on the machine.
• Wait for reboot.

Impact:

• The MASTERKEY set of vulnerabilities enable an attacker to execute unsigned code inside the PSP. Totaling a complete compromise of the Secure Processor. The exploit reflashes the BIOS to take advantage of the vulnerability: - On some motherboards – this works out of the box. This is because PSP firmware is often ignored by BIOS signature checks. - In other cases – RYZENFALL #1-2 or FALLOUT #1-#2 could be used as a prerequisite for MASTERKEY to achieve code execution in SMM and bypass BIOS signature checks made in SMM code.
• Even if all else fails, we believe using RYZENFALL-4 to write to SPI flash from inside the PSP is probably possible.

CHIMERA - Requirements:

• Physical access is not required. An attacker would only need to be able to run an EXE with local admin privileges on the machine.

Impact:

• The CHIMERA set of vulnerabilities are a set Manufacturer Backdoors left on the AMD Chipset, developed by Taiwanese company ASMedia.
• This allows for an attacker to inject malicious code into the chip and take over the chipset (Read/Write/Execute).
• One set of backdoors in implemented in firmware, while the other is implemented in the actual logic gates of the chip (ASIC). Both yield to the same impact.

 

[TechPJC]

https://www.howtogeek.com/346782/ho...asterkey-fallout-and-chimera-vulnerabilities/