Vulnerabilities are becoming like celebrities, with freaky names and their own websites.
The latest ones to hit the scene are Zombieload, RIDL and Fallout, also known as Microarchitectural Data Sampling, (MDS for short), discovered by Intel and researched by academic departments at security-focused institutions around the world. These vulnerabilities are in the same vein as Spectre and Meltdown, being design flaws that reveal data. Zombieload is particularly worrying because it affects all Intel Core and Xeon CPUs manufactured since 2011.
There are four distinct vulnerability registrations combining to make a Zombieload exploit possible: CVE–2018–12126, CVE–2018–12127, CVE–2018–12130, and CVE–2019–11091. Look at the codes and you’ll see three were registered last year. The issue has been kept under wraps, a practice known as Coordinated Disclosure, to stop ‘bad actors’ exploiting vulnerabilities before the rest of us can defend against them. Microsoft, Amazon AWS and Google have all mitigated the problem in their data centers, being in the ‘inner circle’ of companies benefiting from advance notice of such problems. Anyone else has to wait for an update from their OS vendor.
KernelCare started testing live patches for MDS on Friday, May 17, and they are now rolled out for all main distributions, with others shortly to follow. For the latest news, follow us on @KernelCare.
Watch the video with the insights regarding MDS from Igor Seletskiy below, or scroll down for instructions on how to mitigate the MDS/Zombieload Vulnerability with no rebooting required.
How to mitigate the MDS/Zombieload Vulnerability
If you are running on hardware:
To mitigate this vulnerability, you will need to take 3 steps that require no reboot if you follow the instructions below:
Microcode is the code that runs inside the CPU itself and is handled by Intel. Microcode update is usually done on reboot: you get the new kernel, it will have new microcode and when the kernel boots it will install new microcode into CPU. You can update microcode without reboot using our instructions.
If you don't disable the CPU simultaneous multithreading (SMT) - you will still have an issue that attacker can read the data of the same CPU. With KernelCare you can disable Hyperthreading without a reboot using our instructions.
Step 3: Apply KernelCare patches
Even if you have done steps 1 and 2, you must still update the Linux Kernel to ensure that the local user can not read the data you are running on the CPU. With KernelCare you can do that without rebooting. Sign up for the free 30-day trial.
If you are running on a Virtual Machine:
You only need to patch the Linux Kernel inside the VM. Make sure that your host node is updated as well which is typically done by your service provider.
If you are using your KernelCare - your patches will be delivered automatically by KernelCare and you don't need to do anything extra. If not - this is the right time to sign up for the free 30-day trial.
Updated Monday, June 10
The KernelCare patch release schedule is shown below. Release schedules are subject to change. Check here regularly or get in touch with our helpdesk.
Released to production:
- CentOS 6
- CentOSPlus for CentOS 6
- CloudLinux OS 6
- Debian 8
- Debian 9
- Ubuntu 14.04 LTS (Trusty Tahr)
- Ubuntu 16.04 LTS (Xenial Xerus)
- Ubuntu 18.04 LTS (Bionic Beaver)
- Oracle Enterprise Linux 6
- Oracle Enterprise Linux 7
- Oracle UEK 3
- Oracle UEK 4
- Oracle UEK 5
- Proxmox VE
- Red Hat Enterprise Linux 6
- Red Hat Enterprise Linux 7
- Amazon Linux 1
- Amazon Linux 2
Patches from the production feed will be applied automatically.
Released to the test feed:
- CentOS 7
- CentOSPlus for CentOS 7
- Cloud Linux 6 hybrid
To install patches from the test feed, run the command:
kcarectl --test --update
When production updates are available, KernelCare will use the regular feed automatically.
Due Week 24:
- CentOS 7
- CentOSPlus for CentOS 7
- CloudLinux OS 7
- Oracle Enterprise Linux