The BigFix team has developed content that leverages a PowerShell script Microsoft created to determine whether your Windows systems are vulnerable to the “speculative execution side-channel attacks” that were recently disclosed. We are releasing this through this forum post as downloads. The content includes a Fixlet that will run the Microsoft v1.0.4 script and an Analysis which contains three properties that represent Microsoft’s three suggested mitigation actions and whether your machines need them. The analysis also collects the raw data from Microsoft’s script.
Run the Fixlet. There are two actions available; one is a one-time action and another will run the action as a policy. Running the Fixlet as a policy action will cause it to run once per day by default.
Activate the analysis.
Run any remediations suggested by the analysis.
If you ran the original Fixlet as a one-time action, rerun the Fixlet in order to determine whether your machines are still vulnerable and update the analysis results.
Using this content, the following report view can be generated via the Explore Data view in Web Reports to provide an overview of Microsoft’s suggested actions in your environment:
Notes
This content is being released as-is to get a valuable tool to our community. As of now we have no plans to release this through a BigFix content site. Please test before releasing broadly. We’ll be monitoring this thread for your feedback.
Microsoft included instructions for running the PowerShell script that would only work on PowerShell 5. We created the Fixlet in a way that we have seen to work on PowerShell 2. If you need to run this on earlier versions of PowerShell, you will have to modify the Fixlet. Please let us know of your results in this thread.
Check the .bes file for any erroneous characters or differences between the files on github, starting with the line and character referenced. The files are valid, but depending on how you copied them to your console system, some characters could have been modified/lost.
One thing that I noticed in my testing of earlier versions is the instances where the second half of the script fails with the “unsupported processor manufacturer:” line. When this occurs the properties for the Bios/Firmware suggested, Windows Update suggested, Additional Configurations suggested all return back “False” when they still may be vulnerable
I started testing a check for the error so at least it spits back “Error” instead of a false positive but I lost the Boolean True/False in the process. I am sure there is a cleaner way but something that I found value in (I am seeing this on 2-3%)
if exists (lines containing "Unsupported processor manufacturer:" of files "results_PS_SpeculationControl.txt" of folders "Logs" of folders "__Global" of data folders of client) then "Error" else lines containing "Install the latest available updates for Windows" of files "results_PS_SpeculationControl.txt" of folders "Logs" of folders "__Global" of data folders of client`
This is an edge case I didn’t hit so I wasn’t able to test. I’ll have to take a look at how I can address the relevance to deal with this, and I think I can.
This should be the “correct” relevance:
if (exists lines containing "Unsupported processor manufacturer:" of files "results_PS_SpeculationControl.txt" of folders "Logs" of folders "__Global" of data folders of client) then ERROR "PS Unsupported Processor" else ( exists lines containing "Install the latest available updates for Windows" of files "results_PS_SpeculationControl.txt" of folders "Logs" of folders "__Global" of data folders of client )
The error keyword lets you send a custom error message that is typeless… works for all types.
@sureshhan That is a needed step. Once you click RAW you can save page as, select all files, then give it a .bes ext.
Definitely not seeing as much of the Unsupported processor manufacturer error message after running on 10,000+ assets. A small number are getting different errors, but this is much smaller scale (So far less than 20 machines)
The errors that I am now seeing look like this (this is two different machine examples)
Raw SpeculationControl results
Add-Type : (0) : Warning as Error: Invalid search path 'C:\Program Files (x86)\
(1) : using System;
These are definitely unusual errors. Do you know what version of powershell is on these machines? (if you are using the new task & analysis, it should be reported as a property for this reason)
This is one of the things I miss about managing 10000+ machines is that you can be almost certain to hit every edge case imaginable which is terrifying, but also lets you smoke test stuff like this way better than most people can.
Looks like it varies, spot checked a couple machines that I see it on and its usually 2 or 5
I dont remember which machines i used before so here are 2 other machines with the same types of errors.
And so far its like 10-20 machines out of 17000 that have run the job and reported to the analysis. So much lower than the 800+ I was seeing before.
Powershell Version Used
2
Raw SpeculationControl results
Add-Type : (0) : Could not write to output file ‘c:\Windows\Temp\rvlc_oqr.dll’
(1) : using System;
Powershell Version Used
5
Raw SpeculationControl results
Add-Type : (0) : Could not write to output file ‘c:\Windows\Temp\bdbicmlk.dll’
(1) : using System;
These are probably bugs in the powershell script itself, but it is a bit odd how rare the errors seem to be. I wonder if there is AV or some other security policy/tool somehow stopping the script from doing what it is attempting?
Yes, it should be available by the end of the day. Need to check to see if any of the messaging / output has changed or what has changed in general to see how it has impacted the relevance.
also, there is a hard coded string in the command that executes the powershell to record the version of the script used in the output file. This is important so that you know that the previous results may be out of date as compared to what is available and that could be used to trigger a run of the script only on machines that haven’t run the newest version.
I took the time to make a template for this for the Fixlet Maker Dashboard so I could save some time updating this thing over time, and I can’t get it to work for some reason that I can’t determine, so that is great.
Look at the property Raw SpeculationControl results and Raw suggested actions to see the output.
TRUE means that those suggested actions show up in the results. TRUE means the powershell output suggests you are vulnerable in some way and the suggested actions appear. TRUE is a bad result or a false positive, FALSE is a good result or a false negative.
If you ran the task that the analysis reads before patching but have not run it again, then the analysis results will not update. Also, the task and analysis have been updated, and I am working on updating the task yet again.
[Add-Type], InvalidOperationExc