Recently, academics from the Vrije University’s Systems and Network Security Group (VUSec) have published details about CrossTalk or SRBDS (CVE-2020-0543) vulnerability in Intel processors. The CrossTalk vulnerability allows attacker-controlled code executing on one CPU core to leak sensitive data from other software running on a different core. In this article, we will show you how to mitigate this Intel CPU vulnerability without a server reboot.

What is CrossTalk?

The CrossTalk vulnerability is a type of MDS (microarchitectural data sampling) attack, similar to Spectre, Meltdown or Zombieload. It allows the exposure and stealing of sensitive data while the machine accesses them. MDS attacks target user data while in a transitory state, as it’s been residing inside the CPU and many systems connected with it.

SRBDS/CrossTalk vulnerability is a transient execution vulnerability. Named as a “Special Register Buffer Data Sampling” or SRBDS (CVE-2020-0543) by Intel, it allows attacker-controlled code executing on one CPU core which results in leaking of sensitive data from victim software executing on a different core.



<img alt="Design of the instruction profiling stage of CrossTalk" data-ezsrc="https://kirelos.com/wp-content/uploads/2020/06/echo/webpnet-resizeimage.png5eea3c938d5a9.jpg" ezimgfmt="rs rscb1 src ng ngcb1" height="263" src="data:image/svg xml,” width=”500″>

Figure 1: Design of the instruction profiling stage of CrossTalk, courtesy of VUSec

Any system that is using an Intel CPU may be affected by this vulnerability. Check here if your CPU is affected.

Rebootless Mitigation of SRBDS (CVE-2020-0543) Vulnerability

Intel has implemented its mitigation for the SRBDS vulnerability in a microcode update distributed to software vendors on Tuesday, June 9, 2020. This mitigation requires the installation of the latest Linux Kernel patches & microcode update. Both operations are traditionally performed on reboot.

While rebooting a couple of servers doesn’t sound like a problem, if you are a SysAdmin who is taking care of 500 servers – it sure is. Rebooting a whole server fleet usually requires a thorough maintenance window planning. Fortunately, live patching technology allows applying security updates the systems against CrossTalk without a reboot, both for microcode update and Linux kernel patch application.

Canonical, Red Hate and other distribution vendors have released the security patches for all supported Ubuntu distributions, Debian, CentOS, Red Hat Enterprise Linux. And, although Canonical & Red Hat have their own solution for patching vulnerabilities without a reboot, in the case of SRBDS/CrossTalk you still need to reboot a desktop or a server after the update.

KernelCare team has created a rebootless mitigation for CrossTalk/SRBDS so that you could avoid rebooting the servers to apply the patches. Find the instructions below:

A) If you are running on hardware, take 3 steps to protect your servers from CrossTalk/SRBDS vulnerability without a reboot:

Step 1: Sign up for a free trial license of KernelCare

KernelCare is free to use for 30 days on all your servers, no credit card required to sign up for a trial. It is also free for healthcare organisations for the remainder of 2020 and forever free for non-profit organisations.

Step 2: Update Microcode without a reboot

Example: Updating microcode on RHEL

This is the example of a rebootless microcode update on RHEL. Instructions for Debian, Ubuntu, CentOS and other distributions can be found in KernelCare Documentation.

For RHEL-based distributions, you can use the microcode_ctl utility to update microcode. 

Before you start, check here if the patches for your distribution are ready. The page is updated every hour.

1. Get the latest microcode by updating the microcode_ctl package

yum update microcode_ctl

2. Create a force-late-intel–06–4f–01 inside the firmware directory.

touch /lib/firmware/`uname -r`/force-late-intel-06-4f-01

3. Run the microcode update

/usr/libexec/microcode_ctl/update_ucode

4. Force the kernel to load the new microcode

echo 1 > /sys/devices/system/cpu/microcode/reload

5. Check the new microcode

dmesg | grep microcode

[ 2.254717] microcode: sig=0x306a9, pf=0x10, revision=0x12

[ 2.254820] microcode: Microcode Update Driver: v2.01 <[email protected]>, Peter Oruba

[ 1483.494573] platform microcode: firmware: direct-loading firmware intel-ucode/06-3a-09

[ 1483.495985] microcode: updated to revision 0x21, date = 2019-02-13

[ 1483.496012] platform microcode: firmware: direct-loading firmware intel-ucode/06-3a-09

[ 1483.496698] platform microcode: firmware: direct-loading firmware intel-ucode/06-3a-09

[ 1483.497391] platform microcode: firmware: direct-loading firmware intel-ucode/06-3a-09

6. (Optional) Double check the new microcode version (revisions per core)

cat /proc/cpuinfo | grep -e microcode

microcode : 0x21

microcode : 0x21

microcode : 0x21

microcode : 0x21

Step 3: Apply KernelCare patches

Now you need to 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. If you signed up for the trial on Step 1 – you are all set and do not have to do anything else.

B) If you are running on VM:

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.Advertisements

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 – sign up for a free 30-day trial.

Show Comments