Zombieload Saga - New Intel Architecture security flaws, worse than Spectre/Meltdown

[ravenshrike]

So apparently Intel tried to bribe the researchers who uncovered the flaw twice, first to the tune of 40k and doubling their offer the second time.

 

https://www.techpowerup.com/255563/intel-tried-to-bribe-dutch-university-to-suppress-knowledge-of-mds-vulnerability

 

https://www.nrc.nl/nieuws/2019/05/14/hackers-mikken-op-het-intel-hart-a3960208

 

A direct translation from anyone who knows danish would be awesome.

 

 

[mr moose]

4 hours ago, Captain Chaos said:

On one hand this sucks.  My system is around 4 years old now.  There were no decent AMD CPUs back then, so Haswell-E was the best option for me really.  If it weren't for having massive overclocking headroom, I'd probably be royally effed and looking into Ryzen right now.

 

On the other hand, how likely are we to see this in the wild?  So far there have been precisely zero reports of exploits that leverage the Spectre or Meltdown vulnerabilities, which is why quite a few people have disabled those patches to regain the lost performance. 

If history has anything to say, the mitigations for these exploits will likely have very minimal impact on home users anyway.   Then on top of that there is no guarantee if you did buy Ryzen (like I am now), that similar exploits won't be discovered in a few years.  

 

 

Tech is so complex now that it is safer to assume everything has holes and the only thing in between discovering them and patching them is an unknown length of time.

[Stroal]

5 minutes ago, ravenshrike said:

So apparently Intel tried to bribe the researchers who uncovered the flaw twice, first to the tune of 40k and doubling their offer the second time.

 

https://www.techpowerup.com/255563/intel-tried-to-bribe-dutch-university-to-suppress-knowledge-of-mds-vulnerability

 

https://www.nrc.nl/nieuws/2019/05/14/hackers-mikken-op-het-intel-hart-a3960208

 

A direct translation from anyone who knows danish would be awesome.

 

 

Intel has known about this since 2007, and ignored it.

[mr moose]

8 minutes ago, Stroal said:

Intel has known about this since 2007, and ignored it.

The whole existence of exploits in these aspects of speculative execution (and many surrounding issues) has been around since god knows when.  The problem is you don't stop production of a CPU architecture you've spent billions developing just because something thinks they can exploit it.  It took until 2016 to actually do it. and even then there were mitigations.  

[Curious Pineapple]

This now leaves me with 2 options. The first being disable HT (which is funny as all my older non-hyper threaded CPU's are vulnerable too and the Pentium 4 HT isn't) and have a slow ass machine, or the second is buy more DDR3 and put my FX machine back into use.

 

As I have a domain name pointed at my workstation with some forwarded ports, I need to do something.Yay Intel.

[Blademaster91]

11 minutes ago, ravenshrike said:

So apparently Intel tried to bribe the researchers who uncovered the flaw twice, first to the tune of 40k and doubling their offer the second time.

 

https://www.techpowerup.com/255563/intel-tried-to-bribe-dutch-university-to-suppress-knowledge-of-mds-vulnerability

 

https://www.nrc.nl/nieuws/2019/05/14/hackers-mikken-op-het-intel-hart-a3960208

 

A direct translation from anyone who knows danish would be awesome.

 

 

Seems rather clickbait to call a paid bug bounty program a "bribe". Though it does make sense from a security standpoint to withhold a vulnerability from making it public until a solution is found.

12 minutes ago, mr moose said:

If history has anything to say, the mitigations for these exploits will likely have very minimal impact on home users anyway.   Then on top of that there is no guarantee if you did buy Ryzen (like I am now), that similar exploits won't be discovered in a few years.  

 

 

Tech is so complex now that it is safer to assume everything has holes and the only thing in between discovering them and patching them is an unknown length of time.

The past few exploits were so overhyped yet didn't really affect most users, the HT exploit is concerning though idk what the chances are as long as the OS and browser are kept updated and a person just avoids shady websites.

[Kisai]

On 5/14/2019 at 1:13 PM, maartendc said:

This is more disconcerting:

 

https://support.apple.com/en-us/HT210107

 

Apparently this has already been patched in Mac OS 10.14.5 for Safari to prevent exploitation via Javascript through a malicious website.. The security flaw was already disclosed to Intel in September of 2018, which is why there already are fixes available.

 

You could still be vulnerable if you use unsigned software / harmful apps, this is what Apple has to say about this:

 

YIKES. I don't know if I WANT to "mitigate" this vulnerability now. Way to go Intel. Apparently Hyperthreading is completely UNSAFE now.

 

I am sure the repercussions are the same for Intel based Windows machines, since the CPU and Hyperthreading seem to be at the core of this vulnerability. Would apply for all OS.

 

Glad I got a Ryzen CPU for my Desktop now!

The problem is the way SMT works. SMT works by sharing the ALU's. It's simply impossible to migitate in a way that isn't effectively disabling hyperthreading or mucking with the scheduling to degrade the benefit of SMT.

 

Source, no idea but was linked from https://superuser.com/questions/122536/what-is-hyper-threading-and-how-does-it-work

 

So Intel Hyperthreading is F, while Intel non-Hyperthreading models is E

AMD's SMT isn't that different, but gamers are often told to turn it off.

 

There's a slide at the beginning of https://www.anandtech.com/show/11170/the-amd-zen-and-ryzen-7-review-a-deep-dive-on-1800x-1700x-and-1700/10 that explains how AMD's SMT works.

 

However we were previously told about PortSmash, which is another SMT related exploit back in late 2018 and that did affect AMD, however the software in question then (OpenSSL) was patched.

 

Realistically, corners that have been cut to give us HT/SMT, Shared caches, and such are coming back to bite everyone now. We should push the vendors to go back to D, which means more expensive CPU's. You gain 25-30% from SMT because the CPU isn't being used efficiently. But HT cuts the ALU's in half to begin with, so may actually gain performance in software that actually uses 4 physical non-HT cores rather than trying to treat all 8 logical cores the same. Open the process list on any application and you'll see a lot of software (like your web browser) using dozens of threads, and yet some how not really using more than one cpu core.  Co-routines are not threads. The web browsers do not muti-thread javascript. 

 

So something that runs on two logical cores can see what's in the other logical core, and can see what's in the L1 and L2 cache.

 

[Kisai]

On 5/15/2019 at 12:22 PM, bcredeur97 said:

we made a decision at work to disable hyper threading on everything. every user laptop/desktop, every server, etc.

Really sucks.... but security

That was probably overkill honestly.

 

Of all the exploits, Anyone with a Haswell class system or newer MUST update the BIOS to close the exploit. Good luck if you don't own a Dell, Apple, HP, or some other system that would be under warranty. My ASRock MB came out with a Beta BIOS update for the Z87 for Spectre/Meltdown, and then didn't do anything further. At this point I'd probably expect anyone with a Broadwell system or later should be yelling at ASRock/Asus/GigaByte/MSI/etc to update the BIOS's, since they should still be under warranty. Dell and HP will likely update their BIOS if they didn't already do it back in November, as I did notice quite a few "pointless updates" from Dell between November and March that seemed to just push the update date and not the version number.

 

If you are using your system for gaming, these exploits are probably entirely pointless and you shouldn't be worried about them unless a game has a built in scripting mechanism (eg a built in web browser, CEF, Node, NW.JS, etc) or is built entirely in HTML5 and connects to the internet for any reason (eg RPG Maker MV.) Like an entirely theoretical exploit could be crafted in javacript and packaged in a RPG Maker MV game.

 

Now if your systems are primarily office systems, then I'd update the BIOS if it's an option, laptops in particuar are better supported by OEM's. But turning Hyperthreading off in an office environment might not even be missed. Servers are another story, and I'd probably turn hyperthreading/SMT features off on any servers that face the internet or are used as terminal servers. If they don't connect to the internet at all, the risk is minimal.

 

 

[maartendc]

On 5/15/2019 at 10:27 AM, justpoet said:

Modern OSs can load microcode overrides prior to loading themselves, much like the bios/EFI can.  It isn't as guaranteed as bios/efi being updated, in case somebody booted to another OS, or you installed a fresh OS, but it is "good enough" for anybody that isn't doing this for a living to be covered, and to not need to know much about bios updates and the like.

 

11 hours ago, Kisai said:

That was probably overkill honestly.

 

Of all the exploits, Anyone with a Haswell class system or newer MUST update the BIOS to close the exploit. Good luck if you don't own a Dell, Apple, HP, or some other system that would be under warranty. My ASRock MB came out with a Beta BIOS update for the Z87 for Spectre/Meltdown, and then didn't do anything further. At this point I'd probably expect anyone with a Broadwell system or later should be yelling at ASRock/Asus/GigaByte/MSI/etc to update the BIOS's, since they should still be under warranty. Dell and HP will likely update their BIOS if they didn't already do it back in November, as I did notice quite a few "pointless updates" from Dell between November and March that seemed to just push the update date and not the version number.

 

If you are using your system for gaming, these exploits are probably entirely pointless and you shouldn't be worried about them unless a game has a built in scripting mechanism (eg a built in web browser, CEF, Node, NW.JS, etc) or is built entirely in HTML5 and connects to the internet for any reason (eg RPG Maker MV.) Like an entirely theoretical exploit could be crafted in javacript and packaged in a RPG Maker MV game.

 

Now if your systems are primarily office systems, then I'd update the BIOS if it's an option, laptops in particuar are better supported by OEM's. But turning Hyperthreading off in an office environment might not even be missed. Servers are another story, and I'd probably turn hyperthreading/SMT features off on any servers that face the internet or are used as terminal servers. If they don't connect to the internet at all, the risk is minimal.

 

 

As @justpoet said previously, OS's can load CPU microcode, so you don't necessarily need to update the BIOS to receive the new Intel Microcode, just keep your Windows Up to date and you will be patched as soon as Microsoft rolls out a Windows Update for it.

 

Then also according to JustPoet, these microcode updates are really just "workarounds" to exploiting the vulnerability, but not really a proper "resolution" of the vulnerability. That is impossible without redesigning the chip. The only way to really "mitigate / resolve" this issue, and future issues that are likely to be discovered, once and for all in older CPU's is to disable Hyperthreading permanently.

 

The performance impact of the Intel microcode updates is likely minimal. Disabling Hyperthreading entirely to be secured from any "unknown" / "Zero-day" hardware exploits is very large.

 

If I was dealing with sensitive / security stuff on an enterprise level, I would also take the drastic step of disabling Hyperthreading on all machines. These exploits have been fixed, but the way things are going, more hardware vulnerabilities in Hyperthreading are likely to pop up in the future!

 

For home users, disabling Hyperthreading is propably not necessary, because the known vulnerabilities will be fixed on a OS and/or BIOS level. If you are really paranoid about yet undiscovered vulnerabilities, only then should you disable HT.

[power666]

On 5/16/2019 at 4:17 PM, Stroal said:

Intel has known about this since 2007, and ignored it.

 

Did Intel know about this particular bug in 2007?  No.  Some of the MDS family of chips require hyper threading which Intel at the time has already abandoned with the Pentium 4 years prior.  I have not seen any mention that this could (or could not) be exploited on Netburst based designs.  Hyperthreading would not return until 2009, years after that post was made.

 

Has Intel known about various bugs an errata for a long time?  Yes.   Does Intel catch some of these before release?  Yes.  That is why TSX was disabled in consumer Haswell post release and on all Haswell-EP/EX parts.  Similarly errata is why Intel never shipped Optane DIMMs with SkyLake-SP.

Is Theo literally ROTFL right now because some of his predictions came true?  YES.  He has been advocating for the disabling of SMT/Hyperthreading for years now due to his perceptions of lax security.  

[Stefan Payne]

On 5/17/2019 at 7:07 AM, Kisai said:

The problem is the way SMT works. SMT works by sharing the ALU's. It's simply impossible to migitate in a way that isn't effectively disabling hyperthreading or mucking with the scheduling to degrade the benefit of SMT.

That is just not true.

You can put a bit or two on an instruction and tell them of wich Thread they come.

 

Or a different memory access strategy could also work.

 

[Kisai]

On 5/17/2019 at 9:46 AM, maartendc said:

 

As @justpoet said previously, OS's can load CPU microcode, so you don't necessarily need to update the BIOS to receive the new Intel Microcode, just keep your Windows Up to date and you will be patched as soon as Microsoft rolls out a Windows Update for it.

 

 

It's not the same effect. A BIOS updates the microcode permanently, where as the OS can only update a subset of the microcode, and is otherwise going to use an entirely software solution against that microcode.

 

https://downloadcenter.intel.com/download/28087/Linux-Processor-Microcode-Data-File

 

"Microcode is best loaded from the BIOS. Certain microcode must only be applied
from the BIOS. Such processor microcode updates are never packaged in this
package since they are not appropriate for OS distribution"

 

https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00233.html

 

https://support.microsoft.com/en-ca/help/4093836/summary-of-intel-microcode-updates

 

 

As I said, you MUST apply the BIOS update if you want the fix to be always-on. Software fixes can otherwise be turned off in the registry.

 

https://support.microsoft.com/en-us/help/4073119/protect-against-speculative-execution-side-channel-vulnerabilities-in

"We are providing the following registry information to enable mitigations that are not enabled by default, as documented in Security Advisories ADV180002 and ADV180012. Additionally, we are providing registry key settings for users who want to disable the mitigations that are related to CVE-2017-5715 and CVE-2017-5754 for Windows clients."

 

Use the powershell script at the bottom. You get something like this if the firmware migitation for Meltdown is installed. This is the Asrock z87 Motherboard with the 3.50 beta firmware (eg with the meltdown MCU).

Hardware is vulnerable to L1 terminal fault: True
Windows OS support for L1 terminal fault mitigation is present: True
Windows OS support for L1 terminal fault mitigation is enabled: True


BTIHardwarePresent                  : True
BTIWindowsSupportPresent            : True
BTIWindowsSupportEnabled            : True
BTIDisabledBySystemPolicy           : False
BTIDisabledByNoHardwareSupport      : False
BTIKernelRetpolineEnabled           : False
BTIKernelImportOptimizationEnabled  : False
KVAShadowRequired                   : True
KVAShadowWindowsSupportPresent      : True
KVAShadowWindowsSupportEnabled      : True
KVAShadowPcidEnabled                : True
SSBDWindowsSupportPresent           : True
SSBDHardwareVulnerable              : True
SSBDHardwarePresent                 : False
SSBDWindowsSupportEnabledSystemWide : False
L1TFHardwareVulnerable              : True
L1TFWindowsSupportPresent           : True
L1TFWindowsSupportEnabled           : True
L1TFInvalidPteBit                   : 45
L1DFlushSupported                   : False

Microsoft and Intel know that the third party MB vendors are going to drag their heels and not release updates for everything impacted again. They are also the ones that will not be turning off these features in software.