Microarchitectural Data Sampling (aka MDS, ZombieLoad, RIDL & Fallout) explained by Red Hat

In the wake of Meltdown, Spectre, and Foreshadow security researchers have been focused on squashing vulnerabilities in other parts of processors. Recently a new security issue has been found known as Microarchitectural Data Sampling or MDS. This targets a flaw in Intel microprocessors that can allow attackers to read or "sample" data used by other programs, containers, and virtual machines to potentially steal sensitive information. This is especially dangerous on shared-tenancy machines such as public clouds.

Think of a server as an apartment building. Mail arrives addressed to Bob in apartment 301, but Bob moved out last week.

Susan, who lives there now, sees that the letter isn't for her. Before she sends the letter back she can sneak a peek by shining a light through the envelope. She may only be able to see a few letters or numbers, a sample of what's inside, but as more letters arrive she can piece enough together to have Bob's bank information. In an actual server, MDS allows an attacker to sample data from previous operations.

Then they could use other sophisticated techniques to stitch it all together to steal valuable information. MDS is possible because of how Intel processors are optimized using buffers during speculative operations. There are a few different ways attackers can use MDS each targeting different processor structures. The store buffer variant exploits how Intel processors speculatively forward data from a store buffer entry.

Intel splits data stores into two separate operations: "Store this address" and "store this value". To improve performance, the data in the store buffer entry isn't removed. A load searches the store buffer to see if it needs to forward a recent store to the same location. If the load requires special assistance, the processor may speculatively use stale data without checking if it's valid. So it may be possible to sample the data. Similar to the way Susan peeked into Bob's letter. The fill buffer and load port variants work essentially the same way.

When Hyper-Threading is used, fill buffers and load ports are shared between Hyper-Threads. So it's not possible to fully restrict access. If an attacker runs code on a peer Hyper-Thread while the other is using sensitive data, it's possible to sample that speculative data. As bad as MDS is, the fix is also painful. For the store buffer variant, microcode updates are available to mitigate the risk. For the fill buffer and load port variants, systems aren't completely safe without disabling Intel Hyper-Threading. This will impact performance significantly. This fix is especially critical to protect users in shared-tenancy environments running untrusted workloads, like how many public clouds are configured. Red Hat Enterprise Linux users will be given an option to disable Intel Hyper-Threading during new installations or via command-line options. But it's up to each company to make the decision whether to turn it off or not. To decide what you should do, visit your vendor's website for more information. As new vulnerabilities are discovered, researchers and vendors will continue to come together to squash them. .

Comments (0)

No comments yet

Leave a Comment