If the OS is x64, be sure to set the Wow6432Node version of the QualityCompat key. Then the fixlets should become relevant.
The updated fixlets should not require the key be set in that location anymore.
You may need to open a PMR about this so it can be investigated.
I’ll have to open a PMR. Nearly all of our servers are not showing relevant for the meltdown fixlets (i.e. MS18-JAN: Security Only Quality Update - Security Only - Windows Server 2012 R2 - KB4056898 (x64)). All relevance are TRUE except for the massive rel #6
1 Like
That is the hardest one to address as well.
FYI: The bigfix content to run microsoft’s powershell module for getting the status of windows in regards to these patches and mitigations has been updated and published:
Microsoft released an updated version of the powershell module.
Anyone having problems with BigFix components after patching? Just saw this and became more curious BigFix Agent disappears after KB4056892
Heads-Up!
2 Likes
and another one…the one is more about patching moving forward…
Customers will not receive the January 2018 security updates (or any subsequent security updates) and will not be protected from security vulnerabilities unless their antivirus software vendor sets the following registry key
Key=“HKEY_LOCAL_MACHINE” Subkey=“SOFTWARE\Microsoft\Windows\CurrentVersion\QualityCompat” Value=“cadca5fe-87d3-4b96-b7fb-a231484277cc” Type="REG_DWORD” Data="0x00000000”
Has anyone created content for detection in RH - https://github.com/speed47/spectre-meltdown-checker/blob/master/spectre-meltdown-checker.sh
1 Like
A Microsoft note on performance impacts: https://www.petri.com/microsoft-outlines-performance-impacts-meltdown-specture-patching
Looking into it. I’ve been hoping for tools for non-windows similar to the powershell one. If anyone has a head start on bigfix content, let me know. I’m also curious to hear about other similar tools for linux/mac/etc…
There is content for this already in bigfix in patches for windows to set the QualityCompat BUT be careful! setting this with an incompatible AV will cause blue screens.
We are adding relevance to exclude the MS patches from AMD systems for this reason.
We think this is an isolated thing that could be related to other tools on the system somehow. I would always recommend caution in rolling out things like this in general because there is an unknown number of possible interactions and this CPU bug and patching is unprecedented in many ways.
So we have used GPO to add the Macafee registry entry and now have a good pile of relevant servers.
We were just about to go all in patching NonProd this afternoon when we notice the issue with the RPC_C_AUTHN_LEVEL_CALL listed on the KB article.
https://support.microsoft.com/en-us/help/4056898/windows-81-update-kb4056898
When calling CoInitializeSecurity, the call will fail if passing RPC_C_IMP_LEVEL_NONE under certain conditions.
When calling CoInitializeSecurity, the call may fail when passing RPC_C_AUTHN_LEVEL_NONE as the authentication level. The error returned on failure is STATUS_BAD_IMPERSONATION_LEVEL.
Microsoft is working on a resolution and will provide an update in an upcoming release.
We have decided to hold off for now as we are not sure what that will affect in our environment. Has anyone who has already patched noticed any issues?
2 Likes
Note from McAfee
Automated Mechanism to Deploy the Registry Key Update
Starting with the January 10th DAT (3221.0) updates for ENS 10.0.2 and later, the registry key will be automatically updated for customers who receive their DAT updates through ePO.
2 Likes
Because this was hard to find, here’s a link of HP Workstation BIOS updates & schedule -
https://support.hp.com/us-en/document/c05869091
3 Likes
The following appears to be a fairly good reference, including microcode resources/links from various manufacturers: https://support.microsoft.com/en-us/help/4073757/protect-your-windows-devices-against-spectre-meltdown
2 Likes
Working on it, but nothing to report. Part of my issue is not having a bunch of Linux VMs set up for testing, another issue is working out issues with how I was downloading the script. I think I need to just test the script first, then try to figure out how I can get it onto a system in a secure manner… ideally using a prefetch.
Not sure I’ll get to this today @nicksberger … I just updated the MS Powershell task since they released version 1.0.3 of the module.
I just figured out part of the problem I was having with spectre-meltdown-checker.sh : https://twitter.com/jgstew/status/951615074665295872
1 Like
Here is crude content to set Chrome Strict Site Isolation feature for Apple MacOS: (another mitigation option)
This uses chrome policies, but also assumes there are no existing chrome policies. Ideally this would be improved to add this setting to chrome policies regardless of if they already exist or not. Similar content could be created for Windows & Linux.
NOTE: this will cause chrome to use more resources, primarily RAM. I have not measured it’s impact in any way.
Related:
2 Likes
We ran into an odd issue with some of our Windows 10 machines where these patches would fail to install. After a Microsoft Premier case, we discovered that the patch did not like the USB storage device restrictions that were part of the hardening policies on these Windows 10 tablets. Upon lifting the USB storage restrictions/hardening, the patch is now applying successfully.
I’ve had this occur repeatedly with older patches as well. Our method (carried over from the XP days) was to add a System:DENY permission on usbstor.inf and usbstor.pnf to prevent USB Storage drivers from loading. This blocked installing many of the MS patches on Win2012, Win2016, and Win10 (presumably, because the patches could not overwrite the files).
Now, I reset the permissions on these two files when entering the patch window.
In the CIS Checklist sites, it looks like IBM’s approach is to rename the two files rather than block access permissions on them. And Win10 has some Group Policy settings that can be used to block the devices as well.
I got it!
No clue why this is what it took, or if there is a more direct way to run it:
wait bash -c "bash /tmp/spectre-meltdown-checker.sh > { pathname of folders "Logs" of folders "__Global" of data folders of client }/results_SH_spectre-meltdown-checker.txt"
Once i got that figured out, I could go back to this way, which is what i was going for in the first place:
wait bash -c "bash '{pathname of file "spectre-meltdown-checker.sh" of folder "__Download" of client folder of current site}' > '{ pathname of folders "Logs" of folders "__Global" of data folders of client }/results_SH_spectre-meltdown-checker.txt'"
Task:
Note: I make no claims about the validity or safety of the script this runs:
The script is hard coded to run this version of the script: https://raw.githubusercontent.com/speed47/spectre-meltdown-checker/dce917bfbb4fa5e135b7ed4c84881086766be802/spectre-meltdown-checker.sh
It will need updated as the script is updated, which is intentional so that the script can be validated and not change over time until such time as it can be revalidated at a new version. Running arbitrary code from GitHub without vetting / validation is not recommend.
Analysis:
By default the output of the script has coloring info, which gets picked by the analysis. The task would need adjusted to not provide the coloring info.
Right now the analysis just reads the raw lines of the results file. I haven’t enhanced it to pull out any specific info for reporting, but that is a possibility if I have a better picture of the different results. The extra colorization stuff in the output doesn’t help currently.