January Intel Meltdown Patches

[JasonWalker]

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

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

[tsikma]

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

[JasonWalker]

Hmm when running the Powershell script on my Win10 client (1607), the results say “You’re hosed”, and among other things points me to the Server guidance -

Suggested actions

 * Install BIOS/firmware update provided by your device OEM that enables hardware support for the branch target injection mitigation.
 * Install the latest available updates for Windows with support for speculation control mitigations.
 * Follow the guidance for enabling Windows support for speculation control mitigations are described in https://support.microsoft.com/help/4072698

[JOLUGO]

Does anyone know if Red Hat will be releasing patches for Red Hat 5 machines? I recently removed the original Red Hat plugin as my organization is trying to move all legacy machines to Red Hat 6 or newer. We still have a few stragglers that I wanted to be proactive with. Upon reconfiguring the plugin, I am unable to download any patches despite seeing a successful login in the download plugin logs. I suspect that this may be due to new patches only being available for organizations with extended support.

[tsikma]

Since RHEL 5 is end of life, its really up to the vendor at this point, i would not count on it.

Its the same boat as XP and 2003 machines on the Windows side. Microsoft did provide a patch 10 months ago for those OS’s but I am not hearing they will be doing the same for this one (probably since those OS’s are more than likely on old hardware)

[JOLUGO]

Hi @tsikma,

Yes that what I am thinking is the most likely outcome as well. Oh well more ammo to tell management to crank up the pressure on our app owners

[itsmpro92]

According to this Vulnerability Article from Red Hat, for customers with Extended Lifecycle Support contracts, patches for RHEL 5 are pending, and for customers with Advanced Update Support contracts, patches for RHEL 5.9 are pending.

[jgstew]

I’m not sure if you need to set those keys on client windows OSes or not.

I just revised the task & analysis I posted. The links above are still correct.

[tsikma]

@jgstew - I started to test your fixlet and analysis and was getting some results but on others the action did not run. Is there a property that I can create that would show the version of Powershell? I see the action checks for version 4 or higher, just want to have a check to see what versions most machines have installed (I had a not relevant machine come up).

[jgstew]

The answer is kind of in the fixlet itself:

(it as string as version) of values "PowerShellVersion" of keys "PowerShellEngine" of keys ((it as string) of maximum of (it as integer) of names of keys of keys "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PowerShell" of (x64 registries;x32 registries)) of keys "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PowerShell" of (x64 registries;x32 registries)

Just drop the exists and the whose. I actually write it as a property first, then convert it into a True/False by adding exists and whose. I consider this a best practice for all relevance. Write something for reporting first, then turn it into “applicability” relevance. (True/False)

• https://bigfix.me/analysis/details/2998541
• https://bigfix.me/analysis/details/2994540
• https://bigfix.me/analysis/details/20

To do this with a PowerShell Command:

powershell -ExecutionPolicy Bypass -Command "echo ('PowershellVersion=' + $PSVersionTable.PSVersion.Major)"

OR, to handle PSv1:

powershell -ExecutionPolicy Bypass -Command "if (test-path variable:\psversiontable) { echo ('PowershellVersion=' + $PSVersionTable.PSVersion.Major) } else { 'PowershellVersion=1' }"

• https://stackoverflow.com/questions/1825585/determine-installed-powershell-version

[tsikma]

Thanks, I was missing the first part of the line “(it as string as version) of” and getting multiple results. I have a few machines with versions <4, so I will reach out to a couple users in the morning and test on powershell verisons 2.0 and 3.0

[dmccalla]

As most are aware there have been some issues spotted regarding the incompatibility of certain anti-virus software as well as some BSOD issues with this patch. This has introduced some delays in the release of our patch content. The patch team is discussing this and conducting some additional testing in order to address these issues. More information will be coming later. We will likely have to release the content a few hours past the 24 hour timeline we normally adhere to but be assured we are working hard on this.

Reference: https://support.microsoft.com/en-us/help/4072699/important-information-regarding-the-windows-security-updates-released

[hmmarkka]

Are there any known problems with BigFix components on any platform after running the patch? This MS statement caught my attention:

During our testing process, we uncovered that some third-party applications have been making unsupported calls into Windows kernel memory that cause stop errors (also known as bluescreen errors) to occur.

Even though this seems to be related to AV, I’m wondering whether it could affect other applications too.

[mwolff]

James, excellent work. Since we have tons of old hardware in our environment, I’ve been able to confirm that this detection will actually work on Windows Server 2008/2008R2 and Windows 7 endpoints running PowerShell 2.x and 3.x clients.

We have some PowerShell 1 clients too, trying to verify if the commands will function on these as well.

[JonL]

Anyone having issues when testing these patches?

On Win10 1607 test computer I see this result:

error 0x80070005: Security Update for Windows KB4056890

Nothing meaning in Google or Bing for this.

[dmccalla]

error 0x80070005

That might be a permissions issue. I found this: https://support.microsoft.com/en-us/help/968003/error-0x80070005-in-windows-update-when-you-try-to-install-updates

[mwolff]

Update:
I can confirm that @jgstew 's actions and relevance work all the way back to PowerShell 1 (don’t ask…).

I’ve successfully gotten results from 5 endpoints with PS1, 43 endpoints with PS2, and 110 endpoints with PS3, with only two unsuccessful runs.

The two failures still ran the script, and returned variants of the following for the Raw SpeculationControl Results property:
Unsupported processor manufacturer:

• throw <<<< (“Unsupported processor manufacturer: {0}” -f $cpu.Ma
• CategoryInfo : OperationStopped: (Unsupported processor manufacturer: :String) [], RuntimeException
• FullyQualifiedErrorId : Unsupported processor manufacturer:

Both are Xeon processors of the E5 model, an E5-2680 v3 and an E5-4650, one running in a virtual environment and the other in a Supermicro. We’re trying to get PowerShell updated on both to see if this will have an effect, since both are running PowerShell 2 on Windows Server 2008R2 which supports PS5 (handy MS reference: https://docs.microsoft.com/en-us/powershell/wmf/readme)

[jgstew]

I can confirm that @jgstew 's actions and relevance work all the way back to PowerShell 1

It may run all the way back to PS1, but are the results provided by PS1 reliable? I think they may be as long as all of the functions used are valid back that far, but MS hasn’t provided a minimum PS version required for the results to be reliable and I have no way to be certain of this without investigating at least the functions used and if they have changed between PS versions in a fundamental way… which they likely haven’t.

Also, thanks a TON @mwolff for doing this testing!!! This is exactly what I hoped the community could provide.

---

the comments here: https://www.powershellgallery.com/packages/SpeculationControl/1.0.1

mention:

“If multiple Win32_Processor instances are returned, this function crashes on older Powershell versions, as it can’t resolve the manufacturer.”

which matches:

Unsupported processor manufacturer: + throw <<<< (“Unsupported processor manufacturer: {0}” -f $cpu.Ma+ CategoryInfo : OperationStopped: (Unsupported processor manufacturer: :String) [], RuntimeException+ FullyQualifiedErrorId : Unsupported processor manufacturer:

which seems to be a flaw in the powershell code itself due to this mention of a workaround:

I use a Workaround in the SpeculationControl.psm1:

$cpu = Get-WmiObject Win32_Processor

if ($cpu.count){$cpu = $cpu[0]}

Which tells me this is most likely an issue whenever there are multiple physical CPUs based upon:

Both are Xeon processors of the E5 model, an E5-2680 v3 and an E5-4650

[jlha]

Fwiw, we had several machines that were not creating the QualityCompat registry entry even after successfully running Symantec’s LiveUpdate. In my tests, the Meltdown patch still works on these systems without causing a BSOD. LiveUpdate is applying an update to the “Eraser Engine” avoid a BSOD. Product Version 117.3.0.358 or higher. Here is the property relevance we’re using to remediate machines that do not have the minimum Eraser Engine version:

(exists file “C:\Program Files (x86)\Common Files\Symantec Shared\EENGINE\eeCtrl64.sys”) and (value “ProductVersion” of version block of file “C:\Program Files (x86)\Common Files\Symantec Shared\EENGINE\eeCtrl64.sys” >= “117.3.0.358”)

[JonL]

So far the 2008 R2 and 2012 R2 patches appear to work successfully. However the patch on Win 10 1607 LTSB continues to error out with either a generic ‘access denied’ or 0x80070005. Attempting to reset permissions as @dmccalla suggested did not work either. Anyone else having success on Win 10 1607 LTSB?