CPU Vulnerabilities, Meltdown and Spectre, Kernel Page Table Isolation Patches, and more

good post. and 'profit' is substitutable for 'performance'. Remember how the Intel CEO sold off his stock , all but the min required to be CEO, 1 week b4 Project Zero's POC was made public?

Interesting. Big picture, yet another angle -pissed off employee wants to upset his boss, read the Amsterdam POC & go for it. But selfishly I couldn't help but wonder, is oldschool AHCI mode a safer alt. for those who can still use it?

From Article above, ""Some of the data will always be the same, and other data will change. We see what occurs most often, and this is the data we’re interested in. It’s basic statistics." Scary!

"We have signed it away...", meaning our Govts.? I agree w/ you Prema on most points, but don't stop the good fight, you know? Its not easy, but there is still some semblance of Privacy today, if one works at it, no? (#eff) Peace!

 

Actually it wasn't 1 week. He setup his 10b5-1 trading plan at the beginning of October of 2017. The sell went through after the release of the HEDT High Core Count CPUs (14-18 core). Also, Coffee Lake, which had the vulnerability, was seemingly pushed up until then and had low availability until after the vulnerability became public in the first days of 2018. Meanwhile, Intel received word of the vulnerability in June of 2017, which considering it required a redesign to fix it, and that was known by September of 2017, there is no way he was not briefed and did not know about the vulnerability. That makes a strong argument for insider trading. But, after the announcement, within a couple days, the couple dollar loss bounced back, meaning you have to argue damages on it.

It's more that governments allow consumers to sign away their privacy rights is how I took that part. So it is the person on FB or other data mining sites that have stripped people of privacy.

Moreover, I don't find those arguments convincing. I personally feel, even though if a person has enough gumption they will get to the data regardless, that you shouldn't make it easy for them.

Considering the plethora of vulnerabilities that have come out in the past 2 years, and the uptick in the number of attacks companies receive daily, I would say that Intel has a serious security issue.

The datacenter market was set to have a downturn in purchases. These vulnerabilities, with the patches implemented, reduced processing power, resulting in the need to scale out their server implementations, which caused the datacenter demand to increase rather than decrease (to make up for the lost processing power), a likely contributor to Intel's fabrication shortage.

 

The Performance Impact Of MDS / Zombieload Plus The Overall Cost Now Of Spectre/Meltdown/L1TF/MDS
by Michael Larabel in Software on 18 May 2019. 28 Comments
https://www.phoronix.com/scan.php?page=article&item=mds-zombieload-mit&num=1

"The past few days I've begun exploring the performance implications of the new Microarchitectural Data Sampling "MDS" vulnerabilities now known more commonly as Zombieload. As I shared in some initial results, there is a real performance hit to these mitigations. In this article are more MDS / Zombieload mitigation benchmarks on multiple systems as well as comparing the overall performance impact of the Meltdown / Spectre / Foreshadow / Zombieload mitigations on various Intel CPUs and also AMD CPUs where relevant.

While disabling Hyper Threading now is recommended by multiple parties if running untrusted code on the system, even if keeping HT/SMT active, the MDS mitigations do provide a very noticeable performance hit in many real and synthetic workloads with the updated Linux kernel patches paired with the newest Intel CPU microcode. Like the other mitigations to this point, the workloads affected most are those with lots of context switches / high interactivity between kernel and user-space.

Before getting to the benchmarks looking at the overall impact of the mitigations to date, first is looking at the MDS on/off costs on various systems while keeping Hyper Threading active. These tests were done on Ubuntu 19.04 using its newest stable release updates bringing a patched Linux 5.0 kernel and the new Intel CPU microcode images.

I tested the MDS on/off tests with a few distinctly different systems for seeing the mitigation cost for Zombieload. Following this batch of tests is a larger set of tests looking at no mitigations for the CPU vulnerabilities, the default mitigations, and then the default mitigations with Hyper Threading disabled. All of these benchmarks were carried out using the Phoronix Test Suite."

There are lots of graphs and supporting information (10 pages), please check out the results of his extensive testing at the URL above...

"If looking at the geometric mean for the tests run today, the Intel systems all saw about 16% lower performance out-of-the-box now with these default mitigations and obviously even lower if disabling Hyper Threading for maximum security. The two AMD systems tested saw a 3% performance hit with the default mitigations. While there are minor differences between the systems to consider, the mitigation impact is enough to draw the Core i7 8700K much closer to the Ryzen 7 2700X and the Core i9 7980XE to the Threadripper 2990WX.

More Linux mitigation benchmarks are coming up on Phoronix in the days ahead."

28 Comments

Gaming Performance Only Faintly Touched By MDS / Zombie Load Mitigations
by Michael Larabel in Linux Gaming on 17 May 2019 at 01:31 PM EDT. 14 Comments
https://www.phoronix.com/scan.php?page=news_item&px=Zombie-Load-Gaming-Impact

"Yesterday I published some initial MDS/Zombieload mitigation impact benchmarks while coming out still later today is much more data looking at the CPU/system performance impact... But is the gaming performance impaired by this latest set of CPU side-channel vulnerabilities?

With the Spectre/Meltdown mitigations, the gaming performance fortunately wasn't impaired by those mitigations. In fact, it was pretty much dead flat.

With my testing thus far of the MDS/Zombieload mitigations on Linux, there does appear to be a slight difference in the rather CPU-bound scenarios compared to Spectre/Meltdown, but still it should be negligible for gamers. Well, that is at least with the higher-end hardware tested thus far, over the weekend I'll be running some gaming tests on some low-end processors/GPUs.

From the tests ran so far with the high-end parts, having the MDS mitigations active only would cause a frame or few hit in the rather CPU-bound scenarios. In those cases already, the games tend to run well over one hundred frames per second so would likely not be noticeable at all to gamers.

...check out the website for results...

So maybe a ~1% hit for some Linux games (if that in some configurations) as a result of the new default MDS mitigations and stopping short of disabling Hyper Threading, but even there most Linux games at least don't use more than a few cores/threads. But as said, will have some low-end Linux gaming hardware tests out in the days ahead.

More of the CPU/system benchmarks that are much more interesting in the context of these mitigations will be out shortly where it seems to be commonly 4~5% but more significant in the context switching heavy workloads."

14 Comments

xfcemint
Junior Member Join Date: May 2019 Posts: 38
#3 05-17-2019, 03:14 PM
"I think the article should have made it more clear that this is with HT on.

To really mitigate ZombieLoad, you need HT off.

Although I speculate that for games, in most cases there will be little difference. But, for the sake of clarity and to provide non-confusing data, you always have to do a run with HT off, and to clearly note it in the article.

Well, in fact, it is also going to depend on number of CPU cores. If a game needs more than 2 cores, and the CPU cannot provide them, there might be some performance hits."

 

Don't worry guys: I am still "fighting the good fight" as it is everyones duty.
I have just stopped giving it more attention than it deserves.

Sometimes catching a wave at the beach is simply so much more fulfilling...

 

[Intel]
Engineering New Protections Into Hardware
https://www.intel.com/content/www/u...ngineering-new-protections-into-hardware.html

Overview
"In 2018, the class of speculative execution side channel vulnerabilities, commonly referred to as Spectre and Meltdown, presented a unique challenge to Intel and the entire industry.

Intel provided microcode updates (MCU) supporting nearly 10 years of Intel® products, which were coupled with updates from our partners to help protect against these vulnerabilities.

We have also taken steps to integrate these protections into our hardware.

Side Channel Mitigation by Product CPU Model
The table below provides details on how the protections are integrated into Intel® products:

[The table is very short, but the data columns are too wide to see, snapshot, and replicate here, please follow the link above to view the list and see what your CPU / Stepping has.]


Frequently Asked Questions
Q1. Are there any differences in the level of protection provided by software mitigated and hardware mitigated versions of these SKUs?

A: No. We expect that the level of protection equivalent whether you have microcode update (MCU) based or hardware-based mitigations in place. The hardware-based mitigations are part of our ongoing commitment to advance security at the silicon level.

Q2. Are there any differences in performance between software mitigated and hardware mitigated versions of these SKUs?

A: For application based workloads, representative of typical usage, such as SYSmark* 2014 SE, PCMark10, WebXPRT 2015, and 3DMark Skydiver Physics the data confirms that the performance between steppings is the same within the normal run to run variation. For some synthetic I/O workloads, we have observed a performance difference between steppings. These synthetic I/O workloads are not representative of mainstream usage.

Q3: How do I determine what I have and how side channel vulnerabilities are mitigated?

A: From the Microsoft Windows Command prompt run “wmic cpu get caption”. Use the result to cross reference the table below.

Q4. What does the “CPU Caption” tell me and how does it map to product SKU?

A: The product caption gives information of what product model and silicon stepping you have. You can see for example on Model 142, as we moved from Stepping 11 to Stepping 12 we integrated hardware mitigations for Variant 2 and L1TF. To determine which products models and stepping maps to what SKU, see the table below.

Another table to view on the site...
AFAIK these new in hardware mitigations only include microcode patch updates burned onto the chip - a stepping change, no other architectural changes have been implemented.

OS patches appropriate for the mitigations are still required, there is no advantage to having the [inactivated] microcode updated on the CPU without the matching OS patch(es).

Intel has not done much in the way of hardware mitigations yet considering it's been going on 2 years since the vulnerabilities were first given to Intel. It's possible that if Intel began dusting off new architecture designs mothballed from before the 4 core ad infinitum dark age, Intel might be able to deliver new CPU architectural designs in the next 12-18 months. Practically speaking, one full generation of release cycle away.

A Look At The MDS Cost On Xeon, EPYC & Xeon Total Impact Of Affected CPU Vulnerabilities
Written by Michael Larabel in Software on 20 May 2019.
https://www.phoronix.com/scan.php?page=article&item=intel-mds-xeon&num=1

"This weekend I posted a number of benchmarks looking at the performance impact of the new MDS/Zombieload vulnerabilities that also included a look at the overall cost of Spectre / Meltdown / L1TF / MDS on Intel desktop CPUs and AMD CPUs (Spectre).

In this article are similar benchmarks but turning the attention now to Intel Xeon hardware and also comparing those total mitigation costs against AMD EPYC with its Spectre mitigations.

This article offers a look at the MDS/Zombieload mitigations on a 1st Gen Skylake Xeon Scalable server as well as a Kabylake Xeon E3 server for reference. Following that is a look at the total CPU vulnerability mitigation costs for 1st Gen Xeon Scalable, 2nd Gen Xeon Scalable (Cascade Lake), and an AMD EPYC 2P server as well for its Spectre mitigations.

As expected given Intel's guidance last week of their latest Xeon processors being mitigated for MDS, indeed, the dual Xeon Platinum 8280 Cascade Lake server reported it was not affected by the MDS mitigations and thus not enabled. So for the MDS tests up first it's just some reference results using a dual Xeon Gold 6138 Skylake server running Ubuntu 19.04 with the Linux 5.0 patched kernel and reference results side-by-side for a separate Xeon E3-1275 v6 server.

All of these mitigation benchmarks were driven in a fully-automated and reproducible manner using the Phoronix Test Suite.

[...lots of benchmark results, please see site at URL above...]

If looking at the geometric mean of all the benchmarks carried out, the EPYC 7601 averages out to about a 1% hit with its Spectre mitigations.

The dual Xeon Platinum 8280 Cascadelake setup with its mostly hardware-based mitigations was slower by 4% with the relevant mitigations enabled.

(l1tf: Not affected + mds: Not affected + meltdown: Not affected + spec_store_bypass: Mitigation of SSB disabled via prctl and seccomp + spectre_v1: Mitigation of __user pointer sanitization + spectre_v2: Mitigation of Enhanced IBRS IBPB: conditional RSB filling).

Meanwhile the dual Xeon Gold 6138 server that unfortunately doesn't have the hardware mitigations saw a 11% hit from the benchmarks run with these Spectre / Meltdown / L1TF / MDS mitigations or 15% if disabling Hyper Threading as an additional measure based on the benchmarks carried out today."

Looking forward to a wider range of testing, as this doesn't seem representative of DC work in general. Reports of 20%-40% performance hits from what workloads? I guess we'll have to be patient to find out.

Checkout J's video about disabling HT, J used the 8700k for testing but comes to the conclusion that HT isn't that important for gaming, and suggests saving $ and getting the 9xxxKF => CPU's without HT, when building new PC's.

Now it makes sense why Intel came out with a whole line of HT-less CPU's, they are more secure without HT in current architecture. Might as well save the silicon real estate, power, thermals, (and $?) and get HT-less to start.

Is Hyper-Threading Even Necessary? ZombieLoad Impact Testing (8700k)
JayzTwoCents
Published on May 20, 2019
http://forum.notebookreview.com/thr...ke-z370-and-z390.809268/page-42#post-10913286

 

Did you notice degraded performance in your organization after patching?

 

What is interesting about all this...

I haven't read of anyone actually being affected by these vulnerabilities and the way to exploit them are so convoluted. Anyone know of anyone that has actually been affected, consumer or enterprise?

Also HT is not needed for most tasks and actually makes zero difference in performance. Only apps that support high thread are affected, and even then it's about 10% only.

Again, I have yet to read anyone affected by this other than Apple making a big deal out of it. Hilarious considering Apple has far more to worry about than this vulnerability, like their devices appear to be designed by interns or intentionally designed to fail.

 

That's right, I don't think I've read about any actual attacks that have been carried out in the wild. Thing is, if there's a vulnerability there then organisations are gonna want to patch them, and maybe some individuals might too. I'm thinking though that these kind of sophisticated attacks are mostly only likely to occur against high value targets, so for the average consumer I don't think these exploits and their patches are quite as significant. At the moment my thought process is that I will adopt the default protection offered by Windows and Intel, rather than doing things like disabling hyper threading - I do have Spectre & Meltdown activated, because it's quite a small performance hit and it's also the default position for Windows/Intel.

 

To go back to HT:

I figure you bought Intel because gaming. In that case, HT makes no difference, 0% loss in performance in vast majority of new 2018/2019 games. Or if you use Adobe products, which seems to prioritize speed over MT, I haven't seen evidence disabling HT will make too much difference, and about the same performance of Ryzen still.

If you care about multi-threading... Well in that case, I would assume you bought either Ryzen or Threadripper, cause Intel equivalents are so expensive right now.

 

HT makes a big difference in performance in a lot of tasks. It's in the region of 30% performance improvement over non-HT, depending on what the work load is. HT is being used all the time on an HT enabled CPU - all logical cores exposed to the operating system are HT cores, each one of them...it's not like the operating system sees 4 real cores and then 4 HT cores, the operating system sees instead 8 HT cores.

EDIT: and HT does help in some games. Worth leaving enabled for gaming. BF1 is just one game that springs to mind. But yeah, not really any difference in gaming performance between 9700K and 9900K, but that's because 9700K already has 8 cores (non hyperthreaded), which is plenty for all games. For 4 core and 6 core CPUs like 7700K and 8700K you're better off leaving HT enabled, and the 4 core CPUs definitely need it.

 

I have not seen this myself. And it seems Intel agrees considering HT is disabled on 9600K and 9700K and they are still outperforming the 8700K w/ HT.

For daily tasks, I'm sure I could disable HT on Ryzen and even disable half the cores and not notice difference.

Either way, maybe I am wrong, but that's all I have read/watched so far.

I would ignore most of this if I was still using Intel. I don't see why I would be vulnerable to any of this. Seems to me this is all way overblown.

I just hope Intel does not ignore this and their 10nm chips eliminate these vulnerabilities.

 

It is all overblown until someone gets hurt by it. No one worried about any of the attacks before they happened and of course took no action to patch or protect from them. As soon as things like Wana-Cry hit then it was a scramble to fix it. Sometimes you catch the thieve before they get in the door, other times you may wake up with them rambling through the house.

 

There will come more Security flaws. Both in hardware, OS, software, drivers etc. A never ending cycle.
http://forum.notebookreview.com/thr...nd-announcements.826887/page-14#post-10913668

 

I feel wannacry and this are different. Wanna-Cry was easily done, as it traveled from infected machines to other machines quickly.

These CPU vulnerabilities require such specific conditions to work, and it seems often you need administrative rights, access to BIOS, root etc, in which case you'd have to have direct control of the machine. My impression with these, if an attacker was able to use these vulnerabilities, this would be the LEAST of your worries.

 

So let's recap.

From Intel Developer Zone: "MDS may allow a malicious user who can locally execute code on a system to infer the values of protected data otherwise protected by architectural mechanisms."
- LOCALLY EXECUTE THE CODE. If you can LOCALLY EXECUTE the code, you don't need these vulnerabilities, it implies you have ACCESS TO THE MACHINE LOCALLY. HOLY SMOKES IS THIS CRYING SO OUT OF PROPORTION AND WHACKED!!!!!

MDS attacks which encompass Zombieload RIDL and the other stupid attacks that don't actually work... Actually work as in, this vulnerability goes back EIGHT YEARS and not one instance or example of it has been documented thus far. No one has proven these attacks actually can work.

The only examples I have seen on mdsattacks.com for example, the person demonstrating h as to execute the vulnerability LOCALLY and it took them TWENTY FOUR HOURS TO WORK... HOLY CRAP, if someone has control of your machine in person for TWENTY FOUR HOURS, you got far more serious issue. Like basic security access to your machines.

In all the examples, you would first either have to gain remote access to the machine with root privileges or gain direct access to the machine. In both cases, if the attacker succeeded, these exploits are pointless. The attacker has far more effective ways to gain access to your files. So far, from what I have garnered since details are so sparse on these vulnerabilities, a lot of generalized rubbish that amount to drivel nothingness, these vulnerabilities are idiotic, and almost not even worth mentioning.

I'm not defending Intel, but to execute these vulnerabilities, holyshit, you have far more to worry about than this idiocy.

Also most BIOS, Windows, Linux distros and Apple already have resolved these problems. So I think the tech world should continue to panic and cry over this. Yup definitely.

 

Change your password every 23 hours and you have nothing to worry about lol.

 

When you come across an exploit through a browser or a download, that exploit is then run as "you" locally, until it finds an exploit to work to get elevated privileges.

Running either as "you" or as the "superuser" locally, the package can then do it's work. It can sit there in the background, with it's task manager / process manager listing removed so it's invisible. It can take hours, or days, it doesn't matter, when the data is collected it can then be held or sent immediately. It can take as long as it wants, set up a server for other connections, or do what it wants.

There are ways to find such things, even before they are ID'd, but those methods are also known to the attackers, and often the exploit package can hide it's presence.

Each software exploit - through the browser, OS, firmware exploits are all old news. Exploits using CPU hardware security holes are more rare, and certainly at the constant level of findings for Intel vulnerabilities, it's gotten to the point where it's advisable to disable HT - advice from major OS /VM vendors, as posted previously. The OS / VM vendors are taking it all very seriously.

Intel and Microsoft are the largest vendors with the largest market share and are therefore the largest target for exploits, and for bad actors to apply their energies to finding ways around mitigation.

These new Intel CPU vulnerabilities are ripe for new exploits, and it's only a matter of time before they are used.

To seriously believe that these new gaping holes won't be attacked over time is to ignore history. There's nothing to joke about here.

 

Wanna cry was a combination of pieces put together for a purpose. The infection vector could be used to deliver other payloads.

Here's a pretty good explanation of the package, how it initially infects, and the rest of the tasks of the payload.

What is WannaCry ransomware, how does it infect, and who was responsible?
Stolen government hacking tools, unpatched Windows systems, and shadowy North Korean operatives made WannaCry a perfect ransomware storm.
https://www.csoonline.com/article/3...w-does-it-infect-and-who-was-responsible.html

Imagine another exploit besides SMB is used for infection and delivery of the payload, and that payload instead can now use Intel CPU Vulnerabilities to extract data from your system - similarly to Wannacry, thousands of systems - and then you have an idea of what how little protection "running locally" really is.

The Intel vulnerabilities don't need to provide an infection vector themselves, there are plenty of other attack vectors to deliver a package exploiting Intel CPU vulnerabilities.

 

I used Wanna-cry not as a tech comparison but as a social one. If there is an exploit that can be had it will be used and to wait to do something until it is too late, well...…..

 

JSP and HTML based fake website are easy to make and impersonate. Self signed exe from powershell can be a attack vector too. Or it might be layered malware using combination of drive by malware, miners,spectre/MDS based exploit target based data mining and processing/cleaning/extraction.
Everyone PC has powerful CPUs and GPUs and for common users CPU/GPU hitting 100% won't be much of an issue.

 

Spectre/Meltdown/L1TF/MDS Mitigation Costs On An Intel Dual Core + HT Laptop
Written by Michael Larabel in Hardware on 21 May 2019 at 08:19 AM EDT. 23 Comments
https://www.phoronix.com/scan.php?page=news_item&px=Spec-Melt-L1TF-MDS-Laptop-Run

"Following the recent desktop CPU benchmarks and server CPU benchmarks following the MDS / ZombieLoad mitigations coming to light and looking at the overall performance cost to mitigating these current CPU vulnerabilities, there was some speculation by some in the community that the older dual-core CPUs with Hyper Threading would be particularly hard hit. Here are some benchmarks of a Lenovo ThinkPad with Core i7 Broadwell CPU looking at those mitigation costs.

Here are some quick complementary data points looking at the impact of the mitigations=off / mitigations=auto (the default kernel behavior for these mitigations) / mitigations=auto,nosmt (disabling Hyper Threading) when using a Core i7 5600U with two physical cores plus Hyper Threading, very different from the desktop/server CPU benchmarks in recent days with high core counts.
...
There are quite a few graphs in that article, but it's otherwise short, check out the URL above.
...
If looking at the geometric mean across dozens of benchmarks ran, the default/out-of-the-box mitigations dropped the performance by 18% or 25% when disabling Hyper Threading. See all the benchmarks via this OpenBenchmarking.org result file."

This is where the main problem - loss of performance - comes into debilitating effect, on low core count CPU's and even new CPU's with steppings older than the latest from Intel production, check your CPU stepping against Intel's hardware mitigations list - if you CPU is a month or older it's likely not "fixed in hardware":

Engineering New Protections Into Hardware
https://www.intel.com/content/www/u...ngineering-new-protections-into-hardware.html

"In 2018, the class of speculative execution side channel vulnerabilities, commonly referred to as Spectre and Meltdown, presented a unique challenge to Intel and the entire industry.

Intel provided microcode updates (MCU) supporting nearly 10 years of Intel® products, which were coupled with updates from our partners to help protect against these vulnerabilities.

We have also taken steps to integrate these protections into our hardware.

Side Channel Mitigation by Product CPU Model
The table below provides details on how the protections are integrated into Intel® products:"

See the above URL for the wide tables to find your CPU - if listed - and if it is find out which was the first "stepping" that solves the vulnerabilities listed in hardware (not all vulnerabilities are fixed in hardware yet).

schmidtbag 05-21-2019, 09:01 AM
"This is one of the few situations where I've actually been able to notice the performance losses without needing benchmarks to confirm my observations. I've noticed my i3 Haswell laptop getting slower and my overall CPU usage going up the past few months."
https://www.phoronix.com/forums/for...tel-dual-core-ht-laptop?p=1100561#post1100561

teresaejunior 05-21-2019, 02:02 PM
"This is so much fun. Slower I/O, memory allocation, network latency. Some SSDs work at almost half speed. Thanks, Intel."
https://www.phoronix.com/forums/for...tel-dual-core-ht-laptop?p=1100705#post1100705

 

I hope you find it helpful to hear from the perspective of a semiconductor security POV.

Meltdown, Spectre And Foreshadow
Why security must be addressed at the architectural rather than the micro-architectural level.
Semiconductor Engineering
Published on Jun 1, 2019
Ben Levine, senior director of product management for Rambus’ Security Division, talks with Semiconductor Engineering about hardware-specific attacks, why they are so dangerous, and how they work


Welcome to Semiconductor Engineering
https://semiengineering.com/

I believe that the initial response to Spectre / Meltdown Vulnerabilities that CERT gave us "to replace the vulnerable CPU with another CPU that isn't vulnerable", is the only real solution, and has been all along:

"But the Computer Emergency Response Team, or CERT, has issued a statement saying there is only one way to fix the vulnerability: replace the CPU.

CERT is based at Carnegie Mellon University and is officially sponsored by the U.S. Department of Homeland Security’s Office of Cybersecurity and Communications.

“ The underlying vulnerability is primarily caused by CPU architecture design choices,” CERT researchers wrote. “Fully removing the vulnerability requires replacing vulnerable CPU hardware.”

They also advise users to apply the various software patches but note that this will only “mitigate the underlying hardware vulnerability.”"
https://venturebeat.com/2018/01/04/...nd-spectre-vulnerabilities-is-to-replace-cpu/

CERT now has a less curt more detailed yet similar statement in their online Solutions as it exists today:

"...
Apply updates
Operating system, CPU microcode updates, and some application updates mitigate these attacks. Note that in many cases, the software fixes for these vulnerabilities will have a negative affect on system performance. Also note that Microsoft Windows systems will no longer receive security updates via Windows Update if they are not running compliant anti-virus software. As with deploying any software updates, be sure to prioritize and test updates as necessary.

Consider CPU Options
Initial reports from the field indicate that overall system performance is impacted by many of the available patches for these vulnerabilities. Depending on the software workflow and the CPU capabilities present, the performance impact of software mitigations may be non-trivial and therefore may become an ongoing operational concern for some organizations.

While we recognize that replacing existing CPUs in already deployed systems is not practical, organizations acquiring new systems should evaluate their CPU selection in light of the expected longevity of this vulnerability in available hardware as well as the performance impacts resulting from the various platform-specific software patches.

Deployment contexts and performance requirements vary widely, and must be balanced by informed evaluation of the associated security risks. Contact your system vendor to determine if the CPU and operating system combination will experience a performance penalty due to software mitigations for these vulnerabilities."
https://www.kb.cert.org/vuls/id/584653/

CERT said it the way it is, which is the only way it should be stated when communicating urgent and clear security solutions. Plainly and simply.

But, now with more text wrapped around it to make it less scarily blunt, because so many from outside of the security world were drawn in to read their statements.

I'm as exposed as others with my Intel hardware, some of it without even so much as a firmware patch available to protect it in conjunction with OS protections, even though that once expensive hardware is perfectly adequate to do work today, and for many years to come.

 

@hmscott did you see the be tool to access PSP on AMD CPUs?

 

Replied to here:
http://forum.notebookreview.com/thr...ga-polaris-gpus.799348/page-610#post-10922246

 

ChromeOS 74 had a configurable to enable Hyperthreading if CPU performance is important for your work, otherwise the default is set to disable Hypertheading for Intel CPU's, Chrome OS 75 has added more mitigations for new specific instances of the MDS flaws with new names:

Chrome OS 75 Adds More Mitigations for Intel MDS Flaws
By Eduard Kovacs on June 27, 2019

" Chrome OS version 75, which Google released on Wednesday in the stable channel, adds more mitigations for recently disclosed Microarchitectural Data Sampling (MDS) vulnerabilities affecting most Intel processors made in the last decade.

The researchers who discovered the security holes have named them ZombieLoad, RIDL (Rogue In-Flight Data Load), Fallout, and Store-to-Leak Forwarding. Intel has assigned them the following names and CVEs: Microarchitectural Store Buffer Data Sampling (MSBDS, CVE-2018-12126), Microarchitectural Fill Buffer Data Sampling (MFBDS, CVE-2018-12130), Microarchitectural Load Port Data Sampling (MLPDS, CVE-2018-12127), and Microarchitectural Data Sampling Uncacheable Memory (MDSUM, CVE-2018-11091).

When the existence of the flaws came to light, Google informed Chrome OS users that version 74 had disabled Hyper-Threading by default, which should prevent exploitation. Chrome OS 75 includes other, unspecified mitigations for these attacks.

Google pointed out when the vulnerabilities were disclosed that disabling Hyper-Threading could have a negative impact on performance in some cases.

“Users concerned about the performance loss, such as those running CPU intensive workloads, may enable Hyper-Threading on a per machine basis. The setting is located at chrome://flags#scheduler-configuration. The ‘performance’ setting chooses the configuration that enables Hyper-Threading. The ‘conservative’ setting chooses the configuration that disables Hyper-Threading,” the company explained.

The ZombieLoad, RIDL and Fallout attack methods work against both PCs and cloud environments. An attacker can leverage these techniques to get applications, the operating system, virtual machines and trusted execution environments to leak information, including passwords, website content, disk encryption keys and browser history.

In the case of Chrome OS, impacted devices include several Chromebook, Chromebox and Chromebase devices made by AOpen, ASI, ASUS, Acer, Bobicus, CTL, Dell, Edxis, Google, HP, LG, Lenovo, Samsung, Toshiba and others."

 

Bypassing KPTI Using the Speculative Behavior of the SWAPGS Instruction
August 6, 2019
https://labs.bitdefender.com/2019/0...eculative-behavior-of-the-swapgs-instruction/

"Bitdefender senior researchers Dan Horea Luțaș and Andrei Vlad Luțaș recently uncovered a new speculative-execution vulnerability and demonstrated how it can be exploited via a side-channel style attack, dubbed SWAPGS Attack. The vulnerability has been publicly reported today as CVE-2019-1125
...
In a technical whitepaper published today, Bitdefender researchers describe the SWAPGS Attack. The attack is a novel approach of leaking sensitive information from the kernel since it bypasses all known side-channel attack mitigation techniques. This is achieved by abusing the fact that SWAPGS instruction can be executed speculatively. An attacker can force arbitrary memory dereferences in kernel, which leaves traces within the data caches. These signals can be picked-up by the attacker to infer the value located at the given kernel address.

Existing mitigations are provided by Bitdefender through the Hypervisor Introspection (HVI). HVI is available for Citrix Hypervisor and is in technology preview for KVM hypervisor."

Critical SWAPGW Attack
New Side-Channel Attack Bypasses SPECTRE and MELTDOWN Defences
https://www.bitdefender.com/business/swapgs-attack.html

"Bitdefender researchers have identified and demonstrated a new side-channel attack. The attack builds on previous research which led to the Spectre and Meltdown attacks. This newly disclosed attack bypasses all known mitigation mechanisms implemented in response to Spectre and Meltdown. Bitdefender Hypervisor Introspection renders Windows systems impervious to this new attack.

The SWAPGS Attack affects newer Intel CPUs that use speculative execution..."

Protecting against SWAPGS Attack via Hypervisor Introspection
Bitdefender Enterprise
Published on Aug 6, 2019
A practical demonstration of HVI detecting and blocking a SWAPGS attack on Citrix Hypervisor.


ValkyrieOneNiner 4 days ago
"'Protecting against SWAPGS Attacks' Don't buy an Intel CPU."

RIddler 2 days ago
"Unfortunately you don't get much option when purchasing a laptop. Sure you can custom build your pc with amd chip but when it comes to laptop, most of them have intel chips which is very annoying"

More information on SWAPGS and Speculative only Segment Loads
On August 6, 2019, researchers at BitDefender* published details on two issues they reported to both Intel and Microsoft* as part of coordinated vulnerability disclosure (CVD).
https://software.intel.com/security...ion-swapgs-and-speculative-only-segment-loads

" SWAPGS
Researchers from BitDefender published a paper entitled, "Bypassing KPTI Using the Speculative Behavior of the SWAPGS Instruction." This information disclosure vulnerability can be used to speculatively access memory, potentially allowing a malicious actor to read privileged data across trust boundaries.

After assessing this issue with industry partners, we determined that the best mitigation would be at the software layer. Microsoft agreed to coordinate remediation efforts, working with the researchers and other industry partners. Microsoft released their software update to address this issue in July 2019 and today published their security advisory as part of the CVD process.

Some Linux* OS vendors may elect to release updates for their products. Please check with your Linux OS vendor for details."

AMD Updates - SWAPGS (CVE-2019-1125) - 8/6/19
https://www.amd.com/en/corporate/product-security

"AMD is aware of new research claiming new speculative execution attacks that may allow access to privileged kernel data. Based on external and internal analysis, AMD believes it is not vulnerable to the SWAPGS variant attacks because AMD products are designed not to speculate on the new GS value following a speculative SWAPGS. For the attack that is not a SWAPGS variant, the mitigation is to implement our existing recommendations for Spectre variant 1.

Description + AMD Recommendation

SWAPGS instruction speculation at CPL3 (Scenario 1)
AMD believed not impacted

SWAPGS instruction speculation at CPL0 (Scenario 2, Variant 1)
AMD believed not impacted

GS base value speculation (Scenario 2, Variant 2)
AMD recommends implementing existing mitigations for Spectre variant 1"

PATCHES => Microsoft Security Update Guide CVE-2019-1125
Details CVE-2019-1125 | Windows Kernel Information Disclosure Vulnerability
Security Vulnerability Published: 08/06/2019 MITRE CVE-2019-1125
https://portal.msrc.microsoft.com/en-us/security-guidance/advisory/CVE-2019-1125

"On January 3, 2018, Microsoft released an advisory and security updates related to a newly-discovered class of hardware vulnerabilities (known as Spectre) involving speculative execution side channels that affect AMD, ARM, and Intel CPUs to varying degrees. This vulnerability, released on August 6, 2019, is a variant of the Spectre Variant 1 speculative execution side channel vulnerability and has been assigned CVE-2019-1125.

Microsoft released a security update on July 9, 2019 that addresses the vulnerability through a software change that mitigates how the CPU speculatively accesses memory. Note that this vulnerability does not require a microcode update from your device OEM."

PATCHES => Microsoft Security Update Guide CVE-2019-1125

REDHAT Customer Portal
CVE-2019-1125: Spectre SWAPGS gadget vulnerability
https://access.redhat.com/articles/4329821

"... Resolution
Red Hat customers running affected versions of the Red Hat products are strongly recommended to update them as soon as errata are available. Customers are urged to apply the appropriate updates immediately and reboot to mitigate this flaw correctly..."

Red Hat Security Errata
https://access.redhat.com/security/cve/cve-2019-1125

Impact: Moderate
Public Date: 2019-08-06
CWE: CWE-385-> CWE-200
Bugzilla: 1724389: CVE-2019-1125 kernel: hw: Spectre SWAPGS gadget vulnerability

Platform Errata Release Date
Red Hat Enterprise Linux 8 (kernel) RHSA-2019:2411 2019-08-07
Red Hat Enterprise Linux 8 (kernel) RHSA-2019:2411 2019-08-07
Red Hat Enterprise Linux 8 (kernel-rt) RHSA-2019:2405 2019-08-07
Red Hat Enterprise Linux 8 (kernel-rt) RHSA-2019:2405 2019-08-07

Affected Packages State, Platform Package State
Red Hat Virtualization 4 redhat-virtualization-host, Affected
Red Hat OpenShift Container Platform 4.1 kernel, Affected
Red Hat Enterprise MRG 2 kernel-rt, Affected
Red Hat Enterprise Linux 7 kernel-alt, Not affected
Red Hat Enterprise Linux 7 kernel, Affected
Red Hat Enterprise Linux 7 kernel-rt, Affected
Red Hat Enterprise Linux 6 kernel, Affected
Red Hat Enterprise Linux 5 kernel, Affected

Mitigation
For mitigation related information, please refer to the Red Hat Knowledgebase article [ Above]:
https://access.redhat.com/articles/4329821
Last Modified Thursday at 4:21 AM"

 

NetCAT is another side-channel attack against Intel CPU's with DDIO Enabled in server environments...another side-channel attack vulnerability...

Weakness in Intel chips lets researchers steal encrypted SSH keystrokes
DDIO makes servers faster. It can also allow rogue servers to covertly steal data.
DAN GOODIN - 9/10/2019, 11:35 AM
https://arstechnica.com/information...s-researchers-steal-encrypted-ssh-keystrokes/

"In late 2011, Intel introduced a performance enhancement to its line of server processors that allowed network cards and other peripherals to connect directly to a CPU's last-level cache, rather than following the standard (and significantly longer) path through the server's main memory. By avoiding system memory, Intel's DDIO—short for Data-Direct I/O—increased input/output bandwidth and reduced latency and power consumption.

Now, researchers are warning that, in certain scenarios, attackers can abuse DDIO to obtain keystrokes and possibly other types of sensitive data that flow through the memory of vulnerable servers. The most serious form of attack can take place in data centers and cloud environments that have both DDIO and remote direct memory access enabled to allow servers to exchange data.

A server leased by a malicious hacker could abuse the vulnerability to attack other customers. To prove their point, the researchers devised an attack that allows a server to steal keystrokes typed into the protected SSH (or secure shell session) established between another server and an application server.

Merely scratching the surface
The researchers have named their attack NetCAT, short for Network Cache ATtack. Their research is prompting an advisory for Intel that effectively recommends turning off either DDIO or RDMA in untrusted networks. The researchers say future attacks may be able to steal other types of data, possibly even when RDMA isn't enabled. They are also advising hardware makers do a better job of securing microarchitectural enhancements before putting them into billions of real-world servers.

"While NetCAT is powerful even with only minimal assumptions, we believe that we have merely scratched the surface of possibilities for network-based cache attacks, and we expect similar attacks based on NetCAT in the future," the researchers, from the Vrije Universiteit Amsterdam and ETH Zurich, wrote in a paper published on Tuesday. "We hope that our efforts caution processor vendors against exposing microarchitectural elements to peripherals without a thorough security design to prevent abuse."

The researchers devised NetCAT after reverse-engineering DDIO and finding that last-level caches were sharing data across CPUs and peripherals, even when they received untrusted or potentially malicious input. Among the things this shared resource divulged was the precise arrival times of data packets sent in sensitive connections such as SSH. The information gave the researchers a side channel they could use to deduce the contents of each keystroke.

NetCAT is based partly on the observation that humans follow largely universal typing patterns that can often reveal clues about the keys they enter into a keyboard. For instance, it's usually faster for most people to type an "s" immediately after an "a" than to type a "g" right after typing an "s." These patterns allowed the researchers to use DDIO to carry out a keystroke timing attack, similar to this one, that uses statistical analysis of the inter-arrival timings of packets. Below is a video demonstrating the attack:

NetCAT remotely leaking keystrokes from a victim SSH session
VUSec
Published on Sep 10, 2019


bitburner 1 day ago
"Too bad you didn’t do a simple google search to find out that NetCAT is already the name of an old and extremely popular security tool."

Continuing article...
"The researchers used rapid delivery provided by RDMA to simplify the attack, but it's not a strict requirement, and future attacks may not need it at all. In an email, Kaveh Razavi, one of the Vrije Universiteit researchers who wrote the paper NetCAT: Practical Cache Attacks from the Network, wrote:

" In short, the root cause of the vulnerability boils down to Intel's DDIO feature enabling the (last-level) CPU cache to be shared with arbitrary peripherals such as network cards.

This dramatically extends the attack surface of traditional cache side-channel attacks, which are normally mounted on a local setting (say from a VM to another in the cloud), exposing servers to cache side-channel disclosure from untrusted clients over the network.

Using RDMA (for convenience), we have demonstrated the vulnerability can be exploited in real-world settings to leak sensitive information (e.g., keystrokes from an SSH session)."

PRIME+PROBE
To suss out the timing information from the last-level cache, the researchers used a technique known as PRIME+PROBE. It involves first priming the cache by receiving packets that will be read from certain memory locations. The result: the technique brings the cache to a known state. The attack then waits for the target SSH client to type a letter. That triggers the PROBE stage, which attempts to detect any changes by receiving the same packets from the same memory locations.

"If the client has typed a key, then these packets will arrive slightly slower, signaling a keystroke," Razavi wrote. "By performing PRIME+PROBE in a loop, NetCAT can find out whenever the victim types something in a network connection."

The researchers proposed a second attack scenario that uses DDIO as a covert channel to funnel sensitive data off a server. In one variation, the covert channel connects a targeted server to an unnetworked, cooperating sandboxed process on a remote machine. A second variation creates a covert channel between two cooperating network clients running inside two separate networks.

Covert channels are mechanisms attackers use to transfer data between processes or hardware that are barred by security policies from communicating with one another. By stealthily bypassing this policy, attackers can steal sensitive data in a way that's not detectable by the target.

The research is impressive, and the vulnerability it reveals is serious. Anyone who uses Intel-made processors inside data centers or other untrusted networks should carefully review the research, Intel's advisory, and any advisories by the network provider to ensure DDIO doesn't present a threat.

People should also be aware that disabling DDIO comes at a significant performance cost.

So far as the researchers know, chips from AMD and other manufacturers aren't vulnerable because they don't store networking data on shared CPU caches.

At the same time, people should remember that the research isn't likely to materialize into widespread attacks in the real world any time soon.

" NetCAT is a complex attack and is likely not the low-hanging fruit for the attackers," Razavi wrote. "In server settings with untrusted clients, where security matters more than performance, however, we recommend DDIO to be disabled."

Reader Comments

Twilight Sparkle, SEP 10, 2019 12:09 PM
"Hunt and peck is now a security technique."

April King, SEP 10, 2019 11:39 AM
"NetCAT is just about the worst possible name for a piece of software like this, since it's been used by netcat (aka `nc`) for about 25 years now. Searches are going to be a nightmare."

IDK, adding DDIO and / or RDMA / SSH, that should help narrow the results.

ChronoReverse, SEP 10, 2019 11:44 AM
"Another day another Intel performance enhancement that turns out to be a security flaw."

John_5mith, SEP 10, 2019 11:56 AM
" Wickwick wrote:
Is it just me or is it starting to feel that any sort of cache is just waiting to be abused?"

" Cache is the root of all evil."

Intel NetCat Security Flaw: The Last Straw to Break the Camel's back...
Moore's Law Is Dead
Premiered 12 hours ago
Another month, another crippling security flaw.


Love Thy Neighbor 9 hours ago
"Doesn't matter. Intel is the BEST at Windows Media Player."

Jason Gooden 12 hours ago
"I was making lunch when I heard Intel had anther security flaw, I just kept making lunch without breaking stride. Not surprised at all, that’s pretty sad."

gamamew 11 hours ago
"LOL so Intel chips are more of a piece of garbage than ever. If you want SMT and virtualization you have to go red team."

Sergio Madureira 12 hours ago
"New security flaw - Intel runs to the closest sand pit to bury their head in"

Replace Intel CPU's is the only sure way to fix these vulnerabilities... gee, didn't CERT say that at the very start of all of this going on 2 years ago??

Cybersecurity agency: The only sure defense against huge chip flaw is a new chip
BY Marcus Gilmer, 2018-01-04 18:54:41 UTC
https://mashable.com/2018/01/04/chip-flaw-cert-recommendation/



Xeon and Other Intel CPUs Hit by NetCAT Security Vulnerability, AMD Not Impacted
by Nathaniel Mott September 11, 2019 at 7:48 AM
https://www.tomshardware.com/news/intel-xeon-cpu-netcat-security-vulnerability-flaw,40376.html

NetCAT: Practical Cache Attacks from the Network
Michael Kurth, Ben Gras, Dennis Andriesse, Cristiano Giuffrida, Herbert Bos, and Kaveh Razavi
Department of Computer Science Vrije Universiteit Amsterdam, The Netherlands
https://www.cs.vu.nl/~herbertb/download/papers/netcat_sp20.pdf

 

Haha..... But I'm sad that nearly all my laptops must be switched to an new AMD based laptop.

 

My off topic response moved here:
http://forum.notebookreview.com/thr...99-xeon-vs-epyc.805695/page-300#post-10950325

 

I'm done with gaming jokebooks! I'm all in on Business laptops from Lenovo. Thinkpad with Ryzen will have 3years+ support in terms of updates, so it makes sense in enterprise and consumer spaces since you get more out from your laptop.

 

good choice, even im waiting for some ryzen laptop, seeing the way 5700XT performs for the price, i think its a win win for AMD...

 

Which laptops sport an AMD CPU now that can rival Intel's offerings?

 

And, Intel has issued Security Updates...with INTEL-SA-00290 being of primary interest as it applies to the NetCAT DDIO & RDMA vulnerabilities.

National Cyber Awareness System=> Current Activity Landing => Intel Releases Security Updates
https://www.us-cert.gov/ncas/current-activity/2019/09/10/intel-releases-security-updates

Intel Releases Security Updates
Original release date: September 10, 2019
"Intel has released security updates to address vulnerabilities in multiple products. An attacker could exploit one of these vulnerabilities to gain an escalation of privileges on a previously infected machine.

The Cybersecurity and Infrastructure Security Agency (CISA) encourages users and administrators to review Intel's Security Advisories INTEL-SA-00290 and INTEL-SA-00285 and apply the necessary updates."

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

Summary:
"A potential security vulnerability in some microprocessors with Intel® Data Direct I/O Technology (Intel® DDIO) and Remote Direct Memory Access (RDMA) may allow partial information disclosure via adjacent access.

Vulnerability Details:
CVEID: CVE-2019-11184

Description: A race condition in specific microprocessors using Intel (R) DDIO cache allocation and RDMA may allow an authenticated user to potentially enable partial information disclosure via adjacent access.

CVSS Base Score: 2.6 Low

CVSS Vector: CVSS:3.1/AV:A/AC:H/PR:L/UI:R/S:C/C:L/I:N/A:N

Affected Products:
Intel® Xeon® E5, E7 and SP families that support DDIO and RDMA.

Recommendations:
Partial information potentially disclosed through exploitation of this vulnerability could be utilized to enhance unrelated attack methods. For published exploits that Intel is aware of, Intel recommends users follow existing best practices including:

Where DDIO & RDMA are enabled, limit direct access from untrusted networks.

The use of software modules resistant to timing attacks, using constant-time style code.

Security Best Practices For Side Channel Resistance:

https://software.intel.com/security...curity-best-practices-side-channel-resistance

Guidelines For Mitigating Timing Side Channels Against Cryptographic Implementations:

https://software.intel.com/security...hannels-against-cryptographic-implementations

Acknowledgements:
Intel would like to thank Michael Kurth, Ben Gras, Dennis Andriesse, Cristiano Giuffrida, Herbert Bos, and Kaveh Razavi from VU Amsterdam for reporting this issue.

Intel, and nearly the entire technology industry, follows a disclosure practice called Coordinated Disclosure, under which a cybersecurity vulnerability is generally publicly disclosed only after mitigations are available."

 

None, if you like to play games at maximum visual quality. Which is something AMD should really fix, having more CPU choices is always a good thing for consumers and for laptop manufacturers.

 

Almost NIL on gaming laptops but one or two models of thinkpad has Ryzen U series which is more than enough for programming and daily tasks. But, sadly I'm waiting for Tseries model with Ryzen 7.

 

Hope you like this wallpaper. Register to this forum just to reply you

p.s I am the one who photoshop this wallpaper

New wallpaper in 4K resolution. Enjoy~

http://fav.me/ddk3t87

 

Maybe you should create a new wallpaper for the newest Intel chips


Intel has steadily added new hardware-based mitigations for many of the new vulnerabilities, like MSBDS, Fallout, and Meltdown, with new steppings of its die.

 

I'd have liked Cracked Intel Inside logo with all vulnerability popping up like a gift hamper!

 

Not everyone is happy with Intel's "progress" at fixing security problem(s) reported more than 2 years ago to Intel...with serious flaws reported to Intel over a year ago are still actively ignored by Intel - maybe because it's unfixable?

Intel Failed to Fix a Hackable Chip Flaw Despite a Year of Warnings
Speculative execution attacks still haunt Intel, long after researchers told the company what to fix.
11.12.2019
https://www.wired.com/story/intel-mds-attack-taa/

"Over the past two years, attacks like Spectre, Meltdown, and variants on those techniques—all capable of tricking a broad range of processors into coughing up sensitive data—have shown how hard it can be to secure a chip. But it's one thing for a company like Intel to scramble to fix a vulnerability, and a very different one when it fails to act on one of those flaws for more than a year.

Today researchers at Vrije Universiteit in Amsterdam, KU Leuven in Belgium, the German Helmholtz Center for Information Security, and the Graz University of Technology in Austria revealed new versions of a hacking technique that takes advantage of a deep-seated vulnerability in Intel chips.

They're spins on something known as ZombieLoad or RIDL, an acronym for Rogue In-Flight Data Load; Intel refers to it instead as as microarchitectural data sampling, or MDS. Like the Spectre and Meltdown vulnerabilities—which some of the same Graz researchers were involved in uncovering in early 2018—the new MDS variants represent flaws that could allow any hacker who manages to run code on a target computer to force its processor to leak sensitive data.

The scenarios for that attack could include anything from a website's Javascript running in a victim's browser to a virtual machine running on a cloud server, which could then target a virtual machine on the same physical computer.

But in this case, the researchers are pointing to a more serious failing on Intel's part than just another bug.

While they warned Intel of these newly revealed MDS variants as early as September 2018, the chip giant has nonetheless neglected to fix the flaws in the nearly 14 months since.

And while Intel announced today that it has newly patched dozens of flaws, the researchers say and the company itself admits that those fixes still don't fully protect against the MDS attacks."
...
"In fact, the VUSec researchers say that in the time since they first disclosed the vulnerability to Intel, they've managed to hone it into a technique capable of stealing sensitive data in seconds rather than the hours or days they previously believed necessary."

"They missed completely a variant of our attack—the most dangerous one."
- KAVEH RAZAVI, VUSEC

...more in the article on Wired...

 

It turns out that the new Intel CPU's with hardware mitigations are themselves vulnerable to exploits related to the previous "fixed" vulnerabilities - modded architectural fixes are not fixes. This was obvious to all security experts from the beginning - that the flawed architecture needs to be replaced, vulnerable hardware needs to be replaced, and until Intel releases truly new designs to replace the vulnerable arcitectures, these problems will continue.

A new ‘Zombieload’ flaw hits Intel’s newest Cascade Lake chips
Zack Whittaker @zackwhittaker / 10:00 am PST • November 12, 2019
https://techcrunch.com/2019/11/12/intel-cascade-lake-zombieload/

"Time to reset your “days since last major chip vulnerability” counter back to zero.

Security researchers have found another flaw in Intel processors — this time it’s a new variant of the Zombieload attack they discovered earlier this year, but targeting Intel’s latest family of chips, Cascade Lake.

Intel calls the vulnerability Transactional Asynchronous Abort, or TAA. It’s similar to the microarchitectural data sampling vulnerabilities that were the focus of earlier chip-based side-channel attacks, but TAA applies only to newer chips.

The new variant of the Zombieload attack allows hackers with physical access to a device the ability to read occasionally sensitive data stored in the processor. The vulnerability is found in how the processor tries to predict the outcome of future commands. This technique, known as speculative execution, makes the processor run faster, but its flawed design makes it possible for attackers to extract potentially sensitive data.

Zombieload was discovered by the same researchers who found Meltdown and Spectre, a set of flaws that could be used to pick out secrets — like passwords — from the processor. It was believed later chip architectures, like Cascade Lake, were toughened against speculative execution attacks, while Intel rolled out software patches to reduce the attack surface.

Neither of the other vulnerabilities in the same family as Zombieload — notably Fallout and RIDL — work on Cascade Lake, they added.

But the researchers said that Intel’s efforts to change the chip design in Cascade Lake are “not sufficient” to protect against these kinds of side-channel attacks.

The same researchers warned Intel about the vulnerability in April — as it did with the other flaws they discovered that were patched a month later. Intel took until this month to investigate, the researchers said.

Intel released patches again for its vulnerable chips on Tuesday, acknowledging that its newest chips are vulnerable to the newest Zombieload variant. But the chip making giant recognizes that the mitigations “may not completely prevent the inference of data through a side channel using these techniques.”

The chip maker said there have been “no reports” of real-world exploits of the vulnerabilities."

Intel's busy patching the leaks (as referenced by the Security Researchers in the previous article and post), but new one's keep getting found, here's news about Intel's latest patchathon:

Intel has revealed 77 new chip vulnerabilities, one of which has a notable [consumer] performance impact
Intel's JCC erratum bug is said to have a performance impact of 0-4% excluding outliers
Published: 12th November 2019 | Source: Intel | Author: Mark Campbell
https://www.overclock3d.net/news/cp...e_of_which_has_a_notable_performance_impact/1

"Every month, Intel released a security advisory, allowing the security research community to disclose their findings and for Intel to update their partners on the security of its products.

This month, Intel has disclosed a whooping 77 vulnerabilities that range from processors to graphics and even ethernet controllers. 67 of these bugs have been discovered by Intel internally, while outside sources uncovered ten. Many of these vulnerabilities are minor, though some others will have a notable impact on Intel's products.

More information about these vulnerabilities is available here, with the focus of this article being a specific vulnerability called "JCC Erratum". This vulnerability impact most of Intel's recently released processors, including Coffee Lake, Amber Lake, Cascade Lake, Skylake, Whiskey lake, Comet Lake and Kaby Lake.

This bug relates to Intel's ICache/ Decodes Streaming buffer, though the issue can be addressed with firmware. However, Intel's mitigations document for Jump Conditional Code Erratum states that the mitigation/workaround will impact performance by 0-4% excluding outliers, which means that even higher performance downsides in specific workloads.

Phoronix is the first website to benchmark Intel's processors both with an without their JCC Erratum mitigations, finding notable performance hits in some software. Unlike some of Intel's other mitigations, the fixes for JCC Erratum can impact pure consumer workloads, which means that this update will impact more general PC users than Intel's previous software mitigations."

IPAS: NOVEMBER 2019 INTEL PLATFORM UPDATE (IPU)
Written by Jerry Bryant | November 12, 2019
https://blogs.intel.com/technology/2019/11/ipas-november-2019-intel-platform-update-ipu/#gs.fmys9g

 

I suppose for high security systems you might think twice about using Intel. I mean like really high security stuff, because these Spectre attacks would be very sophisticated and would take a lot of dedication from the attacker I think, so I believe such attacks would be precisely targeted rather than spammed across systems - therefore unless you have reason to be a high value target I'm thinking these vulnerabilities are not as important. However, for high security needs I think I would think twice about Intel. That's my intuition on it based on the bits & pieces I know.

 

Another feature Intel suggests disabling to avoid exploits of their failed CPU architecture security: TSX. I don't recall TSX broken out as a toggle in BIOS's... maybe I've just missed it.

The dangerous Intel: MDS processor problem called Zombieload has a different version and newer processor models are vulnerable to it.
https://howtofix.guide/some-intel-p...to-the-new-version-of-the-zombieload-problem/

Spoiler: Details...

In May of year, researchers revealed information about a new class of vulnerabilities in processors Intel: Microarchitectural Data Sampling (MDS). As well as the Specter and Meltdown vulnerabilities, the new bugs turned out to be associated with a proactive (or speculative) mechanism for executing commands. Then the experts identified four vulnerabilities and three groups of problems: RIDL, Fallout and ZombieLoad.

All these bugs allow an attacker to steal passwords, cryptographic keys and other personal data downloaded or stored in the memory of processor buffers.

As Graz University of Technology experts have now found out, ZombieLoad, the most dangerous of the problems found earlier, has a second option (CVE-2019-11135), which poses a threat to newer Intel processors, including Cascade Lake. Previously experts believed that these processors are not susceptible to such attacks, as they are protected at the hardware level.

We present a new variant of ZombieLoad that enables the attack on CPUs that include hardware mitigations against MDS in silicon. With Variant 2 (TAA), data can still be leaked on microarchitectures like Cascade Lake where other MDS attacks like RIDL or Fallout are not possible. Furthermore, we show that the software-based mitigations in combinations with microcode updates presented as countermeasures against MDS attacks are not sufficient”, — write researchers from Graz University of Technology.

As part of the November update Tuesday, Intel engineers released microcode updates that fix the Zombieload 2 problem.

In the spring of this year, experts were silent about the existence of CVE-2019-11135, since Intel developers were not yet ready to issue patches. Now, researchers said that the work of the second ZombieLoad variation involves the use of Intel Transactional Synchronization Extensions (TSX) technology and asynchronous interruption.

In fact, an attacker could use malicious code to create a conflict between reading operations inside the CPU. As a result, data processed by the processor may leak. Researchers write that the attack even works against machines with hardware fixes for the Meltdown vulnerability (in particular, the i9-9900K and Xeon Gold 5218 were tested).

The only prerequisite for the attack is the need for Intel TSX support, which is available by default in all Intel processors manufactured after 2013 (Haswell processors got the first TSX support).

Intel representatives not only published updated microcodes, but also hastened to assure that Zombieload 2 is not as dangerous as it might seem.

The fact is that all MDS attacks allow malicious code to be executed on Intel processors, but attackers cannot control what data they extract”, – Intel engineers report.

In fact, Intel experts claim that criminals have other, much simpler ways and means to steal data from targets.

Recommendations:
Since patches for speculative attacks usually lead to a potential drop in system performance, many users may not want to install the next update. In this case, Intel recommends disabling TSX support if it is not absolutely necessary."

 

After VMware patch the performance is slowed by 2-10sec. I'm going axe my entire laptops in coming months once Ryzen 3rd gen mobile comes up.

 

What performance slows down specifically for you in your VM's?

I'm fully prepared to take a ~10 sec hit on performance for security, but I don't think I'll gamble with driver/optimization/program and O/S updates with Ryzen 3 which could easily take minutes or hours/weeks/months to be ironed out.

Trading 'slowdowns' is not what I optimize my workloads. Especially trading for unknowns.

 

I think he is referring to using a VM to update the micro-code, but Windows already loads the micro-code at boot time..

Dont forget about the random bug in current Ryzen CPU's that can be corrected via AGESA updates that not all mobo manufacturers are updating in time..
Add to that that laptop BIOS see even less updates, and laptops ship with the smallest needed flash chip and you might be out of NEEDED security updates provided via BIOS/AGESA updates that wont be released or wont even fit in the original laptop flash chip..

Intel might be bad, but laptops with AMD are always super cut down(I smell that its due in part due to Intel colusion/paying the OEM's to make them crappy), there are current Ryzen laptops using the same chassis used with Intel chips that have such a crap cooling that they cant even sustain 15Watts TDP..

Or the Asus gl702zc that wont see a BIOS update to support newer Ryzen CPU's because Asus said so, so much for hurr durr socketed is much better..

 

I used VMware CPU flinger tool to update skylake to D4. Sustained workloads be it CPU/IO are taking a severe hit. VM in Vbox felt slower than usual CC uCode.

 

Do you recall what the name is of that VMware fling?

 

Here you go! http://forum.notebookreview.com/thr...x-for-spectre-ht-bug-fix-and-meltdown.806451/

 

Thanks. But perhaps I'm missing something. How is this affiliated with a VMWare fling?

Nevermind. I got it from reading the post with a link to another post with the VMware fling. That VMware fling can also work with updating the microcode found in regular Windows. I thought the fling would update the microcode in the BIOS of the virtual machine's CPU itself.

 

We use VMware CPU uCode patcher to patch any Intel/AMD CPUs. Its easier to uninstall too!