|
Since downloading the latest version, issuing the command: Invoke-Command -ComputerName server-name ${function:Get-SpeculationCont rolSettings} returns the error: You must provide a value expression on the right-hand side of the '-' operator. + CategoryInfo : ParserError: (:) [], ParseException + FullyQualifiedE rrorId : ExpectedValueEx pression + 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.microso ft.com/Forums/s criptcenter/en- US/9dd9b476-16c 6-4aa3-9b92-568 5f794a122/specu lationcontrol-n o-longer-works- remotely-agains t-hostnames-con taining-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- SpeculationCont rolSettings} Result received: You must provide a value expression on the right-hand side of the '-' operator. + CategoryInfo : ParserError: (:) [], ParseException + FullyQualifiedE rrorId : ExpectedValueEx pression + PSComputerName : C-DHCP-RELAY-01
Import-Module : The 'L:\SpeculationControl\Specula tionControl.psd 1' module cannot be imported because its manifest con ains one or more members that are not valid. The valid manifest members are ('ModuleToProce ss', 'NestedModules' , 'GUID , 'Author', 'CompanyName', 'Copyright', 'ModuleVersion' , 'Description', 'PowerShellVers ion', 'PowerShellHost Name', 'Po erShellHostVers ion', 'CLRVersion', 'DotNetFramewor kVersion', 'ProcessorArchi tecture', 'RequiredModule s', 'TypesToProce s', 'FormatsToProce ss', 'ScriptsToProce ss', 'PrivateData', 'RequiredAssemb lies', 'ModuleList', 'FileList', 'FunctionsT Export', 'VariablesToExp ort', 'AliasesToExpor t', 'CmdletsToExpor t'). Remove the members that are not valid ('RootModul '), then try to import the module again. At line:1 char:14 + Import-Module <<<< .\SpeculationCo ntrol.psd1 + CategoryInfo : InvalidData: (L:\Speculation C...ionControl. psd1:String) [Import-Module] , InvalidOperatio nException + FullyQualifiedE rrorId : Modules_Invalid ManifestMember, Microsoft.Power Shell.Commands. ImportModuleCom mand
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/w mf/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/Ge t-SpeculationCo ntrol-Powershel l2/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 BTIImportOptimi zationEnabled. 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 L1TFHardwareVul nerable from the same virtual devices. I have worked around this by assigning string NULL to outcome if logical $null is present: if($SSBDHardwar eVulnerable -eq $null) { $SSBDHardwareVu lnerable = "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-Speculation ControlSettings to variable, example $SC, and then list SuggestedAction s property with $SC.SuggestedAc tions. 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?
We've also tried using the 64/3 settings that are mentioned here for AMD servers: https://support.microsoft.com/ en-us/help/4072 698/windows-ser ver-guidance-to -protect-agains t-the-speculati ve-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/articl e/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/eg infolib/securit yalerts/Variant /Variant_Vulner abilities.html. The output of Version 1.0.11 is: BTIHardwarePres ent : True BTIWindowsSuppo rtPresent : True BTIWindowsSuppo rtEnabled : True BTIDisabledBySy stemPolicy : False BTIDisabledByNo HardwareSupport : False KVAShadowRequir ed : False KVAShadowWindow sSupportPresent : True KVAShadowWindow sSupportEnabled : False KVAShadowPcidEn abled : False SSBDWindowsSupp ortPresent : True SSBDHardwareVul nerable : True SSBDHardwarePre sent : False SSBDWindowsSupp ortEnabledSyste mWide : False L1TFHardwareVul nerable : False L1TFWindowsSupp ortPresent : True L1TFWindowsSupp ortEnabled : False L1TFInvalidPteB it : 0 L1DFlushSupport ed : False Also tried the values for FeatureSettings Override 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/4074 629/understandi ng-the-output-o f-get-speculati oncontrolsettin gs-powershell
Hi, non-compliant in regard of the SCCM Compliance Baseline developed by the MSFT SCCM Team here: https://gallery.technet.micros oft.com/Specula tion-Execution- Side-1483f621 Looking at the output of your script regarding SSBD: SSBDWindowsSupp ortPresent : True SSBDHardwareVul nerable : True SSBDHardwarePre sent : False SSBDWindowsSupp ortEnabledSyste mWide : False The SSBDHardwarePre sent = $false and SSBDWindowsSupp ortEnabledSyste mWide = $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/eg infolib/securit yalerts/Variant /Variant_Vulner abilities.html additionally to the Reg-Keys anything should be fine. B. Get-Speculation ControlSettings results to SSBDHardwarePre sent = $false and SSBDWindowsSupp ortEnabledSyste mWide = $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 SpeculationCont rol.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 .\SpeculationCo ntrol.psd1 You must provide a value expression on the right-hand side of the '-' operator. At SpeculationCont rol.psm1:237 char:73 + $l1tfInvalidPte Bit = ($flags -band $l1tfInvalidPte BitMask) - <<<< shr $l1tfInvalidPte BitShift + CategoryInfo : ParserError: (:) [], ParentContainsE rrorRecordExcep tion + FullyQualifiedE rrorId : ExpectedValueEx pression
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] , ParameterBindin gException + FullyQualifiedE rrorId : PositionalParam eterNotFound,Mi crosoft.PowerSh ell.Commands.Wr iteVerboseComma nd
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.pn g
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/4074 629/understandi ng-the-output-o f-get-speculati oncontrolsettin gs-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.