Linux vs. Zombieload

New ‘Spectre-class’ flaws in Intel CPUs might be revealed soon
Reports are emerging about eight new ‘Spectre-class’ security CPU vulnerabilities. Read more: https://zd.net/2wjWREu

Zombieload sounds like a bad horror adult film, but it’s actually the latest class of Intel processors security vulnerabilities. Discovered by researchers, attackers can use Zombieload to steal data being used inside a CPU.

Oh, boy.

The researchers have shown a Zombieload exploit that can look over your virtual shoulder to see the websites you’re visiting in real-time. Their example showed someone spying on another someone using the privacy-protecting Tor Browser running inside a virtual machine (VM).

Zombieload’s more formal name is “Microarchitectural Data Sampling (MDS).” It’s more common name comes from the concept of a “zombie load.” This is a quantity of data that a processor can’t handle on its own. The chip then asks for help from its microcode to prevent a crash. Normally, applications, virtual machines (VMs), and containers can only see their own data. But the Zombieload vulnerabilities enable an attacker to spy on data across the normal boundaries on all modern Intel processors.

Unlike the earlier Meltdown and Spectre problems, Intel was given time to ready itself for this problem. Intel has released microcode patches. These help clear the processor’s buffers, thus preventing data from being read.

To defend yourself, your processor must be updated, your operating system must be patched, and for the most protection, Hyper-Threading disabled. When Meltdown and Spectre showed up, the Linux developers were left in the dark and scrambled to patch Linux. This time, they’ve been kept in the loop.

Zombieload, the exploit, has three unique attack paths that could allow an attacker to execute a side-channel attack to bypass protections to read memory. The four Common Vulnerability and Exposures (CVEs) for this issue are:

  • CVE-2018-12126 is a flaw that could lead to information disclosure from the processor store buffer.
  • CVE-2018-12127 is an exploit of the microprocessor load operations that can provide data to an attacker about CPU registers and operations in the CPU pipeline.
  • CVE-2018-12130 is the most serious of the three issues, involved the implementation of the microprocessor fill buffers, and can expose data within that buffer.
  • CVE-2019-11091 is a flaw in the implementation of the “fill buffer,” a mechanism used by modern CPUs when a cache-miss is made on L1 CPU cache.

So, how bad is it?

Red Hat, which leads the way in dealing with Linux security issues, rated 12130 as a severity impact of “important,” while the others have moderate severity.

Greg Kroah-Hartman, the stable Linux kernel maintainer, bluntly wrote: 

I’m announcing the release of the 5.1.2 kernel.

All users of the 5.1 kernel series must upgrade. Well, kind of, let me rephrase that…

All users of Intel processors made since 2011 must upgrade.

Kroath-Hartmann concluded: “As I said before just over a year ago, Intel once again owes a bunch of people a lot of drinks for fixing their hardware bugs, in our software.”

Red Hat noted all its Linux distributions from Red Hat Enterprise Linux (RHEL) 5 on up to the new RHEL 8 are affected. Platforms based on these Linux distros, such as Red Hat Virtualization and Red Hat OpenStack, are also vulnerable.

This is not a Red Hat problem. All — and I mean all — Linux distributions are vulnerable to it. That’s because the problem is really with Intel’s underlying processors and not operating systems.

As Chris Robinson, Red Hat’s product security assurance manager, explained: 

“These vulnerabilities represent an access restriction bypass flaw that impacts many Intel CPU’s and many of the operating systems that enable that hardware. Working with other industry leaders, Red Hat has developed kernel security updates for products in our portfolio to address these vulnerabilities. We are working with our customers and partners to make these updates available, along with the information our customers need to quickly protect their physical systems, virtual images, and container-based deployments.”

This also means Linux-based containers and VMs are also open to attack. To protect yourself, you’ll need to patch the following Linux files: Kernel, kernel-rt, libvirt, qemu-kvm, qemu-kvm-rhev, and microcode_clt on all your systems. In particular, there’s a known attack vector for CE-2018-12130, which enables a malicious VM or container spy another containers or VMs. In other words, you must patch all your running containers and VMs on a server — or one bad apple can reveal the data in the patched ones.

While the patches are ready, they will degrade system performance. In particular, Red Hat recommended customers evaluate their risk profile to understand if attacks of this nature require them to take the additional step of disabling hyper-threading. That said, because of the threat posed by vulnerability chaining (the ability to exploit one vulnerability by exploiting another one first), Red Hat strongly suggested that users update all systems even if they do not believe their configuration poses a direct threat.

Canonical, the company behind Ubuntu Linux, takes it farther. Canonical recommended disabling hyper-yhreads if the system is used to execute untrusted or potentially malicious code. Some example workloads that warrant the need to disable hyper-threads are:

  • A multi-user system with a potentially malicious user. A malicious user could leverage MDS to extract secrets from other users on the system.
  • A system that runs programs which come from questionable sources. This could occur if a user on the system regularly makes use of new versions of programs that are published by an individual or group that they don’t not fully trust. A malicious software publisher could leverage MDS to extract secrets from the system.
  • A system that hosts virtual machines from varying security domains and/or that the system owner does not fully trust. A malicious program in one virtual machine could extract secrets from other virtual machines or from the virtualization host itself.

Reading between the lines, except for people running stand-alone Linux desktops, Canonical recommended you make the patches and disable hyper-threading.


Must read


Most business Linux distributions already have the patches ready to go. But they may not be available through the usual security patch channels. Canonical, for example, stated: “Due to the complexity of the changes involved in mitigating this hardware vulnerability, a live patch will not be available via the Canonical Livepatch Service.”

Red Hat’s VP of operating system platforms, Denise Dumas, said: “Because these security updates may affect system performance, Red Hat has included the ability to enable these fixes selectively in order to better manage the impact on performance-sensitive workloads.”

Once you have made the the kernel and Intel microcode patches, if you want to take the additional precaution of turning off hyper-threading, you can do so. You do this by setting the Linux kernel boot option:

mitigations=auto,nosmt

For more on working with the kernel, see The Linux kernel user’s and administrator’s guide.

The only real long-term fix

The Linux kernel Core Scheduling, a new scheduling program, may help mitigate Zombieload. But even Peter Zijlstra, the Linux kernel developer overseeing it, isn’t happy with it. He introduced it as saying he hated it with a passion, and no matter what you did with the program, “it is expensive and nasty.

The only real long-term fix — for Linux and all other operating systems — is when Intel introduces a new generation of processors. As it is, the current generation of Intel CPUs, with their older speculative execution process approach, improves data processing speeds and performance, but at the price of built-in security vulnerabilities.

Source Article from https://www.zdnet.com/article/linux-vs-zombieload/#ftag=RSSbaffb68
Linux vs. Zombieload
https://www.zdnet.com/article/linux-vs-zombieload/#ftag=RSSbaffb68
http://www.zdnet.com/blog/rss.xml
Latest blogs for ZDNet
Latest blogs for ZDNet
https://zdnet3.cbsistatic.com/fly/bundles/zdnetcore/images/logos/zdnet-144×144.png

Article written by

great guy, love the news