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

Thanks, looks like Microsoft edited that KB article today to include that info that you're linking regarding enabling retpoline through registry editing. I followed the instructions and applied it to my Sandy Bridge laptop. There's still no performance change in CB15, but I should do that powershell thing to confirm that retpoline is indeed enabled - need to go to sleep now, so will probably do that tomorrow.

 

Ok, so it says that "an attacker...requires some kind of foothold in your machine in order to pull this off". If that's the case, then wouldn't an attacker with a foothold in your machine be able to use other types of attacks rather than this new Spectre attack to retrieve the same information - I mean it's another potential tool in their arsenal, but I'm surmising that they'd be able to find out the same information in other ways if they already had a foothold in your machine. If this is the case, then it kind of downplays the importance/significance of this new Spectre style attack, because it's probably not really increasing risk.

 

Many exploits need some elevated privilege access, and that's easily done through many other privilege exploits, most malware or hidden information gathering software uses multiple exploits in a concerted effort as a package to attain it's goals.

It's kind of a "newbie" thing to say that an exploit that requires elevated privilege is useless because it requires an already exploited machine - since the delay between exploited and actively gathering data is a very short distance for these packaged malware data gatherers.

There are many exploits like this that at one time weren't patched and had long legs before they were, and in a package of exploits to attain a goal there may be many such steps of "trying" to do a hack to get to the next step, with some failing and some working, until the overall goal of access of a particular type is attained.

It's far more complex - and far more simple - than just poo-pooing something because it has pre-requisites to run successfully, as all exploits do, they first have to find a host running the level or revision of OS keen to it's exploit, then it needs to pass through the network in some way to hop onboard, then it needs to be initiated to start the process - so to speak - and then once the process is active there needs to be a way to get the data back home for use.

One step at a time, just like the most complex programmatic goal, is all it takes.

In the case of "Spoiler" apparently browsing a site with "javascript" enabled will be enough, or perhaps kitted along with an installer even better, there are many vehicles to deliver payloads these days, so I don't think "Spoiler" would have any trouble getting onboard and setup quickly.

It also sounds like this little honey will be easier to code up and have a much higher success to attempt rate vs the typical Spectre hack.

It's gonna be a good time to upgrade to AMD coming soon.

 

Well, I'm putting it in perspective by saying that they need a foothold in your computer before they can use this Spectre style attack, combined with the fact that they could do other attacks once they have a foot hold anyway, not just Spectre, so the risk is not vastly greater due to this new threat, that's my intuition of it. It's certainly not lowered the threat level, but I don't think it's increased it much.

 

Nah, you are trying to deflate the importance of practicing mitigation for an exploit by saying it's less dangerous because you say it requires prerequisites that might not exist on a targeted computer.

And, I am saying you are naive, and putting people in actual danger by expressing your faulty logic.

Naysaying security mitigation implementation is a slippery slope for the people and companies that listen to such half-baked comments. The person making them (you) are safe to make such comments having no responsibility for the consequences.

If you are making such suggestions at the company you work, and they are compromised based on your recommendations, then you will be responsible, and likely fired.

I sincerely hope you aren't in a position of responsibility for security policies and implementation at your company.

 

It goes without saying that in an actual business security should be first and foremost. No arguments there from myself or from Robbo99999, from his posts.

But, like Robbo99999 is saying, if someone has the actual hardware in their possession, being 'unprotected' by that specific attack vector is moot. They then have otherwise full access to anything and everything they need to anyhow at that point.

Trying to twist this solid logic to make Robbo99999 or anyone else to look wrong or incompetent only shows how insecure you are. This is ( our) forum.notebookreview.com. Not forum.corporateplatform.com.

And I'll predict (safely, I'm sure) that just like when these Spectre/Meltdown attack vectors were first discovered, it isn't only Intel that is so compromised. Variations of Spoiler will be found in other vendors platforms too.

I'm glad these are being discovered so quickly now. They'll eventually get this right. And by 'they'; I mean all CPU manufacturers that not only exist today but also those that will emerge in the future too.

 

If you two are so convinced security is all a bit of nonsense, and being in possession of your computers protects you against compromise, why are you wasting our time posting naysaying comments here?

We are here to share the information on mitigations for exploits, and implement security around preventing compromises.

We don't need your help trying to convince us that it's all really nothing to get worried about.

 

You really like to make things up and/or pull things out of thin air to make yourself look superior. Heads up, you don't and you aren't.

My comments are in support of Robbo99999's statements which any and every other logical person here would agree to.

Don't try to dig so deep to prove how right you are. Others can be just as right too. Re-read what I and Robbo99999 wrote. Please don't put words in other peoples mouths.

 

Chiming in only on how widespread spoiler is. It only effects Intel chips because only Intel uses the specific way of securing the memory. AMD uses a very different table setup which is NOT exploitable in this specific way. It's also why AMD wasn't exposed to the other Intel memory attack from a couple months back. ARM also has a different implementation. Don't speak without understanding why it was already shown Intel is vulnerable and the others are not.

This is NOT to say there may not exist some memory exploit for AMD (looking at PSP exploits, which AMD employs and Intel doesn't). It is to say don't confuse this with a speculative side channel exploit, or portsmash which also only effects Intel machines (if I remember correctly, that is the L1 cache speculative exploit).

Sent from my SM-G900P using Tapatalk

 

Agree overall with what you state below. However, history/experience has taught me that once an exploit is discovered in any system, the idea behind it can be most likely be leveraged similarly in other/different system.

I did and I do understand before I posted; please don't jump to conclusions.

When an idea is put into a coder (or hackers) head; the end result can usually be achieved, regardless of equipment/hardware.

 

Yes, but there is a reason Intel requires an all encrypted memory segmentation or none, while AMD can do partial encryption, partial not. That difference is not insignificant.

That is why security relies on level headed examination. What was found with meltdown only applied to Intel CPUs and a couple ARM designs. With spectre, it depended on variant of the exploit as to who was vulnerable and the degree to which they were vulnerable. Some of those attacks were not verified on AMD do to researchers not having AMD equipment upon which to verify the exploit (this comes down to market share, and Intel is the behemoth). For portsmash with L1 cache, that was all Intel. For the ones that were done as a hit piece on AMD that the "research security" company released without giving AMD a chance to patch, those were solely AMD chips (most were real, but fixed in a subsequent microcode update and remedied within a month or two). And then there are ARM specific exploits that don't effect AMD or Intel.

My overall point is playing teams, regardless of side you take, is ridiculous when it comes to security. Instead, you need a level headed look at what your deployment is and how exposed the hardware is in that deployment environment. There are times where Intel's vulnerabilities are more likely to be exploited in certain environments, and times AMDs will be.

With that said, no company is willing to turn off predictive branch completely because of the performance hit, instead relying on a couple hardware tweaks, microcode updates, firmware updates, and the bulk in software updates, unfortunately.

What spectre and meltdown started was an avalanche of discovered exploit variants, all while leading researchers to make a name finding new hardware weaknesses.

For spoiler, it is a new one found on Intel related to their memory that others are not vulnerable to. Intel will likely find a hardware fix in time for ice lake desktop, which should be about ready for tape out (too late for the laptop chips expected this summer). That instead acts as a good argument to grab AMD now or Intel possibly then if your deployment scenario runs a specific or elevated risk to the type of attack.

Meanwhile AMD still enjoys the security through obscurity related to their version of Intel's management engine that is found on AMD chips (not saying ME and AMD's implementation are anything alike). At least one vulnerability related to it was discovered and fixed, but it is relatively new, and we've all seen how Intel's management engine is chocked full of exploits. Given enough time, security through obscurity never works. It is great at first, but people will figure it out whether you tell them what is happening with a system or don't.

Because of this, I'm not here to say pick one over the other. It really depends on your deployment as to what risk is being run.

For me, personally, the Intel exploits are too much of a risk, from SXG exploits to the hits from mitigations on speculative attacks to the memory attacks. But that is my deployment and risk tolerance. Others may differ.

Either way, my recommendation is to wait for Intel's server chips this summer and AMD's Zen 2 desktop and server offerings this summer to see what has been fixed by then. There has been little to no opportunity to fix some of the most recent exploits, while others, the answer in re-engineering has not been as quick as hoped. That happens. But, awareness is the first step.

Sent from my SM-G900P using Tapatalk

 

Again, I agree with your statement overall.

The quoted text below is where we differ. I don't believe that what they will say is fixed will be true either way. Nor will it stop further exploits from being discovered weeks, months, years and decades from now.

There is not a lot of choice going forward in 2019 as to whether or not to use an insecure platform like a computer (any computer).

I will keep buying based on performance (Intel still rules there, even after waiting for Ryzen to catch up for a couple of years) and the security will be handled internally as usual (in my terms and with my rules).

Awareness happened around the '70s. The only thing that is changed today and for a few years now is that a larger %age of the general public is aware (at least on some level) of the new(er) exploits too.​

 

First, that was general advice. Second, Intel and AMD have mentioned fortifications and corrections to KNOWN vulnerabilities. Switching to unknown makes no sense here, as it is meant to over generalize and say buy now, which isn't proper for all.

Third, and least important, Zen 2 has already shown to have caught up at stock clocks with the 8-core demo while using significantly less power and will drop mid-year. Do what you like, but facts are facts.

Fourth, awareness isn't just hippy dippy b.s. It allows for an evaluation of your deployment environment, for an evaluation of risks, and to make an informed decision. It allows for monitoring if the risk is accepted, to a degree and only applicable to some vulnerabilities, but can lead to general monitoring for odd behavior.

Fifth, unless you are a coding guru that writes microcode and firmware, as well as modifying OS kernels, etc., no one truly does security on their own. They can make decisions about deploying patches for vulnerabilities, which goes to knowing your deployment environment and risk tolerance, but they alone cannot do all security alone and are at the whims of hardware manufacturers and software vendors to various degrees.

Sent from my SM-G900P using Tapatalk

 

My post was general advice too. Take it for what it's worth.

AMD and Intel will never mention corrections to unknown vulnerabilities. No company does. That is why my long term viewpoint is valid. The exploits will keep coming. Regardless of which brand is the popular favorite today. And why the 'unknown' is also relevant here too.

Zen 2 doesn't interest me in my workflows. Too slow. Lower power may have been a factor, but dropping mid-year? Am I expected to take an extended hiatus while AMD keeps ramping things up? lol...

Yeah, not a coding guru. But microcode and firmware is not the end all and be all of the security within a company either. Like I've stated previously; anything digital is up for grabs by someone just a little bit smarter than yourself.

Anyone is fooling themselves that they're making an informed decision today when it comes to security. I would be surprised that even the great coders working at the big firms saw the exploits found in the last few months to a year.

To take an analogy from a cash flow business problem. The cash is always the problem. Just like the potential data is in the digital domain. Seems we agree that constant monitoring is the only 'solution'.

At the same time, you can only look for what you've been taught to see.

Thanks for the exchange.

 

Some info for you. But I don't know what he used for testing https://forums.mydigitallife.net/threads/windows-10-hotfix-repository.57050/page-378#post-1507000

 

When I have time I'm gonna update my laptop 2920XM Sandybridge CPU with that retpoline registry fix that manually enables retpoline and I'll post back with my performance findings.

I have actually done the same thing with my desktop Skylake 6700K CPU, and even though you can't have retpoline on it (not compatible with Skylake & later CPUs), but it does enable "Import Optimisation" which sits alongside retpoline as the two changes they've used to combat the Spectre related performance losses. I've done some testing on my desktop, and the "Import Optimisation" does increase performance a little, but it's varied. I've seen the highest Firestrike CPU score I've ever seen since Spectre fixes came about, but it's only a small 0.3% higher than the previous highest score I've seen. I did some BF1 gaming and I was taking note of the fps while on the Amiens map (often CPU limited on that one), again I saw the highest fps in certain areas than I've ever seen before since Spectre - I can't really provide a totally accurate figure, but I did see it in the 140's rather than the 130's in the opening section of spawning in Amiens - hard to be absolutely sure though because each time I play that map I don't always look at the fps. CB15 didn't show any improvements with "Import Optimisation".

 

I've been doing real IP security monitoring and mitigation since the first IP/TCP internet debuted in 1981 - implementing protocol source at the kernel level on UNIX - VMS - Tops 10/20 - and dozens of other OS's since, at the firmware and OS configuration level for most every brand of communications hardware involved in the entire communications chain of data, and I was active on the internet before then since 1978 before the TCP transition from NCP.

And, I've continued that work for a wide range of companies, from small startup's to huge multi-national corporations and governments on worldwide networks at the hardware and software level. Designing and debugging at the hardware and software level, pre-configuring and preventing security issues throughout all of those implementations.

In comparison, and to be kind, your comments and @Robbo99999 's comments in this thread stand out in sharp contrast to what I see from other peer professionals, and makes what you two write often look to me like infantile gibbering garbage.

When your comments are directed at trying to make yourselves look good rather than actually trying to solve problems and help people become aware of problems, it's a further waste of our time.

You two, and a few others, repeatedly waste our time trying to downplay the actual serious issues at hand, to the detriment of others security concerns, wasting our time posting useless meanderings instead of contributing something constructively useful.

My perspective is much more serious and matter of fact based on the certainty of real world experience - how things look when discovered, how they look as they progress into real threats, and how they look as captured in real time as they happen to live systems, over days, weeks, months and years, transitioning to long term support for mitigations into decades of time.

Please stop filling the thread with useless posts that dilute the useful information with garbage no one seriously interested in this thread topic wants to wade through. We don't want to hear BS that tells us "not to worry about this or that" because of some hair-brained guesses.

You simply don't know what you are talking about and we don't need to hear your mutterings to yourselves why it's all going to be ok and there is nothing to really worry about. There certainly is, and you need to stop ignoring it like it doesn't exist.

 

These problems could be from coincidental changes unrelated to Retpoline - or accidental side effects of changing the associated code, as the retpoline code isn't supposed to be active by default, and should only be able to be enabled manually, which most gamers will not have done - yet they are still seeing performance problems with the patch installed.

It's sad when fix patches create new bugs, even when the fixes aren't active, so until MS gets this patch fixed it's probably best to forgo this retpoline patch by uninstalling it.

Microsoft Warns Latest Windows 10 October Update Can Cripple Game Performance
by Brandon Hill — Thursday, March 07, 2019
https://hothardware.com/news/microsoft-windows-10-october-update-cripple-game-performance

"Microsoft released KB4482887 for Windows 10 version 1809 (October 2018 Update) on March 1st, and the headlining feature was the inclusion of Retpoline performance improvements for Spectrevariant 2 mitigations. But almost immediately, gamers began reporting problems.

In one reddit thread, numerous users complained about performance problems in their games after installing KB4482887. A redditor by the name of rayw_reddit wrote:

This patch is causing massive lag spikes in older games, like CoD4 and CoD MW2. Right after installing this update, I launch any of the two aforementioned games, moving the mouse around (yes, mouse movement) causes the game to freeze in 1 second intervals every time. If you don't move the mouse, game appears fine.

The above gamer is running a pretty stout system with a Ryzen Threadripper 2950X and a GeForce RTX 2080 Ti.

"I’ve got this same issue with an RTX2080 and Ryzen 2700X," added maverick26290, "Destiny 2 has some insane lag spikes when you move the mouse.

Also uninstalled this update and all is normal again." Yet another user, jenders37, wrote, "Having issues with this on several of my games as well. Destiny 2 was a NIGHTMARE, but as you said it resolved when removing the patch."

Hopping on over to the Destiny subreddit, it's more of the same, with jlobue10 writing:

I logged in to play some yesterday prior to Season of the Drifter starting this Tuesday and noticed my game was unusually sluggish. It also felt as though my mouse setting and sensitivity were messed up even though I had been comfortable with the settings I have for quite a long time now.

Now, Microsoft has officially chimed in an acknowledged that there is indeed a performance issue with KB4482887. The company confirms:

After installing KB4482887, users may notice graphics and mouse performance degradation with desktop gaming when playing certain games (eg: Destiny 2).

At this point, Microsoft says that it is working on a fix that would restore performance for affected gamers. In the meantime, Microsoft is suggesting that gamers who are experiencing issue uninstall KB4482887 for now, after which any performance lagging should be eliminated.

Microsoft has not said what is causing the problems, but many are speculating that it could be in relation to the Retpoline tweaks that were implemented with this latest cumulative update."

Another article here:
Microsoft warns of KB4482887 game performance issues
http://forum.notebookreview.com/threads/windows-10.762434/page-556#post-10878109


Remember, retpoline is really only attempting to claw back Windows performance lost due to patches for Spectre / Meltdown vulnerabilities. Felt worst on older gen CPUs, the original Spectre / Meltdown patches, resulted in slowdowns particularly in disc and network access. But now we see that the magic bullet dubbed KB4482887 might cause users to "notice graphics and mouse performance degradation with desktop gaming when playing certain games, such as Destiny 2."

...Looking around Reddit and Twitter one can't be certain if games other than Destiny 2 are affected, but it seems likely. In the meantime if your PC is adversely affected and you can't wait for a 'resolution' from Microsoft, it is OK to "uninstall KB4482887 to regain performance," says Microsoft in the patch release notes."

 

That comes as a big surprise, you don't seem mature enough to have that kind of experience. And you talking about clogging up threads with useless posts, yet you constantly spam other threads with anti Intel/NVidia and pro-AMD postings to the point that it's just spam, and also combined with your real need for having the last word. I'm surprised to hear your experience given your 'behaviour' on here...but it is what it is. I'll continue to post my own viewpoints on the topics in these forums, and in this thread too.

 

Well said. Nothing more to say from me.

 

Spoiler: Closing off the OT dialog

I am just as serious with my posts and comments about Intel, Nvidia, AMD, as I am here.

The amount of posts coincide with the amount of information being discussed with new releases, reviews, and owners feedback. There is a cycle to new product releases, and at times there is far more information being exchanged publicly and privately than others.

The "last word" is your imagination, as there are always ongoing discussions around the same subject going on all the time, even after my last posts.

The Pro-AMD comments are trying to keep AMD in the conversation while Intel and Nvidia are flooding the mind space with their marketing BS and deceptive spin. If thoughtful and objective people that consider all options and motivations for purchase didn't do that then Intel and Nvidia would have brainwashed everyone.

Sounds good, thanks to both of you for ending this useless OT dialog in this thread.

Please let's keep the security discussions serious, constructive, and on point as they should be for the sake of their scope and effect on people looking for information and help here.

There is plenty of Intel BS trying to minimize the real situation and try to downplay the problem, while caring nothing for their customers security exposure - only as far as they are forced to by the level of awareness and demand for fixes from their customers.

Raising the awareness and providing information is what we are trying to do here and in other threads here on NBR so members can know what's what when their only other source of information is Intel and Microsoft.

Posting minimization's and poo-pooing the potential effect of exploits not even out of the gate - before we know their full effect - so as to drive it out of the mind for real thought and consideration, is a disservice and a waste of everyone's time.

This threads discussion addresses the vast majority of computers used today, and wasting time mentioning air-gapped or otherwise "unassailable" computers as being unaffected is wasted discussion. As it is well known that "unassailable" vectors are also compromisable.

As with all security exploits access is key to deployment, and there are few if any consumers with computers that aren't connected to the internet, or don't use USB or other media - or the internet - to install software, all vectors providing access for infection through unpatched or unknown exploits.

All successful malware coming through browsers use exploits unpatched or unknown, which can deliver a payload that contains other unpatched or unknown exploits - including these new to public disclosure discoveries which may not be new at all, and in fact might already be used in the field.

* Here is the original post I made, 22 posts back:

http://forum.notebookreview.com/thr...atches-and-more.812424/page-120#post-10875985

SPOILER alert, literally: Intel CPUs afflicted with simple data-spewing spec-exec vulnerability
'Leakage ... is visible in all Intel generations starting from first-gen Core CPUs'
By Thomas Claburn in San Francisco 5 Mar 2019 at 06:34
https://www.theregister.co.uk/2019/03/05/spoiler_intel_processor_flaw/

148 Comments

Note: "The issue is separate from the Spectre vulnerabilities, and is not addressed by existing mitigations. It can be exploited from user space without elevated privileges."

Updated: Further demonstrating the computational risks of looking into the future, boffins have found another way to abuse speculative execution in Intel CPUs to steal secrets and other data from running applications.

--------

Intel CPUs Reportedly Vulnerable To New "SPOILER" Speculative Attack
Written by Michael Larabel in Security on 5 March 2019 at 09:28 AM EST. 66 Comments
https://www.phoronix.com/scan.php?page=news_item&px=Intel-SPOILER-Attack

"SPOILER is the newest speculative attack affecting Intel's micro-architecture.

Researchers out of the Worcester Polytechnic Institute and University of Lubeck discovered this new speculative attack dubbed SPOILER, Speculative Load Hazards Boost Rowhammer and Cache Attacks.

Intel was notified of this issue a few months ago but no software/hardware fix appears ready yet, while the researchers claim there might not be an effective software solution available at least anytime soon -- and any mitigation would likely come at a performance cost, as we've seen with Spectre and Meltdown over the past year.

AMD and ARM CPUs aren't believed to be impacted by SPOILER.

The SPOILER research paper can be read here:
https://arxiv.org/pdf/1903.00446.pdf

66 Comments
------

SPOILER alert, literally: Intel CPUs afflicted with simple data-spewing spec-exec vulnerability
submitted 5 days ago by alexeyr
https://www.reddit.com/r/programmin...er_alert_literally_intel_cpus_afflicted_with/
https://www.reddit.com/r/hardware/comments/axi1pn/spoiler_alert_intel_chips_hit_with_another/
https://www.reddit.com/r/intel/comments/axjk51/spoiler_alert_literally_intel_cpus_afflicted_with/
https://www.reddit.com/r/Intelligen...er_alert_literally_intel_cpus_afflicted_with/

 

Level1 News March 12 2019: SPOILER ALERT
41:10 - All Intel chips open to new Spoiler non-Spectre attack: Don't expect a quick fix

All Intel chips open to new Spoiler non-Spectre attack: Don't expect a quick fix
Researchers say Intel won't be able to use a software mitigation to fully address the problem Spoiler exploits.
By Liam Tung | March 5, 2019 -- 11:33 GMT (03:33 PST)
https://www.zdnet.com/article/all-i...r-non-spectre-attack-dont-expect-a-quick-fix/

Splork • 7 days ago
"Speculation abounds that Apple may be planning to ditch Intel processors. There is certainly a mountain of motivation to do so. Even AMD processors would be a welcomed change. I wonder if Intel can be sued for culpable negligence when their numerous vulnerabilities cost users and enterprises significant loss..."

 

Just a general heads up - pull'em out of the sand and patch your computers. This advice goes for individuals too.

Computers online appear the same, whether for business, gaming, browsing, or general use. All computers can be vulnerable.

Stop Contributing to the Global Cybercriminal Haul
Written by Eric Jacksch on 07 January 2019
POSTED IN SECURITY SHELF - ERIC JACKSCH
http://www.canadait.com/index.php/i...contributing-to-the-global-cybercriminal-haul

"According to a 2018 study led by Dr. Michael McGuire, Senior Lecturer in Criminology at the University of Surrey, worldwide cybercrime revenues are estimated at $1.5 trillion per year. In 2019, ...businesses of all sizes should take measures to stop contributing to the global cybercriminal haul.

APPLY PATCHES AND UPDATES
While exotic zero-day vulnerabilities grab headlines, in reality intruders frequently succeed by exploiting known security issues for which patches already exist. Unless patches are applied regularly, the resulting security landscape makes it far too easy for relatively unsophisticated cybercriminals to intrude into systems and steal data.

Spoiler: More...

Many organizations, both public and private, suffer from misaligned priorities. They deploy expensive security products, but neglect basics such as patching. Intrusion prevention and antimalware are important, but they do little to protect servers and PCs riddled with security holes.

While it is possible to keep systems up-to-date through diligent system administration practices, a variety of vulnerability and patch management tools are available to help. If your organization has not made software updates a security priority in the past, make it one for 2019.

HARDEN SERVERS
It is difficult to find security advice written in the past few decades that doesn’t include server hardening. Yet time and time again, security professionals and hackers find network services that shouldn’t be there in the first place, nevermind exposed to the network.

While legacy systems may present challenges, the majority of the time the real issue is that security is just not a priority. Insecure protocols such as FTP and telnet have no place on today’s systems. Unless the server is a file server, inbound connectivity to SMB ports should be blocked. While it might be more convenient for administrators to update web content via a Windows file share, it’s a poor security choice. SCP and SFTP are far more secure.

Server hardening also includes making privilege escalation more difficult. Web servers, databases, and similar applications should not run with administrative privileges, and when colocated on the server should be protected against each other. As an example, a database process should not have write access to a web server’s directories.

SECURITY AWARENESS TRAINING
Phishing and fraud are on the rise. Never in history has it been easier to research and target individuals and businesses, and criminals are getting much better at it. In the past, poor grammar and comically bad writing made fraudulent emails easier to spot. More recently, fraudsters have seriously improved their game. Employees today are receiving well-written emails, addressed to them by name, and purporting to be from managers and executives within their organization.

While technical controls can certainly help (it is amazing that in 2019 we don’t have a clear indicator of whether an email originated inside or outside our organization), the real key is security awareness training. In fact, training employees likely has a higher ROI than any other security expenditure.

MULTI-FACTOR AUTHENTICATION
Another opportunity to improve security this year is to adopt multi-factor authentication. Most major companies support it, and thanks to the standards charge lead by Google Authenticator, no extra hardware is required. Apps like Authy make it easy to manage multiple accounts and synchronize MFA credentials across multiple devices.

Low cost FIDO U2F and FIDO2 devices make hardware-based MFA simple and easy. A single device can be used to authenticate to an unlimited number of Internet sites and accounts.

Organizations should consider the services they use, and prioritize MFA starting with email and social media accounts. Those using cloud computing should, if they are not already, mandate the use of MFA for all administrator access.

BACKUPS
The final line of defence against a multitude of security incidents, including ransomware attacks, malicious insiders, hardware failures, and natural disasters, is recovering data from backups. Protecting data is an obvious business imperative, yet many business fail to adequately do so. This is particularly problematic for small businesses and individuals. Ironically, unprecedented Internet bandwidth and low-cost backup services make it easier than ever. At a cost of around $5 per PC for automatic, unlimited backup, there is simply no excuse."

 

Data-spewing Spectre chip flaws can't be killed by software alone, Google boffins conclude
While browsers have got their act together, any other apps interpreting user-supplied code need to be aware of this
By Thomas Claburn in San Francisco 18 Feb 2019 at 07:05
https://www.theregister.co.uk/2019/02/18/spectre_cant_be_killed/

"Google security researchers have analyzed the impact of the data-leaking Spectre vulnerabilities afflicting today's processor cores, and concluded software alone cannot prevent exploitation.

The Chocolate Factory brainiacs – Ross Mcilroy, Jaroslav Sevcik, Tobias Tebbi, Ben L. Titzer, Toon Verwaest – show that they can construct what's dubbed a universal gadget to exploit the spectre gang of speculative-execution flaws present in various CPU families, allowing attacker-supplied code running in a thread to read all memory in the same address space.

This means, for example, a malicious webpage's JavaScript code executing in a web browser thread can potentially snoop on another webpage's JavaScript running in another thread within the same process, and steal secret data from that other page.

There are already some mitigations in place in browsers, such as Chrome's Site Isolation that keeps webpages in separate processes, limiting what any malicious JavaScript can spy on. Firefox, Internet Explorer, and Edge, at least, block the use of JS object SharedArrayBuffer, which can be exploited to perform Spectre snooping.

However, the underlying threat is still there for any browsers and other applications interpreting attacker-supplied code. Language-based defenses and similar safeguards within a process can't stop Spectre; you have to go down to hardware-based separation using individual processes with their own individual virtual address spaces and hardware-enforced page tables.

Since there aren't many other scenarios in which attacker-supplied code is interpreted in the same address space as other user-supplied code – web browsers spring to mind, chiefly – the Googlers' research is largely academic, and not something to immediately panic over.

However, if you're developing software that interprets external code – such a cloud-based execution environment in which customers' threads share the same process – this is something to be very much aware of.

"We now believe that speculative vulnerabilities on today’s hardware defeat all language-enforced confidentiality with no known comprehensive software mitigations, as we have discovered that untrusted code can construct a universal read gadget to read all memory in the same address space through side-channels," the researchers say in a paper distributed through pre-print service ArXiv.

Shortly after The Register first reported the Spectre and Meltdown bugs in January 2018, University of Michigan assistant professor of computer science Daniel Genkin, a co-author of the original Spectre research paper who was a postdoctoral student at the time, said as much: "We are currently not aware of effective countermeasures that will eliminate the root cause of Spectre, short of hardware redesign," he told The Register last year.

Spectre, as its name suggests, involves the exploitation of speculative execution, a feature of modern processors that involves guessing the future path of a program and making anticipated calculations while the processor is busy with other tasks.

These calculations can be retained if the correct path was guessed, which saves time and hastens code execution. But as the Spectre flaws demonstrated, the ability to peer into the future can be abused.

There are several Spectre variants but the basic problem is that chip designers traded security for speed. "Our models, our mental models, are wrong; we have been trading security for performance and complexity all along and didn’t know it," the researchers observe.

Variant 4, Speculative Aliasing Confusion, has no software solution that Google's researchers could find. "Variant 4 defeats everything we could think of," the researchers say.

Initially, software and hardware makers pushed fixes like microcode updates and techniques like Retpoline. Browser makers Google and Mozilla made timing data less accessible, to make speculative execution attacks more difficult.

But that appears to be futile. "We argue that mitigating timing channels by manipulating timers is impossible, nonsensical, and in any case ultimately self-defeating," the researchers say.

Google's boffins added defenses against Spectre into the V8 JavaScript virtual machine within the company's Chrome browser and found the performance penalties frustrating because they slow things down without truly fixing the problem. "None of these mitigations provide comprehensive protection against Spectre, and so the mitigation space is a frustrating performance / protection trade-off," they say.

That's why Google shifted its browser security focus to the aforementioned site isolation. But help has to come from hardware, too, in the form of better process isolation.

Intel announced hardware fixes for some of the Spectre vulnerabilities in March 2018, but its claim that Spectre Variant 1 "will continue to be addressed via software mitigations" now looks rather dubious."

 

15 months after Spectre and Meltdown, the fixes are still flowing
By Simon Sharwood, Apr 8 2019, 11:16AM
https://www.crn.com.au/news/15-months-after-spectre-and-meltdown-the-fixes-are-still-flowing-523511

"The Spectre and Meltdown CPU design flaw bugs that emerged in early January 2018 are still creating work for users.

Cisco last week issued a Field Notice to users of its Content Delivery Engine products, hefty servers packed chock full of disks and I/O option to stream video across a LAN or the Internet, or enable services like cloud DVRs.

The Field Notice reveals that the devices are actually built on Intel CPUs and Supermicro servers, so are vulnerable to Spectre and Meltdown.

Or as Cisco puts it, “CDE250/460/465 systems use third party CPUs that are potentially vulnerable. However, these products are closed systems which do not allow custom code to be run on them. While these systems are not currently included in the vulnerable product list in the security advisory below, this BIOS update is available as a precautionary measure.”

So even though the devices are hard to penetrate, they've gone without specific remediation for 15 months. And Cisco thinks they might just need it.

Which is just a little bit terrifying as the official Meltdown and Spectre FAQ states:

Q: Has Meltdown or Spectre been abused in the wild?

A: We don't know.

And just to make things even more amusing, the FAQ also includes the following couplet.

Q: Can I detect if someone has exploited Meltdown or Spectre against me?

A: Probably not. The exploitation does not leave any traces in traditional log files.

Installing a new BIOS isn’t a quick job. And it’s understandable if users have stopped checking to see if server vendors, or third parties that pack servers into appliances, have issued any new fixes.

Cisco’s Field Notice is therefore a warning to both fix up any Content Delivery Engines you own, and revisit other product to see if any other Spectre and Meltdown fixes have landed lately."

Field Notice: FN - 70347 - VDS - CDE250/460/465 BIOS Updates for the CPU Meltdown/Spectre Issue - BIOS/Firmware Upgrade Recommended
Updated: April 3, 2019 Document ID: FN70347
https://www.cisco.com/c/en/us/support/docs/field-notices/703/fn70347.html

" Problem Description
To enhance security, new BIOS updates are available to further improve system resiliency against known security vulnerabilities identified as Meltdown and Spectre. CDE250/460/465 systems use third party CPUs that are potentially vulnerable. However, these products are closed systems which do not allow custom code to be run on them. While these systems are not currently included in the vulnerable product list in the security advisory below, this BIOS update is available as a precautionary measure.

Background
Please see link below for detailed information on CPU Side-Channel Information Disclosure Vulnerabilities:
https://tools.cisco.com/security/ce...rityAdvisory/cisco-sa-20180104-cpusidechannel

Problem Symptom
No symptoms are visible to the end user or administrator.

CSCvj56715 Intel Meltdown/Spectre BIOS Updates for the CDE250/460/465 systems"

 

Intel may never make a CPU we can trust, but others might
Jon Martindale, 04.6.19 - 1:00AM PST
https://www.digitaltrends.com/computing/sidestepping-solution-spectre-and-meltdown/

"Remember the Spectre and Meltdown security exploits from last year? Intel and AMD really hopes you don’t. Despite what they want you to believe, these speculative execution exploits aren’t going away, at least not with the solutions proposed so far.

Instead of trying to fix each variant that comes along, a permanent fix will require a fundamental change to how CPUs are designed. The proposition? A “secure core” that make ensure your data stays safe from attackers, no matter what bugs they might try to exploit.

It might not be the route these large processor companies want to take, but it might be the only one that actually works."

See site for full article...

 

AMD addresses Spoiler vulnerability: Ryzen users are safe from this one
By Eric Hamilton on March 17, 2019, 10:22 PM 10 comments
https://www.techspot.com/news/79234-amd-addresses-spoiler-vulnerability-ryzen-users-safe-one.html

"In context: Researchers continue to find ways to abuse and exploit speculative execution on modern CPUs. The newest vulnerability has been named "Spoiler," and while it'll likely be a thorn in Intel's side for some time to come with no viable solution, AMD's processors are unaffected claims the CPU maker.

Researchers at Worcester Polytechnic Institute in the US, and the University of Lübeck in Germany, recently discovered another speculative execution vulnerabilityimpacting Intel processors. Dubbed "Spoiler," and like Spectre before it, the flaw preys upon the CPU's speculative execution engine that presciently guesses upcoming computations to boost performance.

As the research paper explains, Spoiler is entirely independent from Spectre, so existing mitigations for Spectre and Meltdown have no effect on the new flaw. Spoiler is a complicated problem, but the paper offers a summary of sorts.

We have discovered a novel microarchitectural leakage which reveals critical information about physical page mappings to user space processes. The leakage can be exploited by a limited set of instructions, which is visible in all Intel generations starting from the 1st generation of Intel Core processors, independent of the OS and also works from within virtual machines and sandboxed environments.

The researchers also tested AMD and ARM-based processors, but found that they were not susceptible in the same way Intel's processors are. This makes Spoiler a problem unique to Intel, and it's already found itself reeling after the frenzy that wasSpectre and Meltdown. And just like those two flaws, there's no viable software-only mitigation; microarchitecure level changes could help, but it'd come at the cost of performance.

No doubt relieved, AMD has confirmed Spoiler does not impact Ryzen processors.

We are aware of the report of a new security exploit called SPOILER which can gain access to partial address information during load operations. We believe that our products are not susceptible to this issue because of our unique processor architecture. The SPOILER exploit can gain access to partial address information above address bit 11 during load operations. We believe that our products are not susceptible to this issue because AMD processors do not use partial address matches above address bit 11 when resolving load conflicts.

While AMD did have to issue some mitigations for Spectre, they seem to have dodged a bullet here. The same can't be said for Intel, unfortunately, who will have to continue to analyze their CPU design at the silicon level for improved security in the future."

 

Intel finally issues Spoiler attack alert: Now non-Spectre exploit gets CVE but no patch
No patch for Spoiler attack affecting all Intel chips, but a security advisory gives it an official CVE identifier CVE-2019-0162.
By Liam Tung | April 10, 2019 -- 11:23 GMT (04:23 PDT)
https://www.zdnet.com/article/intel...ow-non-spectre-exploit-gets-cve-but-no-patch/

"Intel has finally posted an official security advisory in response to the recently revealed Spoiler attack, which uses a weakness in Intel CPUs to enhance already known attacks that leak secrets from memory.

Researchers from Worcester Polytechnic Institute, Massachusetts, and the University of Lübeck in north Germany in March drew attention to a weakness in Intel's proprietary memory subsystem that affects Intel CPUs all the way back to its 1st generation Intel Core processors, regardless of the operating system.

An attacker with low privileges can use Spoiler to learn a system's virtual address mapping to physical memory addresses, Intel said in an assessment, which stressed that Spoiler itself doesn't reveal secret data.

Spoiler is not a speculative execution side-channel attack like Spectre v2, which could leak secrets like passwords. However, Spoiler does lower the bar for other known memory-leaking attack techniques, such as Rowhammer bit-flipping in memory chips, and classic side-channel attacks.

Intel initially didn't say much about Spoiler's impact, except that it believed software can be shielded against Spoiler issues by employing "side-channel safe software development practices" and that DRAM modules with Rowhammer mitigations should remain protected.

Rowhammer mitigations include ECC or Error-Correcting Code memory, used in RAM for mission-critical systems. Researchers recently showed that ECC in DDR3 and possibly DDR4 is fairly brittle in the face of a specific Rowhammer attack. If it triggered three simultaneous bit flips ECC could be completely bypassed.

Intel has now assigned the vulnerability identifier CVE-2019-0162 to Spoiler and given it a CVSS severity score of 3.8 out of a possible 10. The 'low' severity rating is likely because an attacker would need to be authenticated and have local access to the hardware, while existing mitigations further reduce risks.

"Memory access in virtual memory mapping for some microprocessors may allow an authenticated user to potentially enable information disclosure via local access," Intel notes in its advisory.

The researchers who discovered Spoiler predicted the chip maker would be unable to patch its memory subsystem with microcode any time soon without "losing tremendous performance".

Indeed, Intel doesn't have a patch but points to documents detailing 'Security Best Practices For Side Channel Resistance' and 'Guidelines for Mitigating Timing Side Channels Against Cryptographic Implementations'.

"Intel recommends that users follow existing best practices to mitigate exploitation of this vulnerability," it notes

In a separate document, Intel says its kernel protections, such as the kernel page-table isolation (KPTI) mitigation against the Meltdown CPU attack, does "reduce the risk of leaking data across privilege levels".

"After careful assessment, Intel has determined that existing kernel protections, like KPTI, reduce the risk of leaking data across privilege levels," Intel notes.

"Combined with side-channel safe software development practices, like ensuring execution time and control flows are identical regardless of secret data, these protections mitigate classic side-channel methods enabled by the Spoiler exploit. Additionally, DRAM modules that are mitigated against Rowhammer-style attacks remain protected regardless of the Spoiler exploit."

Spoiler: MORE ON INTEL, SPOILER AND SPECTRE

• All Intel chips open to new Spoiler non-Spectre attack: Don't expect a quick fix
• Microsoft rolls out Google's Retpoline Spectre mitigation to Windows 10 users
• Researchers discover SplitSpectre, a new Spectre-like CPU attack
• Researchers discover seven new Meltdown and Spectre attacks
• Linus Torvalds: After big Linux performance hit, Spectre v2 patch needs curbs
• Intel ditches Linux patch benchmark 'gag', offers 'innocuous' new license
• New Spectre variant 4: Our patches cause up to 8% performance hit, warns Intel
• Critical flaws revealed to affect most Intel chips since 1995
• Got an old PC? Find out whether you will get Intel's latest Spectre patch TechRepublic
• Class-action suits over Intel Spectre, Meltdown flaws surge CNET

 

New secret-spilling flaw affects almost every Intel chip since 2011
Zack Whittaker @zackwhittaker / 17 hours ago
https://techcrunch.com/2019/05/14/zombieload-flaw-intel-processors/

"Security researchers have found a new class of vulnerabilities in Intel chips which, if exploited, can be used to steal sensitive information directly from the processor.,

The bugs are reminiscent of Meltdown and Spectre, which exploited a weakness in speculative execution, an important part of how modern processors work.

Speculative execution helps processors predict to a certain degree what an application or operating system might need next and in the near-future, making the app run faster and more efficient. The processor will execute its predictions if they’re needed, or discard them if they’re not.

Both Meltdown and Spectre leaked sensitive data stored briefly in the processor, including secrets — such as passwords, secret keys and account tokens, and private messages.

Now some of the same researchers are back with an entirely new round of data-leaking bugs.

“ZombieLoad,” as it’s called, is a side-channel attack targeting Intel chips, allowing hackers to effectively exploit design flaws rather than injecting malicious code. Intel said ZombieLoad is made up of four bugs, which the researchers reported to the chip maker just a month ago.

Almost every computer with an Intel chips dating back to 2011 are affected by the vulnerabilities. AMD and ARM chips are not said to be vulnerable like earlier side-channel attacks.

Spoiler

ZombieLoad takes its name from a “zombie load,” an amount of data that the processor can’t understand or properly process, forcing the processor to ask for help from the processor’s microcode to prevent a crash. Apps are usually only able to see their own data, but this bug allows that data to bleed across those boundary walls. ZombieLoad will leak any data currently loaded by the processor’s core, the researchers said. Intel said patches to the microcode will help clear the processor’s buffers, preventing data from being read.

Practically, the researchers showed in a proof-of-concept video that the flaws could be exploited to see which websites a person is visiting in real-time, but could be easily repurposed to grab passwords or access tokens used to log into a victim’s online accounts.

Like Meltdown and Spectre, it’s not just PCs and laptops affected by ZombieLoad — the cloud is also vulnerable. ZombieLoad can be triggered in virtual machines, which are meant to be isolated from other virtual systems and their host device.

Daniel Gruss, one of the researchers who discovered the latest round of chip flaws, said it works “just like” it does on PCs and can read data off the processor. That’s potentially a major problem in cloud environments where different customers’ virtual machines run on the same server hardware.

Although no attacks have been publicly reported, the researchers couldn’t rule them out nor would any attack necessarily leave a trace, they said.

What does this mean for the average user? There’s no need to panic, for one.

These are far from drive-by exploits where an attacker can take over your computer in an instant. Gruss said it was “easier than Spectre” but “more difficult than Meltdown” to exploit — and both required a specific set of skills and effort to use in an attack.

But if exploit code was compiled in an app or delivered as malware, “we can run an attack,” he said.

There are far easier ways to hack into a computer and steal data. But the focus of the research into speculative execution and side channel attacks remains in its infancy. As more findings come to light, the data-stealing attacks have the potential to become easier to exploit and more streamlined.

But as with any vulnerability where patches are available, install them.

Intel has released microcode to patch vulnerable processors, including Intel Xeon, Intel Broadwell, Sandy Bridge, Skylake and Haswell chips. Intel Kaby Lake, Coffee Lake, Whiskey Lake and Cascade Lake chips are also affected, as well as all Atom and Knights processors.

But other tech giants, like consumer PC and device manufacturers, are also issuing patches as a first line of defense against possible attacks.

Computer makers Apple and Microsoft and browser makers Google have released patches, with other companies expected to follow.

In a call with TechCrunch, Intel said the microcode updates, like previous patches, would have an impact on processor performance. An Intel spokesperson told TechCrunch that most patched consumer devices could take a 3 percent performance hit at worst, and as much as 9 percent in a datacenter environment. But, the spokesperson said, it was unlikely to be noticeable in most scenarios.

And neither Intel nor Gruss and his team have released exploit code, so there’s no direct and immediate threat to the average user.

But with patches rolling out today, there’s no reason to pass on a chance to prevent such an attack in any eventuality.

I haven't seen a customer facing Intel firmware patch download yet... I'll update if I see it.

" Intel has released microcode updates to motherboard and OEM firmware vendors already, and they should be made available to users as part of OEM firmware updates in the future."
https://www.zdnet.com/article/how-to-test-mds-zombieload-patch-status-on-windows-systems/

Apple, Amazon, Google, Microsoft and Mozilla release patches for ZombieLoad chip flaws
Zack Whittaker @zackwhittaker / 17 hours ago
https://techcrunch.com/2019/05/14/intel-chip-flaws-patches-released/

"Big tech is stepping in to patch newly disclosed security flaws affecting almost every Intel chip since 2011.

Spoiler

Researchers on Tuesday released details of the vulnerability, known as ZombieLoad — or microarchitectural data sampling (MDS) as its technical name — which can leak sensitive data stored in the processor, such as passwords, secret keys and account tokens and private messages.

You can read our coverage here. In short, don’t panic — but you should patch your systems. Here’s how.

Apple released macOS fixes
Apple has fixes out for every Mac and MacBook released during and after 2011.

The tech giant said in an advisory that any system running macOS Mojave 10.14.5, released Monday, is patched. This will prevent an attack from being run through Safari and other apps. Most users won’t experience any decline in performance. But some Macs could face up to a 40% performance hit for those who opt-in to the full set of mitigations.

The security update will also be pushed to Sierra and High Sierra versions. iPhones, iPads and Apple Watch devices aren’t affected by the bugs.

Google patches Android, will update Chrome
The search and browser maker also confirmed it has released patches to mitigate against ZombieLoad.

Google said the “vast majority” of Android devices aren’t affected but Intel-only devices will need to be patched once device makers make updates available.

Chrome OS devices, such as Chromebooks, are already protected in the latest version, and permanent mitigations will be pushed to devices in the next version.

And, the company’s Chrome team has a technical advisory out, but said users should rely on patches for their computer. “Operating system vendors may release updates to improve isolation, so users should ensure they install any updates and follow any additional guidance from their operating system vendor,” said Google. In other words, make sure your Windows PC or your Mac is patched.

Google also rolled out patches to its data centers, so cloud customers are already patched, but should be aware of the company’s guidance.

Mozilla plans long-term Firefox fix
Firefox browser maker Mozilla said it’s got a long-term fix on the way.

“Firefox has applied the mitigation recommended by Apple on macOS,” said a Mozilla spokesperson. “The macOS mitigation will be part of our upcoming Firefox release (67) and Extended Support Release update (60.7), both scheduled for May 21.”

“Firefox Beta and Firefox Nightly already include the change,” the spokesperson said, adding that no action was recommended for browsers on Windows and Linux.

Microsoft rolls out Windows updates
Microsoft has released patches for its operating system and cloud.

Jeff Jones, a senior director at Microsoft, said the software and cloud giant has been “working closely with affected chip manufacturers to develop and test mitigations” for its customers. “We are working to deploy mitigations to cloud services and release security updates to protect Windows customers against vulnerabilities affecting supported hardware chips,” he said.

In a TechNet article, the company said customers may need to obtain directly from their device maker microcode updates for their processor. Microsoft is pushing many of the microcode updates itself through Windows Update, but they are also available from its website.

Software updates will be released Tuesday also through Windows Update. Microsoft also has a page with guidance for how to protect against the new attacks.

Microsoft Azure customers are already protected, the company said.

Amazon patches AWS
A spokesperson for Amazon has confirmed its cloud service Amazon Web Services has been updated to prevent attacks.

“AWS has designed and implemented its infrastructure with protections against these types of bugs, and has also deployed additional protections for MDS,” said an advisory posted on Amazon’s website. “All EC2 host infrastructure has been updated with these new protections, and no customer action is required at the infrastructure level.”

Updated article and headline to include remarks from Amazon and Mozilla.

Read more:

• New secret-spilling flaws affect almost every Intel chip since 2011
• Intel announces hardware fixes for Spectre and Meltdown on upcoming chips
• Apple issues Meltdown fix for Macs running Sierra and El Capitan
• Google claims its Spectre and Meltdown mitigation results in no performance degradation
• Intel tried desperately to change the subject from Spectre and Meltdown at CES
• Intel CEO: Meltdown and Spectre patches will come to 90%+ of chips in the next week

How to test MDS (Zombieload) patch status on Windows systems
PowerShell script tells you if you're Windows OS is safe from MDS attacks.
By Catalin Cimpanu for Zero Day | May 15, 2019 -- 00:49 GMT (17:49 PDT)
https://www.zdnet.com/article/how-to-test-mds-zombieload-patch-status-on-windows-systems/

" Four MDS attacks have been revealed today, with Zombieload considered the most dangerous of them all:

• CVE-2018-12126 - Microarchitectural Store Buffer Data Sampling (MSBDS) [codenamed Fallout] 
• CVE-2018-12127 - Microarchitectural Load Port Data Sampling (MLPDS) [codenamed RIDL] 
• CVE-2018-12130 - Microarchitectural Fill Buffer Data Sampling (MFBDS) [codenamed Zombieload, but also RIDL] 
• CVE-2018-11091 - Microarchitectural Data Sampling Uncacheable Memory (MDSUM) [codenamed RIDL]

To safeguard systems, users must install Intel CPU microcode updates, but also OS-level updates. Microsoft, along with other OS makers, have already released OS patches today.

Intel has released microcode updates to motherboard and OEM firmware vendors already, and they should be made available to users as part of OEM firmware updates in the future.

Last year, Microsoft released a PowerShell script to help system administrators detect if Meltdown and Spectre patches have installed and are working correctly.

Today, Microsoft updated that same script to support the new MDS attacks, which just like the Meltdown and Spectre vulnerabilities, are also flaws in the speculative execution process, and can be detected the same way.

Below are the steps to download and use the PowerShell script, as well as information to the way results should be interpreted.

Spoiler

1) Open a PowerShell terminal with admin rights. You can do this by clicking the Start button, searching for " Windows PowerShell," right-clicking the option, and selecting " Run as Administrator."



2) In the PowerShell terminal, enter " $SaveExecutionPolicy = Get-ExecutionPolicy".

This will save your current PowerShell execution policy (access rights) to a variable, so you can restore it later.

3) In the PowerShell terminal, enter " Set-ExecutionPolicy RemoteSigned -Scope Currentuser". Don't forget to enter "Y" and then press Enter. If that doesn't work, replace Currentuser with Unrestricted.

4) In the PowerShell terminal, enter " Install-Module SpeculationControl". This command will download and install Microsoft's speculative execution status check script.

5) In the PowerShell terminal, enter " Get-SpeculationControlSettings". This will produce a report like the following:

Sections A and B are practically the same, with section A providing a reasonable explanation of what's currently installed on the system. But for clarity, we've pulled Microsoft's explanations for each of these three checks.

MDSWindowsSupportPresent or "Windows OS support for MDS mitigation is present"

"This line tells you if the Windows operating system support for the Microarchitectural Data Sampling (MDS) operating system mitigation is present. If it is True, the May 2019 update is installed on the device, and the mitigation for MDS is present. If it is False, the May 2019 update is not installed, and the mitigation for MDS is not present."

MDSHardwareVulnerable or "Hardware is vulnerable to MDS"

"This line tells you if the hardware is vulnerable to Microarchitectural Data Sampling (MDS) set of vulnerabilities (CVE-2018-11091, CVE-2018-12126, CVE-2018-12127, CVE-2018-12139). If it is True, the hardware is believed to be affected by these vulnerabilities. If it is False, the hardware is known to not be vulnerable."

MDSWindowsSupportEnabled or "Windows OS support for MDS mitigation is enabled"

"This line tells you if the Windows operating system mitigation for Microarchitectural Data Sampling (MDS) is enabled. If it is True, the hardware is believed to be affected by the MDS vulnerabilities, the windows operating support for the mitigation is present, and the mitigation has been enabled. If it is False, either the hardware is not vulnerable, Windows operating system support is not present, or the mitigation has not been enabled."

6) In the PowerShell terminal, enter " Set-ExecutionPolicy $SaveExecutionPolicy -Scope Currentuser" to restore your system's original PowerShell execution policy. If you want to be safe, just use " Set-ExecutionPolicy -ExecutionPolicy Restricted".

If patches have not been installed, the team of security researchers who uncovered the MDS attacks recommend disabling the Simultaneous Multi-Threading (SMT) feature on Intel CPUs will significantly reduce the impact of all MDS attacks."

 

Do you remember Intel's advertising specifically claiming how secure they were? At this point, it is pretty obvious they sacrificed security for performance, or, sometimes it seems, for no reason at all!

 

Had the patch available for download yesterday from Windows Update and ran it.

Edit: Also updated the ME with the firmware tool and BIOS. Lost 0 points in TimeSpy Physics test, gained 15 points in Cinebench run from my initial testing at 9900K launch though as always there is variability in that test and multiple runs, tested a few games and 0 performance loss.

Official public statement from Intel

https://www.intel.com/content/www/us/en/architecture-and-technology/mds.html

Is Intel recommending that I disable HT?
No. Intel is not recommending that users disable Intel® Hyper threading. It’s important to understand that doing so does not alone provide protection against MDS, and may impact workload performance or resource utilization that can vary depending on the workload.

Is this mitigated in future hardware?
Yes. MDS vulnerabilities are addressed by hardware changes with select 8th and 9th Generation Intel® Core™ processors, as well as the 2nd Generation Intel® Xeon® Scalable Processor Family. We expect all future processors will include hardware mitigations addressing these vulnerabilities.

More information can be found by going here.

https://support.microsoft.com/en-gb/help/4494441/windows-10-update-kb4494441 -- Here is your Windows update if you don't get it via automatic download option in Windows.

 

Note that the newest vulnerability Intel microcode patches (listed first below) do not include the latest build of Windows 10 1809 or 1803, the latest Windows version Intel microcode patch for Zombieload is for Windows 10 1709. Previous vulnerabilities do have Intel microcode patches for 1809/1803 and 1803 only and are listed below in 2 groupings.

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

[Zombieload]
"Microsoft is making available Intel-validated microcode updates that are related to Microarchitectural Data Sampling ( CVE-2019-11091, CVE-2018-12126, CVE-2018-12127, CVE-2018-12130).

The following table lists specific Microsoft Knowledge Base articles by Windows version. The article contains links to the available Intel microcode updates by CPU.

KB number and description Windows version Source
KB4494452 Intel microcode updates Windows 10, version 1709, and Windows Server 2016, version 1709 Microsoft Update Catalog
KB4494453 Intel microcode updates Windows 10, version 1703 Microsoft Update Catalog
KB4494175 Intel microcode updates Windows 10, version 1607, and Windows Server 2016 Microsoft Update Catalog
KB4494454 Intel microcode updates Windows 10 (RTM) Microsoft Update Catalog

We will offer additional Intel-validated microcode updates for Windows as they become available to Microsoft, and update these articles accordingly.

Customers should refer to information from Intel and their device manufacturer about the availability of applicable firmware security updates for the specific device, including the Intel Microcode Revision Guidance (April 2, 2018), Intel Microcode Revision Guidance (August 8, 2018), and Intel Microcode Revision Guidance (May 14, 2019)."

"Microsoft is making available Intel-validated microcode updates that are related to Spectre Variant 3a (CVE-2018-3640: "Rogue System Register Read (RSRE)"), Spectre Variant 4 (CVE-2018-3639: "Speculative Store Bypass (SSB)"), and L1TF (CVE-2018-3620, CVE-2018-3646: "L1 Terminal Fault").

The following table lists specific Microsoft Knowledge Base articles by Windows version. The article contains links to the available Intel microcode updates by CPU.

KB number and description Windows version Source
KB4465065 Intel microcode updates Windows 10, version 1809, Windows Server 2019 Microsoft Update Catalog
KB4346084 Intel microcode updates Windows 10, version 1803, and Windows Server, version 1803 Microsoft Update Catalog
KB4346085 Intel microcode updates Windows 10, version 1709, and Windows Server 2016, version 1709 Microsoft Update Catalog
KB4346086 Intel microcode updates Windows 10, version 1703 Microsoft Update Catalog
KB4346087 Intel microcode updates Windows 10, version 1607, and Windows Server 2016 Microsoft Update Catalog
KB4346088 Intel microcode updates Windows 10 (RTM) Microsoft Update Catalog"

"Microsoft is making available Intel-validated microcode updates that are related to Spectre Variant 2 (CVE 2017-5715 [“Branch Target Injection”]).

The following table lists specific Microsoft Knowledge Base articles by Windows version. The article contains links to the available Intel microcode updates by CPU:

KB Number and Description Windows Version Source
KB4100347 Intel Microcode Updates
Windows 10, version 1803, and Windows Server, version 1803
Windows Update, Windows Server Update Service, and Microsoft Update Catalog

KB4090007 Intel Microcode Updates
Windows 10, version 1709, and Windows Server 2016, version 1709
Windows Update, Windows Server Update Service, and Microsoft Update Catalog

KB4091663 Intel Microcode Updates
Windows 10, version 1703
Windows Update, Windows Server Update Service, and Microsoft Update Catalog

KB4091664 Intel Microcode Updates
Windows 10, version 1607, and Windows Server 2016
Windows Update, Windows Server Update Service, and Microsoft Update Catalog

KB4091666 Intel Microcode Updates
Windows 10 (RTM)
Windows Update, Windows Server Update Service, and Microsoft Update Catalog"

Thanks to @Papusan for this notification for users of the Microsoft Insider program that may receive Intel Microcode for Zombieload for their supported CPU through the Insiders Program Windows Update, see below:

Spoiler

Windows 10 Insider Preview for KB4497165: Intel microcode updates
Applies to: Windows Server, version 1903 Windows 10, version 1903
https://support.microsoft.com/en-us/help/4497165/kb4497165-intel-microcode-updates

Summary
Intel recently announced that it has completed software validations and has started to release new microcode for current CPU platforms in reaction to the following threats:

• CVE-2019-11091 – Microarchitectural Data Sampling Uncacheable Memory (MDSUM)
• CVE-2018-12126 – Microarchitectural Store Buffer Data Sampling (MSBDS)?
• CVE-2018-12127 – Microarchitectural Load Port Data Sampling (MLPDS)
• CVE-2018-12130 – Microarchitectural Fill Buffer Data Sampling (MFBDS)

This new release is provided to Window Insider program Slow, Fast, and Release Preview rings, and [see supported CPU list for your CPU] includes a microcode update from Intel for the following CPUs. [There is no direct download for your Windows 10 OS Insider release, if available it will be provided by Windows Update - Insider ring]

Important - Install this update for the listed processors only.

[The list of supported CPU's is extremely long, please go to the above URL to find out if your CPU is supported.]

This update is a standalone update that is targeted at Windows 10, version 1903 and Windows Server 2019, version 1903. This update also includes Intel microcode updates that were already released for these operating systems at the time of release to manufacturing (RTM).

We will offer additional microcode updates from Intel through this article for these operating systems as they become available to Microsoft. Use the registry settings as described in the Windows client and Windows Server KB articles. (By default, these registry settings are enabled for Windows client OS editions and Windows Server OS editions.)

Consult with your device manufacturer and Intel through their websites regarding their microcode recommendation for your device before you apply this update to your device.

How to obtain and install the update
Microsoft Update Catalog
To get the standalone package for this update, go to the Microsoft Update Catalog website. [Again, if your CPU is supported - see list - and a microcode patch exists from Intel it will be applied via Microsoft Insider Updates through Windows Update]

 

Lots of interesting details in that article, it's not in English, I used Google Translate (right click in Chrome Browser).

VU discovers megaleak in Intel chips
Leaky hardware thanks to a mistake, the VU uncovered a mega-leak in Intel chips. Intel pays the price for a fast but risky design.
Marc Hijink, May 14, 2019
https://www.nrc.nl/nieuws/2019/05/14/hackers-mikken-op-het-intel-hart-a3960208

"The news in brief :

• Researchers from the VU University Amsterdam have found an extensive data breach that is present in all Intel processors. These chips are in more than 80 percent of all computers and servers.
• On Tuesday evening, Intel and VU announced the details of RIDL (Rogue In-Flight Data Load), a vulnerability that allows malicious parties to steal "almost all data" from computers. Unauthorized persons can view the data that the processor is currently processing.
• The vulnerability is in all Intel processors of the last ten years - including the very latest. Hackers can exploit the vulnerability by hiding code in a web advertisement."

...
RIDL, as the new vulnerability was baptized, came to light by chance. On Tuesday 11 September, Stephan van Schaik, Computer Science student at VU University Amsterdam, worked on his study assignment: investigating a leak in the Intel processor.
...
Premium with aftertaste
Although parts of the leak were found by several researchers from different universities and companies, the VU has discovered the majority. Amsterdam University is also the only party to receive a reward: $ 100,000 (89,000 euros), Intel's maximum reward for discoverers of critical leaks.

There is a small taste to the premium. According to the VU, Intel tried to downplay the severity of the leak by officially paying $ 40,000 in rewards and in addition, "$ 80,000" off. That offer was politely refused.

Anyone who accepts a reward must also adhere to the rules. In this case, that meant: no consultation between researchers and uncertainty about which software manufacturers were warned in advance.According to the researchers, tech companies do not reason in the interests of the user, but of the shareholder.

Intel initially failed to notify Google and Mozilla, two major browser manufacturers.

The VU tried to force the manufacturer to come out faster. Eventually the VU forced Intel to come out in May - otherwise the university would publish the details itself. "If it were up to Intel, they would have wanted to wait another six months," says Bos.

Intel had promised that the next generation of chips would not be vulnerable to RIDL, but that is not the case."

 

Intel may also want to update their marketing campaign to better reflect the times.

 

Isn't ZombieLoad the same as MDS?

Someone should replace it with RIDL

 

0:32 - New Intel firmware boot verification bypass enables low-level backdoors

New Intel firmware boot verification bypass enables low-level backdoors
By replacing a PC's SPI flash chip with one that contains rogue code, an attacker can can gain full, persistent access
By Lucian Constantin, Romania Correspondent, CSO | MAY 10, 2019 11:04 AM PT
https://www.csoonline.com/article/3...ation-bypass-enables-low-level-backdoors.html

"Researchers have found a new way to defeat the boot verification process for some Intel-based systems, but the technique can also impact other platforms and can be used to compromise machines in a stealthy and persistent way.

Spoiler: Long - scary but not surprising

Researchers Peter Bosch and Trammell Hudson presented a time-of-check, time-of-use (TOCTOU) attack against the Boot Guard feature of Intel's reference Unified Extensible Firmware Interface (UEFI) implementation at the Hack in the Box conference in Amsterdam this week.

Boot Guard is a technology that was added in Intel Core 4th generation microarchitecture -- also known as Haswell -- and is meant to provide assurance that the low-level firmware (UEFI) has not been maliciously modified. It does this by checking that the loaded firmware modules are digitally signed with trusted keys that belong to Intel or the PC manufacturer every time the computer starts.

Bosch, an independent researcher and computer science student at Leiden University in the Netherlands, discovered an anomaly in the Boot Guard verification process while he was trying to find a way to use the open-source Coreboot firmware on his own laptop. In particular, he noticed that after the system verified the firmware and created a validated copy in cache, it later re-read modules from the original copy located in the Serial Peripheral Interface (SPI) memory chip -- the chip that stores the UEFI code.

This isn't correct behavior, because the system should only rely on the verified copy after the cryptographic checks are passed. This made Bosch think there might be an opportunity for an attacker to modify the firmware code after it's been verified and before it's incorrectly re-read from SPI memory. He took his findings and an early proof-of-concept implementation to Trammell Hudson, a well-known hardware and firmware researcher whose previous work includes the Thunderstrike attacks against Apple's Thunderbolt technology.

Hudson confirmed Bosch's findings and together worked on an attack that involves attaching a programming device to the flash memory chip to respond with malicious code when the CPU attempts to reread firmware modules from SPI memory instead of the validated copy. The result is that malicious and unsigned code is executed successfully, something that Boot Guard was designed to prevent.

While the attack requires opening the laptop case to attach clip-on connectors to the chip, there are ways to make it permanent, such as replacing the SPI chip with a rogue one that emulates the UEFI and also serves malicious code.

In fact, Hudson has already designed such an emulator chip that has the same dimensions as a real SPI flash chip and could easily pass as one upon visual inspection if some plastic coating is added to it.

What are the implications of such TOCTOU attacks?

The Intel Boot Guard and Secure Boot features were created to prevent attackers from injecting malware into the UEFI or other components loaded during the booting process such as the OS bootloader or the kernel. Such malware programs have existed for a long time and are called boot rootkits, or bootkits, and attackers have used them because they are very persistent and hard to remove. That's because they re-infect the operating system after every reboot before any antivirus program has a chance to start and detect them.

In its chip-swapping variant, Hudson's and Bosch's attack acts like a persistent hardware-based bootkit. It can be used to steal disk encryption passwords and other sensitive information from the system and it's very hard to detect without opening the device and closely inspecting its motherboard.

Even though such physical attacks require a targeted approach and will never be a widespread threat, they can pose a serious risk to businesses and users who have access to valuable information.

Such a physical compromise could occur in different ways, for example in an Evil-Maid-type scenario where a high value target, like a company's CEO, travels to a foreign country and leaves their laptop unattended in their hotel room. Bosch tells CSO that replacing the SPI memory chip with a rogue one designed to execute this attack would take 15 to 20 minutes for an experienced attacker with the right equipment.

Another possibility are supply chain attacks or the so-called "interdiction" techniques where computer shipments are intercepted in transit, for example by an intelligence agency, are backdoored and then resealed to hide any tampering. The documents leaked by Edward Snowden showed that the NSA uses such techniques, and it is likely not the only intelligence agency to do so.

Some devices do have tamper-evident seals or mechanisms, but someone with the right resources and knowledge can easily bypass those defenses, Bosch tells CSO.

Malicious employees could also use this technique on their work-issued laptops to either bypass access controls and gain administrator privileges or to maintain access to the company's data and network after they leave the company. Such a compromise would survive the computer being wiped and being put back into use.

There have been several cases over the years of economic espionage where employees working for various companies were caught stealing trade secrets and passing them to foreign governments or to competitors.

What is the mitigation?
The two researchers notified Intel of their findings in January and tell CSO that the chipmaker treated the issue seriously and assigned a high severity to it. The company already has patches available for its reference UEFI implementation -- known as Tianocore -- that it shares with BIOS vendors and PC manufacturers. The researchers haven't yet tested the fixes, but at least based on the description they seem comprehensive and should prevent similar attacks in the future.

The problem is that distributing UEFI patches has never been an easy process. Intel shares its UEFI kit with UEFI/BIOS vendors who have contracts with various PC manufacturers. Those OEMs then make their own firmware customizations before they ship it inside their products. This means that any subsequent fixes require collaboration and coordination from all involved parties, not to mention end users who need to actually care enough to install those UEFI updates.

The patches for the critical Meltdown and Spectre vulnerabilities that affected Intel CPUs also required UEFI updates and it took months for some PC vendors to release them for their affected products. Many models never received the patches in the form of UEFI updates because their manufacturers no longer supported them.

The two researchers plan to release their proof-of-concept code in the following months as part of a tool called SPISpy that they hope will help other researchers and interested parties to check if their own machines are vulnerable and to investigate similar issues on other platforms.

"I would really like to see the industry move towards opening the source to their firmware, to make it more easy to verify its correctness and security," says Bosch.

 

Tbh it'd be pretty surprising if you couldn't compromise a system by desoldering and replacing physical firmware rom chips but I guess the secure boot stuff is designed to stop exactly that... So oops.

I'd just like to see some of these vulnerabilities used for some useful backdoor things for us pleb consumers such as bypassing firmware blocks and whitelist mechanisms (gstink), microcode hacks like the old unlocked multiplier one, unlock arbitrarily disabled features, enable unofficial upgrades etc

 

There are a huge number of graphs in the article, please go to the site to see them. Perhaps tomorrow he will have the runs without HT enabled up for comparison.

MDS / Zombieload Mitigations Come At A Real Cost, Even If Keeping Hyper Threading On
Written by Michael Larabel in Linux Security on 16 May 2019 at 03:37 PM EDT. 50 Comments
https://phoronix.com/scan.php?page=news_item&px=MDS-Zombieload-Initial-Impact

"The default Linux mitigations for the new Microarchitectural Data Sampling (MDS) vulnerabilities (also known as "Zombieload") do incur measurable performance cost out-of-the-box in various workloads.

That's even with the default behavior where SMT / Hyper Threading remains on while it becomes increasingly apparent if wanting to fully protect your system HT must be off.

MDS was announced on Tuesday and I am running a number of MDS/Zombieload mitigation benchmarks including the likes now of comparing the overall Spectre/Meltdown/L1TF/MDS impact and also if going the "full" route of disabling Hyper Threading.

Tomorrow will be the first featured (multi-page) article with MDS data on multiple systems while here are some initial numbers I am seeing when just looking at the new default cost of this MDS mitigation.

Obviously if going the route of disabling Hyper Threading, the multi-threaded workloads will be even more impacted. Stay tuned for the complete scoop that should be out tomorrow on the initial batch of MDS mitigation testing."
50 Comments

aphysically
Junior Member Join Date: May 2019 Posts: 5 #6 05-16-2019, 04:07 PM
"One of the Intel writeups said that their 8th and 9th gen processors have hardware mitigations, but my 8th gen processor defaulted to the same "Clear CPU buffers; SMT vulnerable". Is it safe to disable the MDS mitigations on 8th and 9th gen processors? Will less aggressive mitigations be possible on those in the future?"

MELTDOWN REDUX: INTEL FLAW LETS HACKERS SIPHON SECRETS FROM MILLIONS OF PCS
AUTHOR: ANDY GREENBERGANDY GREENBERG, 05.14.19 01:00 PM
https://www.wired.com/story/intel-mds-attack-speculative-execution-buffer/

"...There are still more components, and many of them are not documented at all, so it's not unlikely this continues for a while," says TU Graz's Moritz Lipp. His fellow researcher Daniel Gruss adds: "We always expected this would keep us busy for years." In other words, don't be surprised if more hidden holes are found in the heart of your computer's processor for years to come."

 

02:10

 

Microarchitectural Data Sampling (aka MDS, ZombieLoad, RIDL & Fallout) explained by Red Hat
Red Hat Videos
Published on May 14, 2019
Microarchitectural Data Sampling—also known as MDS, ZombieLoad, RIDL & Fallout—is a set of Intel processor-based vulnerabilities that allows unauthorized users to access data used by other programs, containers, and virtual machines.

MDS lets attackers read--or sample--data from previous operations and potentially steal sensitive information by using other methods to stitch several pieces together.

This flaw is particularly dangerous for Intel-based public clouds running untrusted workloads in shared-tenancy environments.

There are a few different ways attackers can use MDS, each targeting different processor structures:

Store buffer attack (aka: Fallout)
Fill buffer attack (aka: RIDL)
Load port attack

Microcode patches are available for the store buffer attack, but to fully protect against the fill buffer and load port variants, IT administrators must disable Intel Hyper-Threading.

This short video provides a high-level primer on what MDS is and how it works. For more technical information about the vulnerability and what your company should do about it, visit red.ht/mds or watch this technical explainer video from Red Hat's Jon Masters: https://youtu.be/Xn-wY6Ir1hw


Understanding Microarchitectural Data Sampling (aka MDS, ZombieLoad, RIDL & Fallout) from Red Hat
Red Hat Videos
Published on May 14, 2019
Microarchitectural Data Sampling—also known as MDS, ZombieLoad, RIDL & Fallout—is a set of Intel processor-based vulnerabilities that allows unauthorized users to access data used by other programs, containers, and virtual machines. In this video,Red Hat computer architect Jon Masters provides a technical overview on how the flaw works and what companies can do about it.


RIDL leaking root password hash
VUSec
Published on May 14, 2019
We leaks the /etc/shadow file by repeatedly trying to authenticate a user with the passwd utility. The animation is sped up for the latter part of the video, the total process takes about 24 hours at the moment. A similar attack can leak the /etc/shadow of a cloud co-tenant by repeatedly opening an SSH connection.


RIDL leaking Linux kernel data
VUSec
Published on May 14, 2019
We showcase how to leak recent kernel data using RIDL. This demo first reads 0 bytes from /proc/version, whereafter we are able to leak the full contents of /proc/version without the data ever being present in userspace.


RIDL from JavaScript
VUSec
Published on May 14, 2019
We leak a string from another process using Javascript and WebAssembly in the SpiderMonkey engine.


Keyword Detection
In this scenario, we constantly sample data using ZombieLoad and match leaked values against a list of predefined keywords:

ZombieLoad Attack example video from zombieloadattack.com
Tech Assimilate
Published on May 15, 2019
"ZombieLoad in Action"
In our demo, we show how an attacker can monitor the websites the victim is visiting despite using the privacy-protecting Tor browser in a virtual machine.


ZombieLoad in Action: Spying on your visited websites
https://www.cyberus-technology.de/posts/2019-05-14-zombieload.html

ZombieLoad attack demonstration - Yet another Intel processor vulnerability
codedamn
Published on May 15, 2019
This video shows you how to demonstrate a zombieload attack using a macOS + VM running Ubuntu 18.04 where a VM steals information from host OS using Zombieload attack. Zombieload attack is the 3rd major processor attack after meltdown and spectre last year.

 

This base problem that Intel won't release updated microcode for processors earlier than 2011 for earlier or future vulnerabilities also affects Windows / Linux x58 hardware CPU's for me, and of course many thousands of others.

So this article isn't only about Apple Mac's, it's about all still active Intel CPU's that Intel won't support. Eventually it might catch up with an Intel CPU you have that is getting support now for currently found issues, but later found issues won't get microcode updates.

Eventually all Intel CPU's made that are vulnerable due to architecture failings will succumb to no support, so many like me that try to keep hardware in use as long as functionally practical will have to retire hardware much earlier than anticipated.

Apple lists Macs it can’t patch against ‘ZombieLoad’ exploits
There’s only so much Apple can do without Intel’s help.
BY KILLIAN BELL • 6:00 AM, MAY 17, 201
https://www.cultofmac.com/625928/apple-macs-cant-patch-against-zombieload-exploit/

"Apple has published a list of Macs that are still vulnerable to “ZombieLoad” exploits because they cannot be patched.

The older machines — all made before 2011 — may receive security updates, Apple says. But a proper fix won’t be available because Intel won’t release the necessary microcode updates.

The ZombieLoad exploit takes advantage of a newly-discovered vulnerability in all Intel processors released since 2011. It allows attackers to acquire sensitive data temporarily stored on the chip.

Fixing the problem is complicated. Apple has already rolled out patches that mitigate the issue, but users who apply a complete fix could suffer a performance decrease of up to 40%.

Some Mac users won’t get a proper fix at all, Apple has warned.

Older Macs still vulnerable to ZombieLoad
A number of Mac models released before 2011 may remain vulnerable to ZombieLoad and similar exploits, Apple has warned. Those include:

• MacBook (13-inch, Late 2009)
• MacBook (13-inch, Mid 2010)
• MacBook Air (13-inch, Late 2010)
• MacBook Air (11-inch, Late 2010)
• MacBook Pro (17-inch, Mid 2010)
• MacBook Pro (15-inch, Mid 2010)
• MacBook Pro (13-inch, Mid 2010)
• iMac (21.5-inch, Late 2009)
• iMac (27-inch, Late 2009)
• iMac (21.5-inch, Mid 2010)
• iMac (27-inch, Mid 2010)
• Mac mini (Mid 2010)
• Mac Pro (Late 2010)

ZombieLoad itself won’t work on these machines because they use older Intel chips. But they could be vulnerable to similar “speculative execution vulnerabilities,” - like those discovered Jan 2018 - Apple says, and there’s only so much Cupertino can do about it.

Intel won’t fix older processors
“These models may receive security updates in macOS Mojave, High Sierra or Sierra,” Apple explains in a new support document. But they are “unable to support the fixes and mitigations due to a lack of microcode updates from Intel.”

You shouldn’t be too concerned, though. Even on newer Macs, it’s unlikely ZombieLoad and similar exploits will affect too many users.

But this is another big reason why Apple is rumored to be developing its own chips for the Mac. Relying on third-parties leads to all kinds of problems that Apple often has no control over."

Additional mitigations for speculative execution vulnerabilities in Intel CPUs
https://support.apple.com/en-us/HT210107

 

Intel being a dick. Microcode updates are not like big OS updates, and for security related issues, updates should be provided for 20 years at least.

 

Oh poor Apple can now blame someone else while they push user into buying new systems.
If you need 'fear' to drive sales then maybe the problem is something else...

No one cares what data anyone has on their system and if someone does care, then buying a new system won't stop that person from getting it.

 

Apple's point wasn't to buy more Intel Mac's. There are no new "secure" architecture Intel CPU's available to purchase by anyone. Apple can't make new "secure" Intel Macintosh computers to sell, they can't exist.

If Intel's master plan was to force customers to purchase new Intel CPU's through core CPU security design failures, that would be another Intel failure as Intel doesn't have a working "secure" CPU solution to sell, even at 14nm.

Apple's message is that Intel needs to get their act together and support Apple Intel Macintosh Owners by continuing to fix CPU security issues that existed when the CPU's were made and sold, only to be discovered years later.

There are lots of people that do care about their data privacy, and if nothing else most people care if their systems are compromised for use in botnets and used as go-betweens in attacks on other computers.

Although I understand these vulnerabilities are very frustrating, adding time consuming work to our already over worked lives - costing us time and money to mitigate, simply declaring "it doesn't matter" doesn't solve the problems now or in the future.

I feel your pain bro, but please don't give up or suggest others should give up, that's not the guru way - we help people solve problems. Suggesting people should simply give up without solving the problem isn't cool.

Hang in there.

 

Everyone has an agenda. It's no coincidence that all these potential security flaws show up now.

If you don't instill fear into people, then how are you going to sell them new laws that are going to keep you 'secure'.

Everyone has already access to all our data because we have signed it away a long time ago...data is the thing that feeds the machine.

Create a problem to sell the solution, sadly the old mistakes are still being repeated.

We live in an age of instant information, but not instant transformation.

We will get there one day, but each one at their own pace...

 

As with all security flaws made public, these are showing up now because enough people in parallel figured them out and the information couldn't be contained. Releasing the information didn't benefit Intel, and it could have horrendous effects on everyone.

The only conspiracy that would come out of this is a conspiracy to weaken peoples resolve to maintain their personal space and personal privacy because it's "hopeless" or "inevitable" so we should all simply "give up".

If you are looking for timing, then it's been timed right at the juncture when people are waking up to the danger to their personal privacy.

Providing such a "hopeless" blow to people to get them to give up is the only conspiracy that makes sense to me. Promoting hopelessness and ignorance is the historical method of choice. It's time to wake up and work toward being a part of the solution, or roll over and go back to sleep in ignorance.

We need to inform people and encourage them to implement solutions, not throw up our hands and suggest giving up.

 

That's easy. We have to start looking inside for security and stop looking for it outside.

Edit: In short > stop buying into fear and don't let it be your decision maker.

 

If you are suggesting we ignore publicly posted security investigations, publicly posted vendor reports from Intel and OS vendors, or other publicly factual reporting, then I can't recommend your advice, as it's motivated by fear - you yourself are interpreting it as fear generating.

I've been doing security mitigations for decades, and there isn't a single time our work has been run on fear - it runs on facts and rational solutions.

Rarely the solutions required switching hardware vendors, usually switching OS versions or specific configurations is all that is needed. If there wasn't a ready solution but the vulnerabilities were live - we are tracking intrusion attempts - then live configuration changes to block those intrusions are acted on - and are adrenaline fueled at times, but you can't let fear change your reasoned course of action.

When I received responses like, ignore it it'll go away, or it's got a low probability of occurring ignore it, those were valid responses 40 years ago, as they didn't know better.

As part of the progression of understanding growing in the mind of managers and employee's, it was fun to watch those fear driven responses die right in front of our eye's - some large conference table meetings included someone saying such fear motivated things - with immediate repudiation by someone else in the meeting - "it's already happened, that's why we are here" let's work toward solutions now we can no longer put this off.

We'd use those times to also take action on other "back burner" projects to resolve security issues - to fold in solution choices - added features to address other issues at the same time - early on we added monitoring functionality we could never get funding for "when everything was working fine".

Can you imagine, there was a time when large networks only monitored for faults? Then performance was added. Then even later monitoring for intrusions, before formalized IDS systems were available.

These are all the steps I've been through, many more of course, and I can tell you that ignoring it isn't a solution, it won't go away, security holes will be actualized into real activity - we don't always know what form, but it's never good for the end user.

We are lucky now in that we have a large heads up and real activity being applied to solutions, unfortunately there are likely even greater levels of activity going into using these vulnerabilities.

I know the feeling, I have had to talk down a lot of panicky people over the years - and reasoned education and awareness were the only workable solution - and lots of patience waiting for them to catch up.

You can help by getting out there and learn as much as you can about the software and hardware behind the problems - and watch for exploits and solutions to mitigate them.

We can't bury our heads to escape from the repercussions from publicly published security vulnerabilities, it's not going away, it's only going to get worse over time.

The more pressure brought on Intel to solve this problem through new hardware architectures the better, sooner, and faster Intel will put the work in to move past these failures.

If I was Intel I'd throw resources at this before wasting $ on 10nm / 7nm, buy new process technology from others right now to assure competitive production continues, and then get back to building new architectures and new secure CPU's.