January Intel Meltdown Patches

Any ETA on Intel Meltdown Patch fixlets?

https://meltdownattack.com/

https://support.microsoft.com/en-us/help/4072698/windows-server-guidance-to-protect-against-the-speculative-execution-s

1 Like

Seconded. We’re already pushing this content to production with SCCM where available, but have other environments where we need IBM content to follow-up.

1 Like

Curious as well. We see the update (appears to be KB4056892 for Win10), but it has a lot of its own issues: Performance, long reboot times, and issues with AV and Encryption as well. Maybe IBM hasn’t pushed it for this reason? In our IT Department, we’re kind of thinking/hearing that MS jumped the gun on this update and there will be revisions and new updates in the very near future.

I did a Gather, and that didn’t pull anything new.

1 Like

@BaiYunfei Hi - Whats the ETA for these please ?

I think we are concerend with the “Meltdown” and “spectre” Vulnerabilities that have been initially addressed with this out of cycle patch … January 3, 2018—KB4056892 (OS Build 16299.192)

https://support.microsoft.com/en-us/help/4056892/windows-10-update-kb4056892

2 Likes

Seconded. At least from my end it’s the January OOB patches we’re wanting now.

IBM content development team - pls update by when we can get today released MS security patches?

1 Like

Update: Now available::

Related:

1 Like

For Windows server OS ,
is there any KB available in BIGFIX as of now ?

FYI, the Red Hat patches appear to be available in the “Patches for RHEL 6 Native Tools” and “Patches for RHEL 7” sites.

18001401	RHSA-2018:0014 - Linux-Firmware Security Update - Red Hat Enterprise Linux 7 (x86_64)	1/4/2018
18000701	RHSA-2018:0007 - Kernel Security Update - Red Hat Enterprise Linux 7 (x86_64)	1/3/2018
18000801	RHSA-2018:0008 - Kernel Security Update - Red Hat Enterprise Linux 6	1/3/2018
18000802	RHSA-2018:0008 - Kernel Security Update - Red Hat Enterprise Linux 6 (x86_64)	1/3/2018
18001201	RHSA-2018:0012 - Microcode_ctl Security Update - Red Hat Enterprise Linux 7 (x86_64)	1/3/2018
18001301	RHSA-2018:0013 - Microcode_ctl Security Update - Red Hat Enterprise Linux 6	1/3/2018
18001302	RHSA-2018:0013 - Microcode_ctl Security Update - Red Hat Enterprise Linux 6 (x86_64)	1/3/2018
2 Likes

Here is content to run micrsoft’s powershell checking code for this: (Updated)

I did see a comment in the powershell gallery that on some lower versions of powershell it doesn’t run successfully due to multiple CPUs throwing off something. I also can’t say for certain if the results are valid for all versions of powershell, but it does appear to run on ALL versions of powershell thanks to testing performed by the community. ( @mwolff specifically )


Update: there is now a fixlet in the patch site for the following:

This should be the right applicability relevance for the settings mentioned in the link:

not exists keys "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management" whose(exists values "FeatureSettingsOverride" whose(0 = it as string as integer) of it AND exists values "FeatureSettingsOverrideMask" whose(3 = it as string as integer) of it) of registry

This should be the right actionscript commands for the setting mentioned in the link:

regset "[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management]" "FeatureSettingsOverride"=dword:0
regset "[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management]" "FeatureSettingsOverrideMask"=dword:3
4 Likes

Note that the following registry key is required in order to install the patches per Microsoft:

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\QualityCompat]
“cadca5fe-87d3-4b96-b7fb-a231484277cc”=dword:00000000

It is worth double-checking and adding as needed.

1 Like

Per the Antivirus compatibility link - I don’t know whether the patch would refuse to install if the Registry key is not present, or if this only affects whether the patch will be offered through Windows Update.

I’d like to hear from the BigFix Content Team how they plan to handle it. Will they check for this key when applying Relevance? Will they make the fixlet Relevant and let it fail to install where the key is not present? Or will the patch actually install and trigger the bluescreen issue?

1 Like

Yeah, it seems like that flag should only be set if there is No AV or if there is an AV that is known to be compatible but hasn’t set that key yet. ( There is now published content to set that )

That is definitely a concern. It probably makes sense to only have it be applicable if the registry setting is there to be conservative and then provide a way to set it.

Any more insight into the Antivirus compatibility registry key?

  • does the value “0” indicate the system is compatible and ready for the patch?
  • On what OS should it appear? The article implies it’s only for Win7, Win2008r2, and Win2012; but I have the value present on my Win10 client.

Edit: I think I misread the article. Looks like the value applies to all Windows, they are clarifying that Win7, 2008, and 2012 don’t come with an antivirus by default, and you should go get one, and once you get one it should set the value. Sorry for the confusion.

1 Like

My read on it was that zero is the expected value. I confirmed that is true on some randomly selected computers that I checked. It appears to be all Windows OS versions.

I would definitely not add the key just to make the patch available on the machine. Pretty sure that is how you can BSOD your machine.

For Symantec once I ran live update the registry key was created and I was able to apply the Microsoft patch, before the update the registry key did not exist. I set an analysis looking for that key and had symantec run live update locally on the machine and as they report back they now have the key as well.

After applying the Microsoft patch I am protected for Meltdown now based on the Powershell command but still vulnerable to Spectre until I update my BIOS.

Analysis I used to check if the key exists

exists key "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\QualityCompat" of native registry
1 Like

The MS article specifically mentions setting that key yourself if you have No AV at all.

it isn’t flawless, but you can detect the No AV condition using MS security center wmi call in most cases, but you are right, you would want to be very careful setting that key

Do we know whether these keys also need to be set on Windows Client operating systems, or just on Server?

I do not see the same reference in the Workstation guidance
reference:
https://support.microsoft.com/en-us/help/4073119/windows-client-guidance-for-it-pros-to-protect-against-speculative-exe

1 Like