Speculation Control Validation PowerShell Script

Since downloading the latest version, issuing the command:

Invoke-Command -ComputerName server-name ${function:Get-SpeculationControlSettings}

returns the error:

You must provide a value expression on the right-hand side of the '-' operator.
    + CategoryInfo             : ParserError: (:) [], ParseException
    + FullyQualifiedErrorId : ExpectedValueExpression
    + PSComputerName    : server-name

If I use a hostname without a hyphen everything works as before.  I have numerous machines which follow this naming convention. 

I have already posed the question in the Script Center with no luck.  I suspect something was missing in the QA of the last rev.

https://social.technet.microsoft.com/Forums/scriptcenter/en-US/9dd9b476-16c6-4aa3-9b92-5685f794a122/speculationcontrol-no-longer-works-remotely-against-hostnames-containing-hyphens?forum=ITCG

Can someone please help?

Does it work, if you surround the server-name in hyphens?

Invoke-Command -ComputerName "server-name" ...

Sorry, i meant quotation marks not hyphens:

Does it work, if you surround the server-name in quotation marks?
Invoke-Command -ComputerName "server-name" ...

Tried using single and double quotes, placing quotes around different segments of the name etc.  Same error.  The Scripting Guys Forum gave me a way to confirm the issue is not with my install of PowerShell.

Was this ever resolved please?

I have exactly the same issue, server names have hyphens in them. Have tried single quotes, double quotes or no quotes. 

Command issued:
PS C:\> Invoke-Command -ComputerName "C-DHCP-RELAY-01" ${function:Get-SpeculationControlSettings}

Result received:

You must provide a value expression on the right-hand side of the '-' operator.
    + CategoryInfo          : ParserError: (:) [], ParseException
    + FullyQualifiedErrorId : ExpectedValueExpression
    + PSComputerName        : C-DHCP-RELAY-01

Import-Module : The 'L:\SpeculationControl\SpeculationControl.psd1' module cannot be imported because its manifest con
ains one or more members that are not valid. The valid manifest members are ('ModuleToProcess', 'NestedModules', 'GUID
, 'Author', 'CompanyName', 'Copyright', 'ModuleVersion', 'Description', 'PowerShellVersion', 'PowerShellHostName', 'Po
erShellHostVersion', 'CLRVersion', 'DotNetFrameworkVersion', 'ProcessorArchitecture', 'RequiredModules', 'TypesToProce
s', 'FormatsToProcess', 'ScriptsToProcess', 'PrivateData', 'RequiredAssemblies', 'ModuleList', 'FileList', 'FunctionsT
Export', 'VariablesToExport', 'AliasesToExport', 'CmdletsToExport'). Remove the members that are not valid ('RootModul
'), then try to import the module again.
At line:1 char:14
+ Import-Module <<<<  .\SpeculationControl.psd1
    + CategoryInfo          : InvalidData: (L:\SpeculationC...ionControl.psd1:String) [Import-Module], InvalidOperatio
   nException
    + FullyQualifiedErrorId : Modules_InvalidManifestMember,Microsoft.PowerShell.Commands.ImportModuleCommand

If I'm not mistaken "RootModule" was new in WMF/PowerShell 3.
So updating WMF might fix this problem for you.
Windows Server 2008 R2 SP1 shipped with WMF 2.0, you can install WMF 5.1 on it. https://docs.microsoft.com/en-gb/powershell/wmf/5.1/install-configure

I got it to work on powershell 2.0 by pulling in third party functions to make up for what was missing on powershell 2.0.  I also had to fix some parameters needing '=$true' and the psd1 file needing 'RootModule' replaced with 'ModuleToProcess'.

Microsoft really should update this script to work from Powershell 2.0 since that is still a supported version of powershell on Windows Server 2008 R2.

https://github.com/agibson2/Get-SpeculationControl-Powershell2/tree/master

We're trying to use the module to verify the presence of the microcode from BIOS vendors and we've discovered that the script will always return "False" for the presence of hardware support unless OS level Spectre/Meltdown patches are installed.

For example, we used a stock Windows 10 install (no patches), performed a BIOS update (Dec 2018) and ran this script which reported the hardware mitigation presence as "False". We then installed kb4074588 and re-ran the script and got the correct reporting of "True".

We believe that the script is not performing a determination of the presence of hardware mitigations based on a value from the hardware but instead on values determined by the OS which are affected by the OS level patches.

We would recommend that if the script cannot make a correct determination of the presence of hardware mitigations (due to missing the OS patches) then it should return an Error or a value of Unknown rather than returning an incorrect value of "False". We further recommend that the script be modified to use hardware registers in determining the presence of hardware based mitigations and return the correct finding.

When I'm executing this script I always get False for BTIRetpolineEnabled and BTIImportOptimizationEnabled. What does it mean and how can I fix it?

Both features are available and enabled in current builds of upcoming Win10 v1903.

Did anyone receive reports on issue with gathering some of the information from virtual machines? I am having troubles gathering SSBDHardwarePresent value on VMWare virtual machines - it just gives $null value. It is odd, because script can properly gather information on L1TFHardwareVulnerable from the same virtual devices.

I have worked around this by assigning string NULL to outcome if logical $null is present:

if($SSBDHardwareVulnerable -eq $null)
{
$SSBDHardwareVulnerable = "NULL"
}

Does anybody have idea why this exact category gives $null and if it this information can be retrieved in any way?

Hi,

When script is executed I get the list of different settings and their values, and on the end there is "suggested actions" tab, example below:

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 Client support for speculation control mitigations described in https://support.microsoft.com/help/4073119

Does the content of "Suggested actions" depend on the previous results, or is list of suggested actions always the same? 

Another question - is it possible to list "Suggested actions" section only? I cannot see it on the list of properties after I get-member the command.

What I mean is, I want to assign Get-SpeculationControlSettings to variable, example $SC, and then list SuggestedActions property with $SC.SuggestedActions. If such functionality is not there, could it be implemented in new version of the script?

Thanks.

No matter what I do, I can't get AMD hosts or guests running on AMD VMware hosts to pass.  Latest bios are applied.  Have tried a combo of many different registry settings, and no go.  Anybody else having similar issues?

can you share a screenshot of the output please? 

https://imgur.com/a/r7xRl6G

We've also tried using the 64/3 settings that are mentioned here for AMD servers: https://support.microsoft.com/en-us/help/4072698/windows-server-guidance-to-protect-against-the-speculative-execution

thanks. So, so I am clear, this is a Windows VM on a VMWare host using an AMD processor right? I can see Windows knows is an AMD processor. Do you control this host and you know the AMD microcode has been installed? 
I am not a VMWare expert but I believe you have to expose the new microcode functionality to guests (this functionality is what the PowerShell is looking for). Take a look at this KB https://kb.vmware.com/s/article/52085

please let me know what you find.
 

This in particular is a windows physical host, not a VM guest.  The same thing is happening in our VM guests, but trying to take that dynamic out of it, and focusing on just windows proper.

Ok, then it can only be one of three things:
1) you don't have a BIOS update with the required functionality from AMD
2) there is a problem with the powershell
3) you don't have a vulnerable processor (and thus, the required  functionality is not present). I don't expect this to be the case unless this is a very old processor, but listed here for completeness. 

I will likely need more information, but for now, can you go to System Information and tell me what you have for these two values:

Processor
BIOS Version/Date	

I want to discard #3, and the above info might also be enough to know about #1 

That info on system info  has been added to the following link https://imgur.com/a/r7xRl6G.

Ok, pardon the delay as I went away and disconnected a bit.  Thanks for the picture. Given this is on a host, the line BTIHardwarePresent says False, which means the PowerShell doesn't detect the required functionality in the microcode. I know you mentioned you had the latest BIOS, but it seems that BIOS update didn't have the latest microcode from AMD to address this issue.  You should check with your OEM to ensure they have a BIOS update with the AMD microcode to address CVE-2017-5715 (Branch Target Injection, aka, Spectre Variant 2).

I don't want to try to hijack this question, but I can also confirm, that on AMD based systems we always get a none compliant result.
We have also HP Proliant Servers but a newer generation DL385p Gen8 with AMD Opteron with the latest BIOS A28 installed as reference at https://h22208.www2.hpe.com/eginfolib/securityalerts/Variant/Variant_Vulnerabilities.html.

The output of Version 1.0.11 is:
BTIHardwarePresent                  : True
BTIWindowsSupportPresent            : True
BTIWindowsSupportEnabled            : True
BTIDisabledBySystemPolicy           : False
BTIDisabledByNoHardwareSupport      : False
KVAShadowRequired                   : False
KVAShadowWindowsSupportPresent      : True
KVAShadowWindowsSupportEnabled      : False
KVAShadowPcidEnabled                : False
SSBDWindowsSupportPresent           : True
SSBDHardwareVulnerable              : True
SSBDHardwarePresent                 : False
SSBDWindowsSupportEnabledSystemWide : False
L1TFHardwareVulnerable              : False
L1TFWindowsSupportPresent           : True
L1TFWindowsSupportEnabled           : False
L1TFInvalidPteBit                   : 0
L1DFlushSupported                   : False

Also tried the values for FeatureSettingsOverride with 0x0, 0x8, 0x40, 0x48 with all the same result.
It seems to me the script is not AMD aware.

Hi Stefan - what exactly are you calling a non-compliant result? In your case, you have the variant 2 hardware support (the first line) and it is enabled (the third line). Is variant 2 what you are looking at or the others? So you are compliant for Variant 2 (but do read the advisory (180002) as there are other factors to be aware off for AMD). 

Just in case, here is the KB that explains the output. 
https://support.microsoft.com/en-us/help/4074629/understanding-the-output-of-get-speculationcontrolsettings-powershell

Hi,
non-compliant in regard of the SCCM Compliance Baseline developed by the MSFT SCCM Team here: https://gallery.technet.microsoft.com/Speculation-Execution-Side-1483f621 
Looking at the output of your script regarding SSBD:
SSBDWindowsSupportPresent           : True
SSBDHardwareVulnerable              : True
SSBDHardwarePresent                 : False
SSBDWindowsSupportEnabledSystemWide : False
The SSBDHardwarePresent = $false and SSBDWindowsSupportEnabledSystemWide = $False are resulting to be not compliant aka. all mitigations have been enabled.

To get more clear:
A. HPE tells us, if we have  the latest BIOS A28 installed as reference at https://h22208.www2.hpe.com/eginfolib/securityalerts/Variant/Variant_Vulnerabilities.html additionally to the Reg-Keys anything should be fine.
B. Get-SpeculationControlSettings results to SSBDHardwarePresent = $false and SSBDWindowsSupportEnabledSystemWide = $False which means those mitigations against SSBD are not present/not enabled.

What is right? A. or B.?

Thanks for confirming this is about SSBD and not variant 2 where you are ok. I need to look into the SCCM compliance baseline and will do that separately. 
The short answer is that, both A + B are right. Let me explain why that is. AMD is not providing architectural support for SSBD, in simple terms, that means there is no microcode that has the "SSBD feature." So A is right, because you seem to have the latest microcode based on support for Variant 2 (BTI, CVE-5715) and there is no further microcode required for SSBD support. 
However, B is right because we have not released SSBD support for AMD's SSBD implementation yet (that is in advisory 180012).  We continue to work on that. I will see if we have opportunities to make that more clear. thanks  

I receive the following error running version 1.0.11 of the script on Windows 7 SP1 Professional (64-bit). While the last version I used successfully (after changing "RootModule" to "ModuleToProcess" in SpeculationControl.psd1, of course) was 1.0.8; judging by the error, it seems to be related to the introduction of the L1TF settings query in version 1.0.9:

PS> Import-Module .\SpeculationControl.psd1
You must provide a value expression on the right-hand side of the '-' operator.
At SpeculationControl.psm1:237 char:73
+ $l1tfInvalidPteBit = ($flags -band $l1tfInvalidPteBitMask) - <<<< shr $l1tfInvalidPteBitShift
    + CategoryInfo          : ParserError: (:) [], ParentContainsErrorRecordException
    + FullyQualifiedErrorId : ExpectedValueExpression

Make sure you are on PowerShell 3.

"Beginning in PowerShell 3.0, the -shr (shift-right) and -shl (shift-left) are added to support bitwise arithmetic in PowerShell."

It seems that the -Verbose option breaks the script. Without it the scripts runs just fine. (Using module version 1.0.11 on Windows Server 2016 core edition.)

Write-Verbose : A positional parameter cannot be found that accepts argument 'True'.
At SpeculationControl.psm1:119 char:17
+ ...             Write-Verbose "BpbEnabled                   :" (($flags - ...
+                 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : InvalidArgument: (:) [Write-Verbose], ParameterBindingException
    + FullyQualifiedErrorId : PositionalParameterNotFound,Microsoft.PowerShell.Commands.WriteVerboseCommand

All the Write-Verbose lines have some syntax issues. Here is an example fix for one of the lines:

Original:
Write-Verbose "BpbEnabled                   :" (($flags -band $scfBpbEnabled) -ne 0)

Fixed:
Write-Verbose "BpbEnabled                   : $(($flags -band $scfBpbEnabled) -ne 0)"

Hello,
I can't get the last vulnerability mitigated on a patched OS with the last microcode that Intel says it should do on a 8700K.
Maybe I am missing something here? Is there anything else required here?
https://i.imgur.com/ocb0gfS.png

The picture shows that you have an affected processor (hardware is vulnerable), not that you haven't patched it.  I can see how that could be confusing, will see if we can make that more clear. If you go to the table that explains the different lines, you will see that vulnerable doesn't take into consideration whether you have the latest microcode or not. https://support.microsoft.com/en-us/help/4074629/understanding-the-output-of-get-speculationcontrolsettings-powershell

We wouldn't say that hardware is not vulnerable if you have the latest microcode because the hardware is still vulnerable. The microcode does not make it "not vulnerable".  For example, you are still vulnerable to the Kernel attack vector (CVE-2018-3620) if you have updated microcode but haven't gotten the Windows updates. Hope this helps.