January Intel Meltdown Patches

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

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
1 Like

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.

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)

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 :slight_smile:

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.

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.

@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).

1 Like

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)

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' }"
1 Like

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

1 Like

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

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.

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.

1 Like

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.

That might be a permissions issue. I found this: Troubleshoot problems updating Windows - Microsoft Support

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)

2 Likes

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: PowerShell Gallery | 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:

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:

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ā€)

1 Like

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?

1 Like