CPU Security Flaws MELTDOWN and SPECTRE

Techpowerup has an additional Q&A concerning the alleged exploits.
https://www.techpowerup.com/242386/cts-labs-responds-to-a-techpowerup-technical-questionnaire

This seems to clarify that persistence is generally related to the off-chip flash memory used by the PSP to store the alterable portions of its firmware and software. That may mean a fresh motherboard could be the upper end of what is needed to be sure a BIOS compromise is avoided, if there's uncertainty about whether a compromised PSP could somehow interfere with an attempt to rewrite the flash.
I would think even then there could be some in-CPU fuses or similar structures to that could be wrecked by an attack program.

The first section on the BIOS exploit points to AMD's firmware signature check authenticating at an early point, and that authentication either covers a subset of the code the PSP loads or somehow the initial check's result somehow applies to a broader range of code that can include hostile code. The description, if accurate, indicates the PSP checks the beginning of its firmware and the exploit occurs in the next step where secondary modules are loaded. I would expect those to be signed as well, so perhaps a bug in their checks, a missing bounds check, or time window for replacing part of their payload after the signature check is what allows unsigned code to get in.

The ideal outcome AMD's general description of its secure platform describes is that tampering with the main firmware or the PSP's modules is that the PSP would halt the process and the CPU would not exit the mostly halted startup state.

The other exploit that requires a signed driver doesn't need the driver itself to be modified by a hostile actor and signed with a vendor's key. The signed driver's importance is that it is granted IO space access by the OS, and then can be manipulated into triggering back doors in the ASMedia hardware/firmware. I had thought AMD's own IOMMU and PSP served to create a thicker layer of isolation, or could if the SOC's programmable elements are tweaked to use their ability to intercept or redirect accesses to the backdoor. I would have thought existing IO virtual management would limit what the hacked DMA unit could look at.

The researchers feigned surprise that AMD hasn't responded to them in a few days, citing that another lab got back to them in a shorter time. This seems disingenuous. An outside lab doesn't need to be that thorough and doesn't have the legal concerns, obligations, and responsibilities that AMD would have.
 
What are the laws regarding an Israeli company in this context?
If they investigate it as insider dealing with manipulation then it is the individuals rather than the company, same thing happened with those manipulating currency rates some years back although they did fine the companies as well I think but the individuals involved went to jail.
 
If they investigate it as insider dealing with manipulation then it is the individuals rather than the company, same thing happened with those manipulating currency rates some years back although they did fine the companies as well I think but the individuals involved went to jail.
I'm wondering more about US-Israeli law and being able to prosecute/extradite.
 
Seriously though, any possible credibility comes down to the fact that they claim 16 years of industry experience yet claim this is their first rodeo and they "didn't know you shouldnt release this stuff right away", topping to the cake is the claim that Israeli laws probhited releasing the code bs
 
I'm wondering more about US-Israeli law and being able to prosecute/extradite.
There is an extradition agreement between US and Israel along with a mechanism on how the accused would serve their time usually in Israel, but politics also come into this and can influence such requests being accepted.
That said I did a quick search and a fraud case back in 2012 all of those involved based in Israel were extradited to the US, but the agreement has a lot of leeway and loopholes for Israel and another time US caught their person when they were travelling to a different country (he defrauded the DoD) and sounds like politics involved in that one.
 
Does anyone know if any more intel processors than those already released so far will get microcode patches, or is haswell where the buck stops?

I've got a Sandybridge mac and a Nehalem PC, and while they don't see much use either of them these days, it'd be good if they were as secure as they could be... :p
 
Does anyone know if any more intel processors than those already released so far will get microcode patches, or is haswell where the buck stops?

I've got a Sandybridge mac and a Nehalem PC, and while they don't see much use either of them these days, it'd be good if they were as secure as they could be... :p
Sandy Bridge and newer get the microcode updates, and they have all been released already by Intel
Now it's just about motherboard manufacturers and other partners to distribute them. ASUS reportedly won't give BIOS updates to anything older than Haswell (X99), dunno about the rest.
MS is currently distributing the patches for Skylake & up, so I'd expect they'll distribute it to older CPUs too in near future.
 
Various reports have relayed AMD's initial response to the CTS exploits:
https://community.amd.com/community...amd-technical-assessment-of-cts-labs-research

Corroborating opinions of those that have reviewed the technical details--that there are hacks on the PSP and Asmedia chipset with specific preconditions like administrator access and a signed driver with IO memory access--are true.
The level of compromise from having admin access and the complex and specific tools and code are what AMD states makes these extremely difficult to pull off.

AMD cites the Trail of Bits update on their review as to the particulars of the exploits.
https://blog.trailofbits.com/2018/03/15/amd-flaws-technical-summary/

AMD's planned resolution is BIOS updates in a matter of weeks, as well as some kind of cooperation with the chipset vendor, contradicting the statements in the announcements concerning an extremely long time to never for a fix.
The expectation is that performance shouldn't be affected, which goes to the idea that the PSP is supposed to be used relatively rarely and not for something in a performance critical path.

There does seem to be the presumption by AMD that this is not being exploited in the wild.
It's not clear if these updates can occur for an firmware-exploited system, as Trail of Bits states one possible threat is ongoing blocking or infection of future BIOS updates.
On another possible nitpick, AMD cites the need for a malicious driver, while CTS claimed it merely needed a suitable third-party vendor's driver that could be duped into exposing internal exploits.

Fixing whatever caused the PSP to not detect compromised firmware or exploits in its API would be a firmware fix to the PSP's OS or modules.
The Chimera exploit is a mix of AMD and chipset vendor fix, though AMD also states a BIOS fix is incoming in a less-certain time period than the PSP fixes. Perhaps the BIOS fix is a mix of firmware and driver changes that remove hidden chipset software functions and/or intercept writes that can hit the alleged hardware backdoor.

Perhaps later steppings could wire off any potential hardware exploit in lieu of continual firmware monitoring, or a new chipset in future products will not have this vulnerability.
 
Last edited:
AMD's planned resolution is BIOS updates in a matter of weeks, as well as some kind of cooperation with the chipset vendor, contradicting the statements in the announcements concerning an extremely long time to never for a fix.
The expectation is that performance shouldn't be affected, which goes to the idea that the PSP is supposed to be used relatively rarely and not for something in a performance critical path.
Will definitely be interesting to see the amount of time taken before fixes are out, as well as whether any noted performance deltas are noted by reviewers ...
 
I don't see that it would cause notable performance issues, its (presumably) just some extra security checks on the secure processor/firmware, its not like its disabling speculation & force flushing the stack every few (hundred?) cycles.
 
Intel quietly updated its microcode update guidance (PDF) on 2nd April. The last time we checked this document, back in mid-March, it was good news and Intel simultaneously revealed via a blog post that it had updated the microcode for all of the products it had launched in the past five years. The latest update to the PDF isn't very good news, as if you check through the document you will see that many processors/chipsets have been shifted to a new production status labelled 'stopped'.


b60c8a89-9813-4682-b8b5-ea1ecf45f07f.png

http://hexus.net/tech/news/cpu/116885-intel-halts-microcode-patch-development-230-cpus/
 
Latest Win10 includes IBPB for some AMD CPUs
https://support.microsoft.com/en-us/help/4093112/windows-10-update-kb4093112
Provides support to control usage of Indirect Branch Prediction Barrier (IBPB) within some AMD processors (CPUs) for mitigating CVE-2017-5715, Spectre Variant 2 when switching from user context to kernel context (See AMD Architecture Guidelines around Indirect Branch Control and AMD Security Updates for more details). Follow instructions outlined in KB4073119 for Windows Client (IT Pro) guidance to enable usage of IBPB withinsome AMD processors (CPUs) for mitigating Spectre Variant 2 when switching from user context to kernel context.
I forget, that was the lesser evil fix right?
 
Latest Win10 includes IBPB for some AMD CPUs
https://support.microsoft.com/en-us/help/4093112/windows-10-update-kb4093112

I forget, that was the lesser evil fix right?
That's the one that hurt performance on Intel (along with Meltdown), Spectre 1 has been OS-patched on everything AFAIK already.
If I remember correctly, AMD said they're not expecting performance hit and at least the microcode-patch to fix it would be optional for those who want it since AMD treats (or treated at least) Spectre 2 as theoretical threat more than anything else (no POCs available)
 
Maybe I should be thinking of getting my CPU microcode patched... Last I checked, ASUS hadn't posted any UEFI updates, but that was a good while ago now.

Fucking hackers, eh. This is why we can't have nice things, and so on... :???:
 
Back
Top