CPU Security Flaws MELTDOWN and SPECTRE

The side commentary in the Ars article from a security expert indicates that--besides the apparent stock manipulation--there is a baseline of truth to the exploits, which generally are not good for AMD's contention that the PSP can be trusted. Among them, there's the assertion is that the PSP's signature verification can be bypassed, there are few safeguards within it, and elements like the SOC's southbridge have broad access once they're exploited. The latter case is something where the third-party vendor is a known security risk that AMD apparently was not able to isolate.

If this proves true and difficult to remedy, it does undermine part of EPYC's security feature set related to safeguarding against broken hosts, and may raise doubts about the trustworthiness of systems that may have gone through intermediaries before getting to the customer. These aren't new threat scenarios for the PSP or Intel's Management Engine, but this might be evidence that they've gone beyond theory crafting and are now exploitable.
 
3dilettante said:
The side commentary in the Ars article from a security expert indicates that--besides the apparent stock manipulation--there is a baseline of truth to the exploits, which generally are not good for AMD's contention that the PSP can be trusted. Among them, there's the assertion is that the PSP's signature verification can be bypassed, there are few safeguards within it, and elements like the SOC's southbridge have broad access once they're exploited. The latter case is something where the third-party vendor is a known security risk that AMD apparently was not able to isolate.

If this proves true and difficult to remedy, it does undermine part of EPYC's security feature set related to safeguarding against broken hosts, and may raise doubts about the trustworthiness of systems that may have gone through intermediaries before getting to the customer. These aren't new threat scenarios for the PSP or Intel's Management Engine, but this might be evidence that they've gone beyond theory crafting and are now exploitable.
Click to expand...
Then again, is there any system out there that wouldn't be vulnerable when you have admin level access to a machine with the ability flash BIOS with malicious custom BIOS etc? Since that's what these apparently require.
 
Kaotik said:
Then again, is there any system out there that wouldn't be vulnerable when you have admin level access to a machine with the ability flash BIOS with malicious custom BIOS etc? Since that's what these apparently require.
Click to expand...
That's for one of the vulnerabilities, and not required for others.
The PSP provides an avenue for persistence, even if a hostile actor only has a brief interaction with the system. The indications from those saying they reviewed the proofs of concept is that physical reflashing isn't necessary, as remote update packages are an option.
AMD's marketing for SEV includes how it protects against a compromised hypervisor, but if the hypervisor and host system can root the PSP, that functionality can be overridden.

The PSP's critical place in the infrastructure is undermined by what appears to be a lower bar for exploit, and multiple significant vulnerabilities existing right alongside it allowing access to areas that shouldn't be accessible at all. Given its role and broken signature validation, it may mean some of the really private platform key values might be extractable.
 
Esrever said:
How did this guy get to test this last week when AMD only got a 24 hour notice?
Click to expand...
The goal was apparently to blindside AMD. I've seen some tweets like from Anandtech note that they think they've had more warning than AMD.
It's significantly more effective, however, if the claims cannot be blown off as purely fabrications. That some names attached to more established companies are vouching that they've seen working proof of concept exploits is likely why they were given advanced access.
 
And if AMD were blind-sided, that means none of these journalists contacted them with the information either. Which means either they were under NDA from the source company to ensure maximum drama exposure on the date of "reveal" and/or their so called integrity was highly lacking and looking at headlines only.
 
Malo said:
And if AMD were blind-sided, that means none of these journalists contacted them with the information either. Which means either they were under NDA from the source company to ensure maximum drama exposure on the date of "reveal" and/or their so called integrity was highly lacking and looking at headlines only.
Click to expand...

It means that malicious actors could have gotten their hands on the exploits and them for attacks. That’s exactly the opposite of what a legitimate security company would do.

This a digital equivalent of a food safety lab doing unsolicited tests of produce at a supermarket until they find signs of contamination, waiting several weeks and then making a manic announcement aimed at causing panic.
 
Kaotik said:
Then again, is there any system out there that wouldn't be vulnerable when you have admin level access to a machine with the ability flash BIOS with malicious custom BIOS etc? Since that's what these apparently require.
Click to expand...

Indeed, this whole thing is extremely overblown. Once you have admin access the whole system is open to you already anyway. The claims made against AMD go against pretty much every piece of hardware.
 
Here is a pretty good balanced piece on the latest situation and the claims against the AMD security flaws : http://www.theregister.co.uk/2018/03/13/amd_flaws_analysis/?page=1
It does look like there are a set of security weaknesses that need a closer look, but it is very clear the narrative was done in a way to short AMD stock - that point was admitted by the "Viceroy Research" group that stated the stock was worth 0 cents and somehow managed to deliver the report within a couple of hours of the initial security "announcement", seems some convenient co-ordination there.
My concern is potentially a state sponsored hacking rather than lower level activities, which is also what the article thinks is probably the most likely risk from this if at all possible, but yeah more details are required.

That said my favourite piece of the article is where they quote Linus Torvalds and he says "At what point will security people admit they have an attention-whoring problem?"
Quite amusing coming from him :)
 
Last edited:
tongue_of_colicab said:
Indeed, this whole thing is extremely overblown. Once you have admin access the whole system is open to you already anyway. The claims made against AMD go against pretty much every piece of hardware.
Click to expand...

The persistence of exploits in a hardware enclave that cannot be scanned by the OS allows for some more complex attacks. Those are rarer, and Intel and ARM products have had security problems like this.
Once brought up within a datacenter, a physical host might never be accessible without getting past the network and physical countermeasures of the target machine, and when it's not running cloud workloads there's nothing for the rogue admin to extract.
Compromising the enclave means the attacker just needs to get to the board at some time in its existence prior to bringup. It's whoever could touch the board or system from the component manufacturers, system assembly, storage, transport, retail, plugging it into the rack, etc.
The security experts that are saying they saw the proof of concept code in action may be an extra data point. If they had the chance to run them on their own EPYC or Ryzen hardware.
For a security platform, one would hope AMD hasn't pulled a Sony and that it might be possible for millions chips out in the wild to carry some common key values.

There are likely ways to help mitigate this like controlling access to firmware-carrying components for data centers or more in-depth evaluation or mandatory reflashing with known-good code (if you trust that), though AMD's security sales pitch is hobbled because part of its extended feature set was supposed to protect against admins that neglected to do this or actively sought to break client encryption.
 
3dilettante said:
The security experts that are saying they saw the proof of concept code in action may be an extra data point. If they had the chance to run them on their own EPYC or Ryzen hardware.
For a security platform, one would hope AMD hasn't pulled a Sony and that it might be possible for millions chips out in the wild to carry some common key values.
Click to expand...
The security experts that are being paid by the company that released the "attacks" with no supplied POC, at this stage there has been no 3rd party independent verification of anything.
 
itsmydamnation said:
The security experts that are being paid by the company that released the "attacks" with no supplied POC, at this stage there has been no 3rd party independent verification of anything.
Click to expand...

I'm discussing the security experts contacted by reports like the one linked earlier on Arstechnica. These are named experts with official capacities at established groups, which means there's more cost to perpetuating a hoax. They've disavowed having connections with the group that announced the exploits, and do not condone the way the information is being used. However, they say they believe the expertise and proofs of concept being seeded are real.

It may not translate into widespread exploit, but as a firmware/hardware issue it leaves imperfect mitigation for existing hardware. AMD's own secure boot and encryption methods were supposed to give it a security value-add by reducing the ability of compromised or negligent hosts scraping data from VM clients. If the vulnerabilities are substantiated by AMD's review, it's problematic if their measures for safeguarding against the host depend on the host to apply updates. This is similar to the catch with Intel's SGX being compromised by Spectre, where SGX is supposed to protect from OS and hypervisor interference but cannot do so if said host does not apply the microcode fix that blocks speculation in and out of the protected region.
 
Except from what I've read so far its not a hardware exploit. You need root/admin access to load malicious drivers/bios. At that point pretty much every device is vulnerable.
 
3dilettante said:
That's for one of the vulnerabilities, and not required for others.
The PSP provides an avenue for persistence, even if a hostile actor only has a brief interaction with the system. The indications from those saying they reviewed the proofs of concept is that physical reflashing isn't necessary, as remote update packages are an option.
AMD's marketing for SEV includes how it protects against a compromised hypervisor, but if the hypervisor and host system can root the PSP, that functionality can be overridden.

The PSP's critical place in the infrastructure is undermined by what appears to be a lower bar for exploit, and multiple significant vulnerabilities existing right alongside it allowing access to areas that shouldn't be accessible at all. Given its role and broken signature validation, it may mean some of the really private platform key values might be extractable.
Click to expand...
PSP related "Ryzenfall" requires admin level access and vendor-signed malicious driver
Fallout requires admin level access and vendor-signed malicious driver
Chimera requires admin level access and vendor-signed malicious driver (also they claim that because some asmedia controllers have "bad firmware and software" (according to CTS Labs anyway), Promontory clearly has them too)
 
How is one supposed to get hold of a vendor cryptographic key to sign one's malicious driver with...?

Seems a very remote possibility to make these hacks work if this is how they work. Also, pretty much impossible to defend against, because if you have both signed malware and root access...what could possibly stop you???
 
Kaotik said:
PSP related "Ryzenfall" requires admin level access and vendor-signed malicious driver
Fallout requires admin level access and vendor-signed malicious driver
Chimera requires admin level access and vendor-signed malicious driver (also they claim that because some asmedia controllers have "bad firmware and software" (according to CTS Labs anyway), Promontory clearly has them too)
Click to expand...

Well most security analysts who are talking about this only mention admin/root level access as the sticking point (a big one), although they all say more information/testing is required and fair to say everyone will agree pretty clear the initial narrative/release was designed to short AMD stock.
As one Infosec example;
https://doublepulsar.com/on-amd-flaws-from-cts-labs-f167ea00e4e8
Point is you go through or even bypass the signed driver, but still it requires root access and more likely to be a state sponsored hacking group/activity and therefore rather niche albeit still a concern to be evaluated and resolved.

In theregister article I linked earlier:
Jake Williams told The Register that the lack of details in the report made gauging the impact of the vulnerabilities difficult, but the flaws could be a major issue - depending on who you think is likely to go after your networks.

"If nation state attackers top your threat model, then yeah this is bad. The vulnerabilities will allow attackers to bypass Trusted Boot (allowing them to bypass device driver signing and other rootkit mitigations) and Credential Guard (allowing them to bypass Windows 10 credential hardening mitigations)," he explained.

"The most concerning are the two chipset vulnerabilities. These have the potential to more widely exploited. The hardware vulnerability that involves direct memory access (DMA) is particularly concerning since it will difficult to impossible to patch through software.
Click to expand...

Separately IMO these need to differentiate between Ryzen and EPYC, personally I feel it is less of an issue for AMD if Ryzen has more weakness than EPYC although that would split opinion of many who look at it from a consumer retail perspective.
 
Last edited:
CSI PC said:
Well most security analysts who are talking about this only mention admin/root level access as the sticking point (a big one), although they all say more information/testing is required and fair to say everyone will agree pretty clear the initial narrative/release was designed to short AMD stock.
As one Infosec example;
https://doublepulsar.com/on-amd-flaws-from-cts-labs-f167ea00e4e8
Point is you go through or even bypass the signed driver, but still it requires root access and more likely to be a state sponsored hacking group/activity.

In theregister article I linked earlier:
Separately IMO these need to differentiate between Ryzen and EPYC, personally I feel it is less of an issue for AMD if Ryzen has more weakness than EPYC although that would split many who look at it from a consumer retail perspective.
Click to expand...
Even the nation backed hackers need to get admin priviliges on the system(s) to exploint any of these. Also, if you could bypass Trusted Boot to skip driver signing requirement, why is it specifically mention in every single claimed exploit?

And like already stated - you're already compromised if the attacker gets admin privileges on your system - no matter what system you're running. And none of these "vulnerabilities" help you get that, as they all require you to have it already.
 
Kaotik said:
Even the nation backed hackers need to get admin priviliges on the system(s) to exploint any of these. Also, if you could bypass Trusted Boot to skip driver signing requirement, why is it specifically mention in every single claimed exploit?

And like already stated - you're already compromised if the attacker gets admin privileges on your system - no matter what system you're running. And none of these "vulnerabilities" help you get that, as they all require you to have it already.
Click to expand...
Check InfoSec reports on this, the only sticking point until more is known is admin/root level access; I gave two different InfoSec guys views already and I could had linked/quoted more.
I am not disagreeing about the level/scale of attack required, just responding to the perspective of one is secure due to signed drivers, which is not really true due to the level of access gained and the bypass/hidden mechanism.
However it is still potentially a notable infosec concern that needs further investigation/resolution as it cannot be left for the various types of datacenters and HPC implementations; to reiterate though this would normally be done in a way for AMD and security community to try and get ahead of this issue rather than create the narrative and situation to short AMD stock, but it is still there.

The secondary attacks around the chipset vuln is a broader issue with different factors, but then it does not affect EPYC (I think).
 
Last edited:
You must log in or register to reply here.
Back
Top