Working on it, but nothing to report. Part of my issue is not having a bunch of Linux VMs set up for testing, another issue is working out issues with how I was downloading the script. I think I need to just test the script first, then try to figure out how I can get it onto a system in a secure manner… ideally using a prefetch.
Not sure I’ll get to this today @nicksberger … I just updated the MS Powershell task since they released version 1.0.3 of the module.
This uses chrome policies, but also assumes there are no existing chrome policies. Ideally this would be improved to add this setting to chrome policies regardless of if they already exist or not. Similar content could be created for Windows & Linux.
NOTE: this will cause chrome to use more resources, primarily RAM. I have not measured it’s impact in any way.
We ran into an odd issue with some of our Windows 10 machines where these patches would fail to install. After a Microsoft Premier case, we discovered that the patch did not like the USB storage device restrictions that were part of the hardening policies on these Windows 10 tablets. Upon lifting the USB storage restrictions/hardening, the patch is now applying successfully.
I’ve had this occur repeatedly with older patches as well. Our method (carried over from the XP days) was to add a System:DENY permission on usbstor.inf and usbstor.pnf to prevent USB Storage drivers from loading. This blocked installing many of the MS patches on Win2012, Win2016, and Win10 (presumably, because the patches could not overwrite the files).
Now, I reset the permissions on these two files when entering the patch window.
In the CIS Checklist sites, it looks like IBM’s approach is to rename the two files rather than block access permissions on them. And Win10 has some Group Policy settings that can be used to block the devices as well.
No clue why this is what it took, or if there is a more direct way to run it:
wait bash -c "bash /tmp/spectre-meltdown-checker.sh > { pathname of folders "Logs" of folders "__Global" of data folders of client }/results_SH_spectre-meltdown-checker.txt"
Once i got that figured out, I could go back to this way, which is what i was going for in the first place:
wait bash -c "bash '{pathname of file "spectre-meltdown-checker.sh" of folder "__Download" of client folder of current site}' > '{ pathname of folders "Logs" of folders "__Global" of data folders of client }/results_SH_spectre-meltdown-checker.txt'"
Task:
Note: I make no claims about the validity or safety of the script this runs:
It will need updated as the script is updated, which is intentional so that the script can be validated and not change over time until such time as it can be revalidated at a new version. Running arbitrary code from GitHub without vetting / validation is not recommend.
By default the output of the script has coloring info, which gets picked by the analysis. The task would need adjusted to not provide the coloring info.
Right now the analysis just reads the raw lines of the results file. I haven’t enhanced it to pull out any specific info for reporting, but that is a possibility if I have a better picture of the different results. The extra colorization stuff in the output doesn’t help currently.
Another heads-up: Intel is warning that the microcode / bios updates may cause reboots on some chips. Some indications they may have quietly told datacenter customers to delay bios updates.
This is very frustrating that the script isn’t just available. This will make it much harder to make bigfix content available for, which is what I just was looking into.
Looking at the Java fixlets for Windows, perhaps we could use the same technique where we have to manually download and cache it locally, complying with the license requirements of having to log in and obtaining the file via the RH Portal.
This is a nicer UI option than running powershell and it something that could be made available for IT Staff to run on machines they are on to validate settings or it could be made available to anyone if they are curious.
I haven’t tested this yet, but this is my first attempt at the RedHat detection script for meltdown/spectre. For now it requires manual caching of the script on the root server, but ideally it could use the RHEL download plugin instead, but I haven’t figured that part out yet.
I did a little different as RH 5/6 doesn’t mount automatically the /sys/kernel/debug:
prefetch spectre_meltdown.sh sha1:a2f5749d3fa420b0dcfdc5b37a0f4529cf988d78 size:11273 https://127.0.0.1:52311/Uploads/a2f5749d3fa420b0dcfdc5b37a0f4529cf988d78/spectre_meltdown.sh sha256:1c5843813d4e24be5c3e7f829c5c1a6c3028cf1dbe2d76cd55b15402d712b2c5
if { (NOT exists match (regex "Red Hat Enterprise (Client|Server|Workstation) 7") of name of operating system ) OR ( (NOT exists match (regex "CentOS.* 7") of name of it) of operating system ) }
delete "{(client folder of current site as string) & "/__createfile"}"
createfile until __EOF__
mount | grep "nodev on /sys/kernel/debug" > /dev/null 2>&1
if [ $? == 1 ]; then
mount -t debugfs nodev /sys/kernel/debug
bash '{pathname of file "spectre_meltdown.sh" of folder "__Download" of client folder of current site}' > '{ pathname of folders "Logs" of folders "__Global" of data folders of client }/results_spectre_meltdown.txt'
umount nodev
else
bash '{pathname of file "spectre_meltdown.sh" of folder "__Download" of client folder of current site}' > '{ pathname of folders "Logs" of folders "__Global" of data folders of client }/results_spectre_meltdown.txt'
fi
__EOF__
wait chmod 555 "{(client folder of current site as string) & "/__createfile"}"
wait bash "{(client folder of current site as string) & "/__createfile"}"
elseif
wait bash -c "bash '{pathname of file "spectre_meltdown.sh" of folder "__Download" of client folder of current site}' > '{ pathname of folders "Logs" of folders "__Global" of data folders of client }/results_spectre_meltdown.txt'"
endif
my understanding is that the script needs to have access to the /sys/kernel/debug files to get the correct results.
PS: if you run the script on RH5/6 without the mountpoint, the script itself ll ask to get it mounted.