Contents

About the Zombieload/MDS Vulnerability

Patch Release Schedule


About the Zombieload/MDS Vulnerability

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, rolling them out for the main distributions first, others later. For the latest news, follow us on @KernelCare.

While we are working on patches for you - watch the video with the insights regarding MDS from Igor Seletskiy:

How to mitigate the MDS/Zombieload Vulnerability

a) 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:

Step 1:

Update Microcode without a reboot

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.

Step 2:

Disable Hyperthreading without a reboot

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-days trial.

b) 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-days trial.

MDS/Zombieload Vulnerability Patch Release Schedule

Updated Friday, May 24

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
  • Ubuntu 18.04 LTS (Bionic Beaver)
  • Ubuntu 16.04 LTS (Xenial Xerus)
  • Oracle Enterprise Linux 6
  • Oracle Enterprise Linux 7
  • Oracle UEK 3
  • OpenVZ
  • Proxmox VE
  • Red Hat Enterprise Linux 6
  • Red Hat Enterprise Linux 7

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 Friday, May 24

  • Debian 8
  • Debian 9
  • CloudLinux OS 7
  • Oracle Enterprise Linux 

Due Monday, May 27

  • Amazon Linux 1
  • Amazon Linux 2
  • CentOS 7
  • CentOSPlus for CentOS 7
  • Oracle UEK 4
  • Oracle UEK 5
  • Ubuntu 14.04 LTS (Trusty Tahr)
New call-to-action

31 comments

  1. Why does Igor Seletskiy insist on being the voice, no one can understand a frigging word he says. We understand he is behind the start of this but FFS get someone who can be the voice in these videos!

    1. Hello Mine, this is Aleksandra Mitroshkina, Product Marketing Manager of KernelCare.
      I am sorry that you had to experience difficulties understanding the speaker. We will work on the voiceover to provide you with more understandable content in the future. Thank you so much for your feedback!

    1. Hello Andre, I'm not sure if you are referring to patches or how-to guides so I will answer both. We are now on the testing phase with patches. For some distributions, patches should be early next week.
      As for the How-to Guides mentioned in a video and a blog post - we'll publish these as soon as the first patches are in production.

    1. Hello Max, we are testing the patches now.
      We plan to start delivering patches early next week.
      Stay tuned for the updates.

    1. Hello Arthur, thank you for your question.
      Yes, we have this in the pipeline. Follow our social media channels to stay updated.

    2. Hello Arthur, I'm afraid that due to the internal miscommunication I have provided you with the wrong information about our future plans on OpenVZ 7 support by KernelCare. We are not planning to support this distribution.

  2. If I have cloudlinux OS with kernelcare on my server will this be updated with kernel care? Or do i need to manually do something?

    1. Hello Donovan, you will need to do microcode update and SMT disabling. But before you do that, diagnose your vulnerability using the guide in this article by CloudLinux OS Team.

      When you perform mictocode update and SMT disabling (you will know if you need to disable it from the link above) Linux Kernel Patches will be delivered by KernelCare automatically, without the reboot.

      1. Basically, if you haven't rebooted in some time, this won't work, because these dont exist:
        /sys/devices/system/cpu/vulnerabilities

  3. Why does a kernel update only work for VMs? Isn't an updated hypervisor and restart of it needed. I saw also updated qemu packages for the md-clear flag.

    1. Hi Stefan, It works for hard nodes too, but you need to update microcode and disable SMT - then the patches will be applied auеomatically - and without reboots, if you use KernelCare.

        1. Hi Stefan,
          Well, md-clear in qemu is a bit in cpuid for the guest information.
          The patched kernel will activate the protection in any case.

  4. Can you possibly ask CloudLinux's upstream (CentOS I guess?) when they'll upgrade microcode_ctl with the latest microcodes that will patch E5 v4 CPUs for example? The patches have been out for about a week, but no update to the microcode_ctl package 🙁

    Alternatively can CloudLinux push an updated package containing the 20190514 and not 20190507 - this way, us that runs v4 and v3 CPUs can actually get patched up as well.

      1. Hi Alexandra,

        the microcode_ctl package supplied by CloudLinux and by CentOS contains the microcodes 20190507 and not 20190514 (which is the latest).

        20190514 introduces a few new microcode versions since 20190507:

        VLV C0 6-37-8/02 00000838 Atom Z series
        VLV C0 6-37-8/0C 00000838 Celeron N2xxx, Pentium N35xx
        VLV D0 6-37-9/0F 0000090c Atom E38xx
        CHV C0 6-4c-3/01 00000368 Atom X series
        CHV D0 6-4c-4/01 00000411 Atom X series
        BDX-ML B0/M0/R0 6-4f-1/ef 0b00002e->00000036 Xeon E5/E7 v4; Core i7-69xx/68xx
        DNV B0 6-5f-1/01 00000024->0000002e Atom C Series

        1. Hi Lucas, you are correct, right now the microcode_ctl package supplied by CloudLinux and by CentOS only contains the 20190507 microcode, not 20190514. The reason behind that is that we usually follow the upstream updates of RHEL/CentOS. As soon as this microcode appears in the upstream - we will provide it for CloudLinuxOS.

      2. That microcode update manual is for RHEL7 only. It is not correct for CL6...

        stat: cannot stat `/usr/libexec/microcode_ctl/update_ucode': No such file or directory

        stat: cannot stat `/sys/devices/system/cpu/microcode/reload': No such file or directory

        1. Hello Deyan, thank you for bringing this to my attention! We are working on fixing the documentation now. Please accept my apologies for the inconvenience. I will mention you in comments when we fix it.

      3. On Intel(R) Xeon(R) CPU E5-2640 v4 @ 2.40GHz server running CL7 and SMT disabled with # echo off > /sys/devices/system/cpu/smt/control
        Microcode and Kernel upgraded with #yum upgrade microcode_ctl && yum install kernel-3.10.0-962.3.2.lve1.5.25.8.el7
        Server rebooted.
        # cat /sys/devices/system/cpu/vulnerabilities/mds returns the following;
        Vulnerable: Clear CPU buffers attempted, no microcode; SMT disabled

        1. INCORRECT, PLEASE DISREGARD THIS: Hi Paul, you need to update the actual microcode as described here, upgrading microcode_ctl package is not enough

          1. Hi Alexandra, that is not true. That manual is only to update microcode without reboot. Reboot should always apply new microcode, but it looks like that is not happening after your latest microcode_ctl package upgrade, so "/sys/devices/system/cpu/vulnerabilities/mds" always return "no microcode", even when microcode is applied manually.

          2. Hello Deyan, can you please create a ticket to our support team here. My colleagues will be able to dig deeper into technical details of your case and we will avoid back-and-forth in comments. Thank you!

          3. I think my post wasn't understood well. Do you mean you are now pushing microcode_ctl package 20190514 (which is the latest) and supports E5 v4 CPUs?
            Lucas Rolff asked when you'd support the same, and you asked which error he was getting trying to apply 20190507. In your response to him, you confirmed that the microcode_ctl package supplied by CloudLinux and by CentOS at the moment only contains the 20190507 microcode, not 20190514 which supports E5 v4 CPUs. So as at now, those of us using E5 v4 CPUs haven't patched up because the 20190507 microcode which you've supplied doesn't work for E5 v4 CPUs.

            Since you had asked Lucas for the error and he didn't provide. I proceeded and did. But I think your answer has pointed me to a different direction.

          4. Paul, Lucas, Deyan, sorry to misinform you - we have to wait for 20190514 microcode to become available from the upstream - we'll release it in CL OS soon after that

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

Have Questions?

If you'd like to schedule a demo of KernelCare, have questions, or with trial and sales inquiries, please call us at +1 (800) 231-7307, email [email protected], or fill out this form.