Dtyjlui

There is this code going around that checks whether your kernel has been patched for Spectre and Meltdown.
It is at:
https://github.com/speed47/spectre-meltdown-checker

Other commentators have talked about the limitations of its method, but I have not found anyone say anything about whether it's safe to run as root.

Can somebody weigh in on the safety aspect of this script?

Does it do anything beyond checking for these vulnerabilities, such as changing system configuration or make any change that could survive beyond reboot?

Thank you

The script is actually checking the mitigations in kernel for all three vulnerabilities. By now the LTS systems and Ubuntu 17.10 have available mitigations for Meltdown vulnerability.

There is a C program to determine one of the Spectre vulnerabilities. You can check if your processor is vulnerable with:

wget https://gist.githubusercontent.com/ErikAugust/724d4a969fb2c6ae1bbd7b2a9e3d4bb6/raw/41bf9bd0e7577fe3d7b822bbae1fec2e818dcdd6/spectre.c



gcc spectre.c -o spectre -std=c99 -w -O0



./spectre

If you can see lines with:

Reading at malicious_x = 0xffffffffffdfebb8... Success: 0x54=’T’ score=7

Then your processor is vulnerable to Spectre branch prediction.

I have personally tested Intel Atom 1st gen, Core 2 Duo E8400, Core 2 Duo 4300 not to be vulnerable and Core i5 3230M, AMD Turion TL-56 to be vulnerable based on running this program.

First off, a few facts from the project's github page. At the time of writing this, it has 48 contributors and 355 forks. A contributor could be someone who's only seen part of the script and modified an area of interest to them but more likely than not, they've probably read through the whole thing to make the code contribution. So that's already a significant level of vetting. There are also 355 forks but seeing how all you have to do is hit a button to make one, make out of that what you will.

Next, one should never rely on Virus Total for checking scripts or source code. Maybe one day, AI will be written that can read through scripts/source code in order to check for malicious content but at the moment no one's really made a way of automatically verifying them. Anti-viruses look for binary signatures and may sometimes use a heuristic approach to analyze binary files. If you give an Anti-Virus a source code or a script, it will interpret it as a text file and tell you it's clean (creating a false sense of security).

Finally, I just finished reading through all 4500 lines of it and did not find anything that I found worrying.

Full disclosure, I only consider myself to be an intermediate bash script writer and this was quite an advanced script that I will probably be cannibalizing for tips and tricks for years to come. Although I was able to keep up with it, it is possible that I may have missed something because a lot was happening in it.

Most it's operations involve making reads in the kernel, cpuid, kernel config, the fs (the parts related to patch and kernel info it needs to it's job) and cpu's msr. It makes a few writes, extractions, dumps and de-compilations that happen in the temp folder and get deleted in the exit cleanup. The only time it uses the internet is to use wget to download a MCExtractor database from it's github page. It does not try to dial home in any way.

I only found two things of note when reading it: the first is that it makes two writes to the model-specific registers (msr) of the cpu (that's where among other things, CPU settings are stored). It was alarming at first but I have verified those writes using guidelines put out by Intel and the writes fall within its recommended parameters.

Second thing of note was that the script needs to download a SQLite3 database from a project called MCExtractor. I don't know the MCExtractor project and have not seen it's source code. Having not really felt like vetting yet another project just to run this script, I searched on the internet to see if there are any hazards from accessing sqlite3 dbs from an unknown source. There is indeed an exploit that can be done with sqlite3 called Magellan but it seems to be more linked to the query code execution aspect of sqlite3 rather than the db aspect of it. I'm personally not too worried about it but I thought I'd point the possibility out and let you make of it what you will. The exploit has been patched out of SQL 3.26 which is not yet in the Ubuntu Bionic or Cosmic repos. If you're worried about it, you can download the 3.26 libsqlite3 version directly from http://us.archive.ubuntu.com/ubuntu/pool/main/s/sqlite3/ as a deb file and install it using sudo dpkg -i name-of-deb-here.deb. I would recommend downgrading right after (again, using a deb file from the same place) as 3.26's currently classified as unstable in the changelogs.

This information relates to commit d7d2e69 of the project which you can find in this link.

It was made on Dec 11 2018 and the sha256sum of the script of that version is:
b0f884be51f0eb49ed61854f0e011a2f89f44c35699e07a705b0ec6f98fa29b5

And you probably use github's