35

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.

12

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:

  • 12
    A whole bunch of AMD information is not going to help a questioner whose CPU is an Intel Core. – JdeBP Jan 4 '18 at 17:16
  • 4
    For the Linux kernel, see Greg Kroah-Hartman's post: kroah.com/log/blog/2018/01/06/meltdown-status – alanc Jan 6 '18 at 20:02
  • According to the debian pages linked above (and the pages linked therein) it seems that kernel patches will be distributed as the responsible vendors publish their microcode. However, from security-tracker.debian.org/tracker/CVE-2017-5754 (the only one fixed so far) it seems that fixes have only been made available to stable and unstable releases. Does anyone know if we can expect fixes for oldstable ("jessie")? I have not been able to find any statement by Debian or the Debian Security team on this matter... – Shevek Jan 7 '18 at 20:22
11

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.

  • 1
    Solution exists for Meltdown now, available via apt-get dist-upgrade. – luchonacho Jan 10 '18 at 13:53
  • 1
    On my phone now but update on LTS causes kernel panic on 1/10/2018. See Ask Ubuntu. – WinEunuuchs2Unix Jan 10 '18 at 14:10
  • 1
    Luckily I updated it with 109 (108 gives the kernel panic). So did not have that problem. It works fine. – luchonacho Jan 10 '18 at 16:04
  • 1
    @WinEunuuchs2Unix there are an update here USN-3531-2: Intel Microcode regression – GAD3R Jan 27 '18 at 10:17
  • 1
    @GAD3R Thank you very much for the link. It help me post an answer in Ask Ubuntu that could help many people: askubuntu.com/questions/998471/… – WinEunuuchs2Unix Jan 27 '18 at 16:53
6

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)

  • 5
    Excuse me, although this helps against the attac, without JS, you wouldn't have been able to leave the answer here. This advice is similar to "stop using the Internet" (in 2018). – Moritz Both Jan 7 '18 at 19:04
  • 4
    @MoritzBoth, thankfully, many sites work well without JS. Sadly, StackExchange does require JS for posting, as you point out. That is a (serious!) shortcoming in SE :( – sampablokuper Jan 7 '18 at 20:57
  • 3
    For FireFox a noScript like addon might help to reduce the usage of JavaScript on dubious sites - although the recent changes brought about by FF Quantum (V57) has lobbed a very big stone into the whole FF addon pool... – SlySven Jan 11 '18 at 0:59
  • 2
    Since the release of Quantum I've switched to Pale Moon, for exactly this reason. Works for me really well, including NoScript and Cookie Masters (once Cookie Monster). – Murphy Jan 11 '18 at 13:33
  • 2
    @MoritzBoth I really don't think that disabling JS amounts to "stop using the web", much less "stop using the internet". However, this is a great time to raise awareness on the issues that come with universal reliance on JS from some web content providers. – Tobia Tesan Jan 18 '18 at 5:53
5

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.