|
Patch reliability is unclear. Unless you have an immediate, pressing need to install a specific patch, don't do it. |
For those of you that like to dig a bit deeper into the details of patching, I highly recommend the Zero Day blog. For those who remember the detaile
[See the full post at: Patch Lady – light reading for the evening]
Susan Bradley Patch Lady/Prudent patcher
Here’s the Status of Meltdown and Spectre Mitigations in Windows
By Catalin Cimpanu | June 13, 2018
Yesterday’s Patch Tuesday release included fixes for the latest Spectre vulnerability, known as Spectre variant 4, or SpectreNG.
These patches are currently not available for all Windows versions, though, and all mitigations are disabled by default.
Only Windows 10, Windows Server 2016, Windows 7, and Windows Server 2008 R2 have received SpectreNG patches.
Meltdown and Spectre patching is a mess
Read the full article here
Just hot off the presses tonight we have another Intel vulnerability that will make our heads hurt trying to figure out the patches on. Called Lazy FP State restore vulnerability
See details on Code Red – Security Advisories:
Intel Releases Security Advisory on Lazy FP State Restore Vulnerability: US-CERT
We have had a peak into the State Hacker’s toolkit lately IMHO
Unless you operate a sensitive server, you probably have nothing to worry about. Although ii is a good reality check to tighten up defenses.
Not logging on as a admin, disabling 3rd party cookies and not running Javascript by default are good places to start.
For me I probably won’t be installing any microcode bios updates. YMMV
As always, there’s a balance to be struck between security and stability, and whilst the balance clearly leans towards security where Windows updates are concerned, subject to the usual caution exercised here as opposed to rushing into installing them, it seems to me that the balance still leans more towards performance where certainly BIOS updates and arguably driver updates are concerned. BIOS updates really can do serious damage to a system, with little in the way of advance feedback because there are so many different systems (and sites like this tend not to talk about them enough), and I’m always reluctant to update drivers that are working flawlessly.
A lot depends on the use you put your computers to, and the severity of loss if any compromise were to happen. My approach to security starts with having nothing whatsoever to do with online or telephone banking, or investment/pension management. I use one credit card for online purchases, and monitor my statements very carefully. As a home-based gamer, for me performance is important, but people who manage all their finances (and/or their businesses) online may feel they need to err more towards security than performance, which would be perfectly understandable.
We have had a peak into the State Hacker’s toolkit lately IMHO Unless you operate a sensitive server, you probably have nothing to worry about. Although ii is a good reality check to tighten up defenses. Not logging on as a admin, disabling 3rd party cookies and not running Javascript by default are good places to start. For me I probably won’t be installing any microcode bios updates. YMMV
Right now that is most certainly true but you can not blindly bank that it will stay that way. The Spectre Pandora’s Box is just starting to open and it’s to good a target not to get exploited somewhere how down the road.
I would say there would need to be a fair deal of sophistication for hackers to exploit a system using Spectre exploits.
While this is entirely possible there are probably many easier ways Hackers can gain access to systems.
The way I see it is that Spectre can be used to infiltrate systems without detection and that sophistication has not been the trademark of normal hackers.
If this does become an issue going forward then revaluation would be required. I would be surprised if 50% of at risk systems would get effective protection.
So in case anyone is wondering, it is a bad idea to enable the Lazy FP State Restore patches inside Server 2012R2 HyperV virtual machines on a host with no microcode update. I am not sure which part of that causes the problem, but it puts you in a bad spot:
This is the exact group policy I applied, which I believe matches Microsoft’s recommendations to enable the patch for CVE-2018-3639:
Essentially, set HKLMSYSTEMCurrentControlSetControlSession ManagerMemory ManagementFeatureSettingsOverride to 8, and FeatureSettingsOverrideMask to 3.
This resulted in a BSOD on startup for ALL of my virtual machines with this policy applied. Fixing this was annoying, since the VMs wouldn’t boot. You have to use the recovery environment, load the SYSTEM hive, and remove the keys.
So if you have the same setup as me (no microcode update on the HyperV host), don’t enable the fix! Hopefully this was obvious to everyone and I was just spacing out on a Friday, but just in case, this is fair warning.
Donations from Plus members keep this site going. You can identify the people who support AskWoody by the Plus badge on their avatars.
AskWoody Plus members not only get access to all of the contents of this site -- including Susan Bradley's frequently updated Patch Watch listing -- they also receive weekly AskWoody Plus Newsletters (formerly Windows Secrets Newsletter) and AskWoody Plus Alerts, emails when there are important breaking developments.
