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
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?
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.
Because this was hard to find, here’s a link of HP Workstation BIOS updates & schedule -
https://support.hp.com/us-en/document/c05869091
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
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
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.
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'"
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.
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.
I just updated the task to run Microsoft’s Powershell detection tool to version 1.0.4 which has a fix for getting the CPU manufacturer - Microsoft PowerShell content for Meltdown and Spectre - UPDATED to 1.0.4
Microsoft has added an explanation of the output of the powershell script that is very useful: https://support.microsoft.com/en-in/help/4074629/understanding-the-output-of-get-speculationcontrolsettings-powershell
Another heads-up: Intel is warning that the microcode / bios updates may cause reboots on some chips. Some indications they may have quietly told datacenter customers to delay bios updates.
AMD has updated their press release and now expect to ship updated firmware for AMD systems.
Both reached the same results with slightly different actions, my analysis (lines of…) is the same
wait /bin/sh -c "(cd __Download && chmod a+x spectre-meltdown-checker.sh)"
wait /bin/sh -c "(cd __Download && ./spectre-meltdown-checker.sh --batch) >/var/opt/BESClient/__BESData/__Global/Logs/spectre_meltdown_check.log 2>&1"
Thanks for posting though.
RedHat just released its own tool: https://access.redhat.com/labs/speculativeexecution
PS: needs to authenticate first with RHN to get the script.
This is very frustrating that the script isn’t just available. This will make it much harder to make bigfix content available for, which is what I just was looking into.
Looking at the Java fixlets for Windows, perhaps we could use the same technique where we have to manually download and cache it locally, complying with the license requirements of having to log in and obtaining the file via the RH Portal.