New Intel chip vulnerability reported

i’m still reading through the wired (disclaimer: behind soft paywall) article, but wanted to share since it seems like this is a fairly new report. the article mentions that intel was informed as far back as a year ago, but asked the researchers to delay their reports until intel could release a fix. so far amd and arm processors seem to be in the clear and of course intel is saying it is less severe than the researchers.

the second link (still haven’t read it) appears to be from some of the researchers and has a tool to test if your system is affected at the bottom. according to the wired article, this affects processors made as far back as 2008 and intel only just began selling some with the fix baked in so that should be most of the ones still in service.

https://mdsattacks.com/

3 Likes

i had meant to add that there windows, apple and android fixes were mentioned in the wired article, but nothing about linux.

3 Likes

Thanks for pointing this out!!!

Note : if you got the spectre-meltdown detect script previously from :

Either refresh it by :
git pull --ff-only

Or grab a fresh copy (you need to be root or run it via sudo to get correct results)

5 Likes

Mint provided an update for this yesterday through update manager and I think most Linux OSes will do so as well. I have not seen it listed in the Windows Updates list that has come out, so those using both should be aware of that.
Thanks for posting the warning.

4 Likes

I’m getting a new linux image installed now on Disco Dingo…

Be weeks/months before I can get anything rolled out for the RHEL/CENTOS/Oracle Linux boxes I manage for customers…

Discoveries :
Latest 0 day patches for Ubuntu (Disco Dingo) fix it…
AMD CPU aren’t vulnerable (at least not my Phenom II X6 - and AMD Turion II)
ARM CPU are vulnerable (despite all the press only mentioning Intel) : my BPi running Armbian (18.04 - i.e. Ubuntu for ARM), my OPi Win Plus running Armbian (18.04 - i.e. Ubuntu for ARM), my Raspberry Pi running Raspbian (Stretch) are all vulnerable to this new bunch of flaws… also my Orange Pi+ 2E with Armbian (16.04) is vulnerable

Updating/upgrade + rebooting ARM devices doesn’t fix it…

FreeBSD on AMD is not vulnerable to the newest stuff - but still vulnerable to CVE-2017-5753 and CVE-2017-5715 (BSD haven’t mitigated these yet)

4 Likes

Do you remember what’s the name of the update? I want to be on the watch for it.

1 Like

Is this something every Linux user should do?

1 Like

It was the intel microcode update which was put out yesterday and it will show that you haven’t updated by a red x in the shield for updates, if you’ve already done it then you will have a tick in the update shield - if you are using Mint that is. I don’t know about other OSes as I don’t use them.

1 Like

I ran that mds tool, with the following results:
MDSTool_Result

1 Like

I prefer the output of the script from GitHub - speed47/spectre-meltdown-checker: Spectre, Meltdown, Foreshadow, Fallout, RIDL, ZombieLoad vulnerability/mitigation checker for Linux & BSD

SUMMARY: 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

to the output of that binary “mds tool”…

I’ve read reviews of the Speed47 check script, and it’s been extensively vetted and people like RedHat point to it, and there’s been hundreds of commits by interested third parties - so I trust it :

That MDS tool tells me (I think? It’s a bit vague) I’m still vulnerable to all the previous variants of Spectre/Meltdown, but only 1 of the latest (i.e. MDS) :


Note : Speed47 script reports ARM vulnerable to MDS and the most recent flaws, however, this page says not - so maybe Speed47 script is reporting a false positive? :

1 Like

my system showed multiple vulnerabilities as well after running the mds tool. i am still working my way through some reading for this one, but i thought i would pass along the link (below) i found that gives intel’s response as far as mitigation goes. i will try an update && upgrade first to see if that changes things. if not, i will follow the links :slight_smile:

1 Like

Just ran this script and apparently one of my Raspi 3Bs is not vulnerable. Nice to see.

2 Likes

What you running on it? DietPi?

Speed47 script tells me my Raspi 3B is vulnerable, running Raspbian Stretch (Debian 9) :

SUMMARY: 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:KO CVE-2018-12130:KO CVE-2018-12127:KO CVE-2019-11091:KO

(all those “KO” come up in red, indicating not mitigated)

However one of those links I posted states ARM is not affected…

1 Like

SUMMARY: 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

  Operating System: Raspbian GNU/Linux 9 (stretch)
            Kernel: Linux 4.14.98-v7+
      Architecture: arm

DietPi is at its core based on Raspbian Mini.

1 Like

Thanks for posting, I ran this tool (linux) and lots of vulnerabilities, hoping for a fix, real soon!

2 Likes

I’m coming up immune now!!!

Stephane Lesimple (author of Speed47 checker script) didin’t update the internal version number of the shell script when he updated it yesterday or the day before - it was still showing a : VERSION=‘04.0’ - the same version it had been on months ago (but it was updated!).

I just refreshed the copy on my RPi 3B (git pull --ff-only) - and now it reports internally as VERSION=‘04.1’
and :
> SUMMARY: 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 :

4 Likes

SUMMARY: CVE-2017-5753:KO CVE-2017-5715:KO CVE-2017-5754:KO CVE-2018-3640:OK CVE-2018-3639:KO CVE-2018-3615:OK CVE-2018-3620:KO CVE-2018-3646:OK CVE-2018-12126:KO CVE-2018-12130:KO CVE-2018-12127:KO CVE-2019-11091:KO
It seems I got a lot of ‘KO’ (red). What do I do now?

1 Like

Depends which distro you’re using…

On Ubuntu 19.04 I just did “sudo apt upgrade” - then rebooted and I get the all clear…

Also did something similar on Oracle Enterprise Linux (OEL) 7.2 (locked to 7.2)… “sudo yum update” then rebooted… this OEL is a VM running in vbox (on my Ubuntu 19.04 laptop) - I still get
CVE-2018-3640:KO CVE-2018-3639:KO

However, running OEL 7.2 (locked to 7.2) on VMware ESX platform - those two give “OK” :
CVE-2018-3640:OK CVE-2018-3639:OK

I wouldn’t be too concerned if I was you - the biggest mitigation for ALL of these flaws is to not have your machine directly on the internet without some firewall doohickey (e.g. like your firewall/router device). If you do have stuff on the intewebs (like my RaspberryPi) make sure SSH is not listening on the default port, lock down things like PHP, use fail2ban…

If you’re on a public wifi access point - then yes - be concerned…

One thing to bear in mind, taking advantage these vulnerbilities is probably beyond the capabilities of most script kiddies (i.e. 90% of self identifying “hackers”)

4 Likes

In Mint you can just do this: in the terminal type - dmesg | grep isolation
It should return this when you do that -[ 0.000000] Kernel/User page tables isolation: enabled
This is what mine did as I ensure that I do all the updates when they come up
More information can be found here, https://en.wikipedia.org/wiki/Kernel_page-table_isolation

I found this on the Mint forum so can not claim credit for it, I had used it before, but had forgotten about it and hadn’t put it in my notes, which I will do so now.

3 Likes