How to mitigate the Spectre and Meltdown vulnerabilities on Linux systems?

Security researchers have published on the Project Zero a new vulnerability called Spectre and Meltdown allowing a program to steal information from a memory of others programs. It affects Intel, AMD and ARM architectures.

This flaw can be exploited remotely by visiting a JavaScript website. Technical details can be found on redhat website, Ubuntu security team.

Information Leak via speculative execution side channel attacks (CVE-2017-5715, CVE-2017-5753, CVE-2017-5754 a.k.a. Spectre and Meltdown)

It was discovered that a new class of side channel attacks impact most processors, including processors from Intel, AMD, and ARM. The attack allows malicious userspace processes to read kernel memory and malicious code in guests to read hypervisor memory. To address the issue, updates to the Ubuntu kernel and processor microcode will be needed. These updates will be announced in future Ubuntu Security Notices once they are available.

Example Implementation in JavaScript

As a proof-of-concept, JavaScript code was written that, when run in the Google Chrome browser, allows JavaScript to read private memory from the process in which it runs.

My system seem to be affected by the spectre vulnerability. I have compiled and executed this proof-of-concept (spectre.c).

System information:

$ uname -a
4.13.0-0.bpo.1-amd64 #1 SMP Debian 4.13.13-1~bpo9+1 (2017-11-22) x86_64 GNU/Linux

$ cat /proc/cpuinfo
model name  : Intel(R) Core(TM) i3-3217U CPU @ 1.80GHz

$gcc --version
gcc (Debian 6.3.0-18) 6.3.0 20170516

How to mitigate the Spectre and Meldown vulnerabilities on Linux systems?

Further reading: Using Meltdown to steal passwords in real time.

Update

Using the Spectre & Meltdown Checker after switching to the 4.9.0-5 kernel version following @Carlos Pasqualini answer because a security update is available to mitigate the cve-2017-5754 on debian Stretch:

CVE-2017-5753 [bounds check bypass] aka 'Spectre Variant 1'
* Checking count of LFENCE opcodes in kernel:  NO  (only 31 opcodes found, should be >= 70)
> STATUS:  VULNERABLE  (heuristic to be improved when official patches become available)

CVE-2017-5715 [branch target injection] aka 'Spectre Variant 2'
* Mitigation 1
*   Hardware (CPU microcode) support for mitigation:  NO 
*   Kernel support for IBRS:  NO 
*   IBRS enabled for Kernel space:  NO 
*   IBRS enabled for User space:  NO 
* Mitigation 2
*   Kernel compiled with retpoline option:  NO 
*   Kernel compiled with a retpoline-aware compiler:  NO 
> STATUS:  VULNERABLE  (IBRS hardware + kernel support OR kernel with retpoline are needed to mitigate the vulnerability)

CVE-2017-5754 [rogue data cache load] aka 'Meltdown' aka 'Variant 3'
* Kernel supports Page Table Isolation (PTI):  YES 
* PTI enabled and active:  YES 
> STATUS:  NOT VULNERABLE  (PTI mitigates the vulnerability)

Update Jan 25 , 2018

The spectre-meltdown-checker script is officially packaged by debian , it is available for Debian Stretch through backports repository , Buster and Sid.

Update 05/22/2018

Speculative Store Bypass (SSB) – also known as Variant 4

Systems with microprocessors utilizing speculative execution and speculative execution of memory reads before the addresses of all prior memory writes are known may allow unauthorized disclosure of information to an attacker with local user access via a side-channel analysis.

Rogue System Register Read (RSRE) – also known as Variant 3a

Systems with microprocessors utilizing speculative execution and that perform speculative reads of system registers may allow unauthorized disclosure of system parameters to an attacker with local user access via a side-channel analysis.

Edit July 27 , 2018

NetSpectre: Read Arbitrary Memory over Network

In this paper, we present NetSpectre, a new attack based on
Spectre variant 1, requiring no attacker-controlled code on the
target device, thus affecting billions of devices. Similar to a local
Spectre attack, our remote attack requires the presence of a Spectre
gadget in the code of the target. We show that systems containing
the required Spectre gadgets in an exposed network interface or API
can be attacked with our generic remote Spectre attack, allowing to
read arbitrary memory over the network. The attacker only sends
a series of crafted requests to the victim and measures the response
time to leak a secret value from the victim’s memory.

Answers:

Thank you for visiting the Q&A section on Magenaut. Please note that all the answers may not help you solve the issue immediately. So please treat them as advisements. If you found the post helpful (or not), leave a comment & I’ll get back to you as soon as possible.

Method 1

Alan Cox shared a link from AMD’s blog:
https://www.amd.com/en/corporate/speculative-execution

Variant One: Bounds Check Bypass

Resolved by software / OS updates to be made available by system
vendors and manufacturers. Negligible performance impact expected.

Variant Two: Branch Target Injection

Differences in AMD architecture mean there is a near zero risk of
exploitation of this variant. Vulnerability to Variant 2 has not been
demonstrated on AMD processors to date.

Variant Three: Rogue Data Cache Load

Zero AMD vulnerability due to AMD architecture differences.

It would be good to have confirmation of these AMD’s statements by a third party though.

The ‘mitigation’ on affected systems, would require a new kernel and a reboot, but on many distributions there is not yet released packages with the fixes:

Debian:

Other sources of information I found:

Method 2

January 27, 2018 Intel Microcode breaks some systems

The Intel Microcode Update 2018-01-08 to address speculative execution branching security holes broke some systems. This effected many Ubuntu systems from January 8th to January 21st. On January 22, 2018 Ubuntu released an update that puts back older Microcode from 2017-07-07.

If you experienced problems with updates, reinstalled Ubuntu and turned off updates between 2018-01-08 and 2018-01-22 you may want to try Ubuntu automatic updates again.

January 16, 2018 update Spectre in 4.14.14 and 4.9.77

If you are already running Kernel versions 4.14.13 or 4.9.76 like I am it’s a no-brainer to install 4.14.14 and 4.9.77 when they come out in a couple of days to mitigate the Spectre security hole. The name of this fix is Retpoline and doesn’t have the severe performance hit previously speculated:

Greg Kroah-Hartman has sent out the latest patches for the Linux 4.9
and 4.14 point releases, which now include the Retpoline support.

This X86_FEATURE_RETPOLINE is enabled for all AMD/Intel CPUs. For full
support you also need to be building the kernel with a newer GCC
compiler containing -mindirect-branch=thunk-extern support. The GCC
changes landed in GCC 8.0 yesterday and is in the process of
potentially being back-ported to GCC 7.3.

Those wanting to disable the Retpoline support can boot the patched
kernels with noretpoline.

Without getting into details of JavaScript here is how to immediately avoid the Meltdown hole (and as of January 10 2018, Spectre protection)

January 12, 2018 update

Initial protection from Spectre is here and will be improved in weeks and months to come.

Linux Kernels 4.14.13, 4.9.76 LTS, and 4.4.111 LTS

From this Softpedia article:

Linux kernels 4.14.13, 4.9.76 LTS, and 4.4.111 LTS are now available
for download from kernel.org, and they include more fixes against the
Spectre security vulnerability, as well as some regressions from the
Linux 4.14.12, 4.9.75 LTS, and 4.4.110 LTS kernels released last week,
as some reported minor issues.

These issues appear to be fixed now, so it’s safe to update your
Linux-based operating systems to the new kernel versions released
today, which include more x86 updates, some PA-RISC, s390, and PowerPC
(PPC) fixes, various improvements to drivers (Intel i915, crypto,
IOMMU, MTD), and the usual mm and core kernel changes.

Many users had problems with Ubuntu LTS updates on January 4, 2018 and January 10, 2018. I’ve been using 4.14.13 for a couple of days without any problems however YMMV.


January 7, 2018 update

Greg Kroah-Hartman wrote a status update on the Meltdown and Spectre Linux Kernel security holes yesterday. Some may call him the second most powerful man in the Linux world right next to Linus. The article addresses stable kernels (discussed below) and LTS kernels which the majority of Ubuntu users have.


Linux Kernels 4.14.11, 4.9.74, 4.4.109, 3.16.52, and 3.2.97 Patch Meltdown Flaw

From this article:

Users are urged to update their systems immediately

Jan 4, 2018 01:42 GMT · By Marius Nestor

Linux kernel maintainers Greg Kroah-Hartman and Ben Hutchings have released new versions of the Linux 4.14, 4.9, 4.4, 3.16, 3.18, and 3.12 LTS (Long Term Support) kernel series that apparently patch one of the two critical security flaws affecting most modern processors.

The Linux 4.14.11, 4.9.74, 4.4.109, 3.16.52, 3.18.91, and 3.2.97 kernels are now available to download from the kernel.org website, and users are urged to update their GNU/Linux distributions to these new versions if they run any of those kernel series immediately. Why update? Because they apparently patch a critical vulnerability called Meltdown.

As reported earlier, Meltdown and Spectre are two exploits that affect nearly all devices powered by modern processors (CPUs) released in the past 25 years. Yes, that means almost all mobile phones and personal computers. Meltdown can be exploited by an unprivileged attacker to maliciously obtain sensitive information stored in kernel memory.

Patch for Spectre vulnerability still in the works

While Meltdown is a serious vulnerability which can expose your secret data, including passwords and encryption keys, Spectre is even worse, and it’s not easy to fix. Security researchers say it will haunt us for quite some time. Spectre is known to exploit the speculative execution technique used by modern CPUs to optimize performance.

Until the Spectre bug is patched too, it is strongly recommended that you at least update your GNU/Linux distributions to any of the newly released Linux kernel versions. So search the software repositories of your favorite distro for the new kernel update and install it as soon as possible. Don’t wait until it’s too late, do it now!


I had been using Kernel 4.14.10 for a week so downloading and booting Ubuntu Mainline Kernel version 4.14.11 wasn’t too much of a concern for me.

Ubuntu 16.04 users might be more comfortable with 4.4.109 or 4.9.74 kernel versions which were released at the same time as 4.14.11.

If your regular updates do not install the Kernel version you desire you can do it manually following this Ask Ubuntu answer: https://askubuntu.com/questions/879888/how-do-i-update-kernel-to-the-latest-mainline-version/879920#879920


4.14.12 – What a difference a day makes

Less than 24 hours after my initial answer a patch was released to fix 4.14.11 kernel version that they may have rushed out. Upgrading to 4.14.12 is recommended for all 4.14.11 users. Greg-KH says:

I’m announcing the release of the 4.14.12 kernel.

All users of the 4.14 kernel series must upgrade.

There are a few minor issues still known with this release that people
have run into. Hopefully they will be resolved this weekend, as the
patches have not landed in Linus’s tree.

For now, as always, please test your in environment.

Looking at this update not very many lines of source code were changed.

Method 3

The fact that this is exploitable using JavaScript isn’t the main point, and shouldn’t be the main concern (although it is a major one because this way remote code can easily be executed on your system, but this isn’t the only way this can happen).

Your focus shouldn’t lie on Javascript and/or your browser. Ideally, your CPU should be patched. Unfortunately, for most of the current wave of bugs this doesn’t appear to be possible. Debian, together will all other OS-providing parties thus go the only other possible way short of recommending a CPU which isn’t flawed: they force the system to workaround the bug in the CPU. Those patches don’t fix the problems. Instead, the OS hides them the best it can from any program a user runs on the machine (and thus, also your browser).

This hiding is extra computational work, and thus your overall system performance will be lower than without. How much lower depends likely heavily on what exactly those programs do.

With that in mind back to your question: what you can do to protect your Debian system is to install security updates. I trust that Debian will do everything possible in the light of these bugs to run Debian as securely as possible despite the inherent CPU flaws.

All sorts of big companies are already working on this issue, and so are numerous hardware and Linux gurus. I don’t want to absolutely hold you back from trying something yourself or from trying to help the general effort. However, if your own security and a timely fix is all you are interested in, then most likely they will find a better solution in shorter time than you would, starting now to look into this yourself.

Method 4

This flaw can be exploited remotely by visiting a JavaScript website.

Indeed. So, one sensible mitigation is to disable JavaScript in your web browsers, or to use web browsers that do not support JavaScript.

Most browsers that do support JavaScript have a setting for disabling it. Alternatively, if you wish to maintain a whitelist of sites or domains for which to allow JavaScript, then there are various add-ons that can assist, such as uBlock Origin and NoScript.

N.B. It should go without saying that disabling/restricting JavaScript should not be your only mitigation. You should additionally review (and probably apply) any relevant kernel fixes and other security updates once they are written, tested and published. On Debian-derived distributions, use commands such as sudo apt update, sudo apt list-upgradable, and sudo apt upgrade.

Update: don’t take my word for it. Alan Cox says much the same:

What you do need to care about big time is javascript because the exploit can be remotely used by javascript on web pages to steal stuff from your system memory. … consider things like Adblockers and extensions like noscript that can stop a lot of junk running in the first place. Do that ASAP. When OS updates appear apply them. (Source)


All methods was sourced from stackoverflow.com or stackexchange.com, is licensed under cc by-sa 2.5, cc by-sa 3.0 and cc by-sa 4.0

0 0 votes
Article Rating
Subscribe
Notify of
guest

0 Comments
Oldest
Newest Most Voted
Inline Feedbacks
View all comments
0
Would love your thoughts, please comment.x
()
x