Intel has released a patch for the Zombieload / MDS (microarchitectural data sampling) security flaws that it first announced last year. This is the third set of patches related to those flaws, though only one of the two fixes even rates “Medium” severity.
The first flaw, CVE-2020-0548, is called Vector Register Sampling by Intel. VRS is a low-risk attack because it only applies to a subset of machines that can be targeted by other flaws, and it doesn’t expose nearly as much information from the vector registers, even in theory. The attack is also considered to be harder to execute than some of the other Meltdown/Spectre/MDS attacks we’ve discussed in the past.
The “Medium” severity flaw is CVE-2020-0549, also known as L1D Eviction Sampling. Here’s how Intel describes the flaw:
On some processors under certain microarchitectural conditions, data from the most recently evicted modified L1 data cache (L1D) line may be propagated into an unused (invalid) L1D fill buffer. On processors affected by Microarchitectural Data Samping (MDS) or Transactional synchronous Abort (TAA), data from an L1D fill buffer may be inferred using one of these data sampling side channel methods. By combining these two behaviors together, it may be possible for a malicious actor to infer data values from modified cache lines that were previously evicted from the L1 data cache. This is called L1D eviction sampling.
The following Intel CPUs are impacted by L1D Eviction Sampling:
There don’t appear to be any performance implications from these fixes at the moment, though Intel is still working on microcode updates to extend protection to the CPUs that need them. Software that already deploys fixes against L1TF (L1 Terminal Fault) should also be protected against L1DES.
Breaking these attacks down into simple descriptions of their individual characteristics, however, doesn’t really give you an effective view of how dangerous they are collectively.
There Are Currently No Public Attacks That Use These Vectors
It’s now been over two years since Intel announced Spectre and Meltdown to the world. I want to make it clear up-front that I’m not excusing the presence of security flaws in Intel CPUs. The company needs to fix the design decisions that exposed its products to these issues. It needs to put procedures in place to ensure that future chips are less impacted by these flaws.
At the same time, however, end-users need some kind of guidance on which threats are more likely to represent serious, real-world risks. It doesn’t normally take badware authors more than two years to take advantage of a flaw when the procedures for doing so are publicly available (as these Intel flaws are).
The entire situation around Spectre/Meltdown/MDS is reminiscent of the Pentium FDIV bug. When Intel discovered that the bug would impact almost no one, it announced it didn’t intend to do anything about it, unless you could prove your system had been impacted. Practically speaking, FDIV was incredibly unlikely to impact the operation of a Pentium CPU for any ordinary desktop user. Intel’s decision made sense, from an engineering perspective, but the public outcry was enormous. Under pressure, Intel changed its tune.
But just because Intel changed course to avoid a PR disaster doesn’t mean the company’s underlying engineering assessment was factually wrong. The overwhelming majority of Pentium owners were never impacted by the FDIV bug in any fashion. That didn’t make it ok to leave the bug in place — the entire reason people were angry is that they were upset at paying for defective goods, even if the defect was largely meaningless — but it did mean that the actual risk to any normal customer of running into a problem was very small.
So far, Spectre, Meltdown, and all of the related attacks seem to be in a similar position. Intel has done the right thing by continuing to close these attack vectors, but it’s not as if the company is doing so while customers suffer from an avalanche of attacks related to them. While it’s absolutely possible that an attack will surface at some point that makes use of them, none is in-use today.
The final point I’d make is that it’s not surprising that these issues continue to surface. Spectre wasn’t really one single attack. Spectre effectively described a method of using side channels of information to exfiltrate data from a CPU. Many of the attacks published since have applied conceptually similar methods to other parts of the CPU. Again, that could be worrisome if we were seeing any attempt to leverage these attacks in the wild, but the bottom line is that there are easier ways to steal data / hack systems than going this route.
Feature image from George Romero’s Night of the Living Dead, courtesy of Wikipedia
Now Read:
- New Spectre-Related CPU Flaw Tops Intel’s Latest Critical Security Fixes
- Intel Discloses New Speculative Execution Security Vulnerabilities
- Modern CPUs Likely Permanently Haunted by Spectre Security Flaws
No comments:
Post a Comment