If you’re like me and like Linux enough to install it on hardware which is sold as a Windows running device then you’ll probably want to keep reading.
During the last 1 – 2 years or so we started seeing new vectors of attack being discovered / exploited which unfortunately come from cutting corners when designing the next generation of hardware – specifically CPUs (my focus is on CVE-2017-5753 CVE-2017-5715 CVE-2017-5754 CVE-2018-3640 CVE-2018-3639 CVE-2018-3615 CVE-2018-3620 CVE-2018-3646 CVE-2018-12126 CVE-2018-12130 CVE-2018-12127 CVE-2019-11091)
Chances of any of these being problematic for a home user might be slim BUT soon we might see a new one that could be extremely problematic and I think it is a good idea to know how to fix stuff like this (better to be prepared right ?)
I’m running CentOS7 on my notebook – which is a Dell Precision 5530 – (don’t ask why and also don’t bother with this, Linux distro is irrelevant here) and have been doing so for a while now ( if you’re one of my readers you might remember reading this article: https://cristian.seceleanu.co.uk/2019/04/usb-c-on-centos7/ ). Reasons for me operating a beast like this include: testing virtualization, playing with clustering, designing various setups for all sorts of services so it’s like a pre-staging environment which also means I need to see how some of these mitigations impact performance on my test setups.
Problem I faced when trying to fix these vulnerabilities using the DELL BIOS update tool was … there was no BIOS update tool released for Linux … they released a shitty .exe file which works on Win 2k10 (which in my case is useless) so the only way for me to fix the CVEs I listed above (or part of) was to do this at kernel level.
All said and done here’s what I ended up doing:
- searched online for a tool / script on linux that would help me identify CVEs my CPU is affected by and found this: https://github.com/speed47/spectre-meltdown-checker
- downloaded the tool and ran it as root
wget https://meltdown.ovh -O spectre-meltdown-checker.sh
chmod 755 spectre-meltdown-checker.sh
./spectre-meltdown-checker.sh
and confirmed I was vulnerable to last 4 of them (CVE-2018-12126 CVE-2018-12130 CVE-2018-12127 CVE-2019-11091) - searched online for the Intel microcode for my CPU and found this page:
https://downloadcenter.intel.com/download/28727/Linux-Processor-Microcode-Data-File?product=873 then went to this address:
https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files
then downloaded the repo as zip - checked I was running a new enough kernel version (a kernel that supports applying the microcode update) – you might want to run the latest kernel available for your distribution and reboot before proceeding – and followed the guide here: https://www.cyberciti.biz/faq/install-update-intel-microcode-firmware-linux/ by running following commands:
ls -l /sys/devices/system/cpu/microcode/reload(to confirm)cp -v intel-ucode/* /lib/firmware/intel-ucode/echo 1 > /sys/devices/system/cpu/microcode/reload
dracut -f (on CentOS7 there is noupdate-initramfs)
reboot - after the reboot i checked microcode was applied by running
dmesg | grep microcode
and re-running the script
./spectre-meltdown-checker.sh
which revealed I’m no longer affected by any of the CVEs I listed aboveSUMMARY: CVE-2017-5753:OK CVE-2017-5715:OK CVE-2017-5754:OK CVE-2018-3640:OK CVE-2018-3639:OK CVE-2018-3615:OK CVE-2018-3620:OK CVE-2018-3646:OK CVE-2018-12126:OK CVE-2018-12130:OK CVE-2018-12127:OK CVE-2019-11091:OK
Intel has not released microcode updates for ALL CPUs that are affected by all or some of the CVEs I mentioned above so don’t expect to be able to fix these on older hardware (many years old) also keep in mind that DELL and other vendors like them usually offer support for their hardware for a limited amount of time so even if Intel released updated microcode the vendors might not release BIOS updates for all the hardware they sold over time.
As I’ve said before, these CVEs are not particularly relevant / problematic on a personal computer / notebook / etc to which only a limited amount of ppl have access and which is generally hard to access remotely because it rarely has a public IP but then … what if ? …
Better to have it and not need it than not have it and need it.