Avery serious security problem has been found in the Intel CPUs. Meltdown CPU Vulnerability CVE-2017-5754 breaks the most fundamental isolation between user applications and the operating system. This attack allows a program to access the memory, and thus also the secrets, of other programs and the operating system. How do I protect my Linux server and laptop/desktop against such attack?
A very serious security problem has been found and patched in the Linux kernel. It was announced on 3rd January 2018. It was independently discovered and reported by various teams including Google Project Zero.
What is the Meltdown security bug in Intel cpus?
From the xen project:
Processors give the illusion of a sequence of instructions executed one-by-one. However, in order to most efficiently use cpu resources, modern superscalar processors actually begin executing many instructions in parallel. In cases where instructions depend on the result of previous instructions or checks which have not yet completed, execution happens based on guesses about what the outcome will be. If the guess is correct, execution has been sped up. If the guess is incorrect, partially-executed instructions are cancelled and architectural state changes (to registers, memory, and so on) reverted; but the whole process is no slower than if no guess had been made at all. This is sometimes called “speculative execution”.
Unfortunately, although architectural state is rolled back, there are other side effects, such as changes to TLB or cache state, which are not rolled back. These side effects can subsequently be detected by an attacker to determine information about what happened during the speculative execution phase. If an attacker can cause speculative execution to access sensitive memory areas, they may be able to infer what that sensitive memory contained.
From the RHEL:
There are three primary variants of the issue which differ in the way the speculative execution can be exploited. Variant CVE-2017-5754 relies on the fact that, on impacted microprocessors, during speculative execution of instruction permission faults, exception generation triggered by a faulting access is suppressed until the retirement of the whole instruction block. In a combination with the fact that memory accesses may populate the cache even when the block is being dropped and never committed (executed), an unprivileged local attacker could use this flaw to read privileged (kernel space) memory by conducting targeted cache side-channel attacks. Note: CVE-2017-5754 affects Intel x86-64 microprocessors. AMD x86-64 microprocessors are not affected by this issue.
A list of affected Linux distros
- Red Hat Enterprise Linux 5 (including clones such as CentOS/Oracle/Scientific Linux 5)
- Red Hat Enterprise Linux 6 (including clones such as CentOS/Oracle/Scientific Linux 6)
- Red Hat Enterprise Linux 7 (including clones such as CentOS/Oracle/Scientific Linux 7)
- Debian Linux wheezy
- Debian Linux jessie
- Debian Linux stretch
- Deiban Linux buster, sid
- SUSE Linux Enterprise 11
- SUSE Linux Enterprise 12
- OpenSuse Linux based upon SUSE 12/11
- Fedora Linux 26
- Fedora Linux 27
- Amazon Linux AMI (Bulletin ID: ALAS-2018-939)
This page documents a current security event affecting many modern microprocessor designs. Information may change rapidly as the event progresses, and more info or commands added here soon. Please note that a patch for Ubuntu and many distros are not released yet. It will be released soon. When you run ‘apt-get upgrade’ or ‘yum update’ command make sure kernel package such as linux-image (Debian/Ubunt) kernel (RHEL) is updated.
Before updating system…
First, always keep backups. Second, note down the Linux kernel version running the following command:
$ uname -r
Please note that fix currently available for the following distros for sure:
- RHEL 7.x
- CentOS 7.x
- Fedora 26/27
- Debian stretch/jessie/wheezy
- Arch Linux
- Gentoo Linux
Fix the Meltdown on a CentOS/RHEL/Fedora/Oracle/Scientific Linux
Type the following yum command:
$ uname -r
$ sudo yum update
Sample outputs (from my CentOS 7.x server):
Resolving Dependencies --> Running transaction check ---> Package iwl100-firmware.noarch 0:126.96.36.199-56.el7 will be updated ---> Package iwl100-firmware.noarch 0:188.8.131.52-57.el7 will be an update ---> Package iwl1000-firmware.noarch 1:184.108.40.206-56.el7 will be updated ---> Package iwl1000-firmware.noarch 1:220.127.116.11-57.el7 will be an update ---> Package iwl105-firmware.noarch 0:18.104.22.168-56.el7 will be updated ---> Package iwl105-firmware.noarch 0:22.214.171.124-57.el7 will be an update ---> Package iwl135-firmware.noarch 0:126.96.36.199-56.el7 will be updated .... ... Dependencies Resolved ======================================================================================== Package Arch Version Repository Size ======================================================================================== Installing: kernel x86_64 3.10.0-693.11.6.el7 updates 43 M Updating: iwl100-firmware noarch 188.8.131.52-57.el7 updates 152 k ... .. python-perf x86_64 3.10.0-693.11.6.el7 updates 5.1 M qemu-img x86_64 10:1.5.3-141.el7_4.6 updates 678 k qemu-kvm x86_64 10:1.5.3-141.el7_4.6 updates 1.9 M qemu-kvm-common x86_64 10:1.5.3-141.el7_4.6 updates 416 k Removing: kernel x86_64 3.10.0-514.21.2.el7 @updates 148 M Transaction Summary ======================================================================================== Install 1 Package Upgrade 48 Packages Remove 1 Package Total download size: 117 M Is this ok [y/d/N]: y Downloading packages: Delta RPMs disabled because /usr/bin/applydeltarpm not installed. (1/49): iwl100-firmware-184.108.40.206-57.el7.noarch.rpm | 152 kB 00:00:00 .... .. microcode_ctl.x86_64 2:2.1-22.2.el7 python-perf.x86_64 0:3.10.0-693.11.6.el7 qemu-img.x86_64 10:1.5.3-141.el7_4.6 qemu-kvm.x86_64 10:1.5.3-141.el7_4.6 qemu-kvm-common.x86_64 10:1.5.3-141.el7_4.6 Complete!
You must reboot your Linux server using shutdown/reboot command:
$ sudo reboot
$ uname -r
Run the following dnf command if you are using a Fedora Linux:
$ sudo dnf --refresh update kernel
sudo dnf update
Reboot the Linux box:
$ sudo reboot
Fix the Meltdown on a Debian/Ubuntu Linux
Use the following apt-get command/apt command:
$ uname -r
$ sudo apt-get update
## better run the following instead of 'sudo apt-get upgrade'
$ sudo apt-get dist-upgrade
Reading package lists... Done Building dependency tree Reading state information... Done Calculating upgrade... Done The following NEW packages will be installed: linux-image-4.9.0-5-amd64 The following packages will be upgraded: linux-image-amd64 1 upgraded, 1 newly installed, 0 to remove and 0 not upgraded. Need to get 0 B/38.8 MB of archives. After this operation, 190 MB of additional disk space will be used. Do you want to continue? [Y/n] y Reading changelogs... Done Selecting previously unselected package linux-image-4.9.0-5-amd64. (Reading database ... 28066 files and directories currently installed.) Preparing to unpack .../linux-image-4.9.0-5-amd64_4.9.65-3+deb9u2_amd64.deb ... Unpacking linux-image-4.9.0-5-amd64 (4.9.65-3+deb9u2) ... Preparing to unpack .../linux-image-amd64_4.9+80+deb9u3_amd64.deb ... Unpacking linux-image-amd64 (4.9+80+deb9u3) over (4.9+80+deb9u2) ... Setting up linux-image-4.9.0-5-amd64 (4.9.65-3+deb9u2) ... I: /vmlinuz.old is now a symlink to boot/vmlinuz-4.9.0-4-amd64 I: /initrd.img.old is now a symlink to boot/initrd.img-4.9.0-4-amd64 I: /vmlinuz is now a symlink to boot/vmlinuz-4.9.0-5-amd64 I: /initrd.img is now a symlink to boot/initrd.img-4.9.0-5-amd64 /etc/kernel/postinst.d/initramfs-tools: update-initramfs: Generating /boot/initrd.img-4.9.0-5-amd64 /etc/kernel/postinst.d/zz-update-grub: Generating grub configuration file ... Found linux image: /boot/vmlinuz-4.9.0-5-amd64 Found initrd image: /boot/initrd.img-4.9.0-5-amd64 Found linux image: /boot/vmlinuz-4.9.0-4-amd64 Found initrd image: /boot/initrd.img-4.9.0-4-amd64 Found linux image: /boot/vmlinuz-4.9.0-3-amd64 Found initrd image: /boot/initrd.img-4.9.0-3-amd64 done Setting up linux-image-amd64 (4.9+80+deb9u3) ...
Reboot the box:
$ sudo shutdown -r 0
$ uname -r
Fix the Meltdown on an Amazon Linux running on AWS
Just run yum command:
# yum update kernel
Fix the Meltdown on an Arch Linux
Just run pacman command:
# pacman -Syu