Skip to main content

Spectre & Meltdown Variants - A rapidly evolving threat

I had the opportunity to read an article from zdnet.com entitled "Intel's Cascade Lake CPUs impacted by new Zombieload v2 attack". Based on this article, I feel as though Intel is trying to solve a hardware problem with a software solution. It is tantamount to substituting duct tape for an automobile part in a faulty vehicle. As absurd as that scenario may sound, in my humble opinion, it is exactly what Intel is doing to solve this problem. As we discussed in class, Spectre and Meltdown are critical vulnerabilities that came to light in January 2018. These new vulnerabilities were very different than the common “0 day” software exploits as they take advantage of the intrinsic functionality of the micro-architecture: speculative execution. Interestingly enough, in the seminal paper titled “Spectre Attacks: Exploiting Speculative Execution” by Kocher .et al, readers learned that these architectural vulnerabilities are not limited to these two exploits. In fact, the authors describe an entirely new class of vulnerabilities called Micro-Architectural Data Sampling vulnerabilities of which this new exploit, ZombieLoad version 2, is a current incarnation.

It’s predecessor, ZombieLoad version 1, caused a great deal of concern for any user running an Intel CPU created since 2011. In the seminal paper, “ZombieLoad: Cross-Privilege-Boundary Data Sampling” by Schwarz et. al. the authors claim that ZombieLoad is more akin to Meltdown than Spectre. Given that the Meltdown vulnerability has been enhanced to “not only leak data from the L1 cache but also from various other micro-architectural structures, including the FPU register file and store buffer”, any exploits that take advantage of these structures are often referred to as Meltdown like (or Meltdown type-effects). The original Meltdown-type effect found in ZombieLoad takes advantage of the processor’s fill-buffer logic. By creating faulting load instructions or loads that require reissuing may allow for transiently dereferenced unauthorized destinations that were previously filled into the buffer by either a current or logical sibling CPU to be reloaded, giving access to the attackers. The authors found this mechanism to occur even on Meltdown and MDS-resistant processors. They also stated that “despite Intel’s claims, we show that the hardware fixes in new CPUs are not sufficient” mitigations to stem this class of exploits. Therefore, it is not surprising that less than 3-weeks ago, we have another incarnation of ZombieLoad which is spreading across patched Intel processors.

This new version of ZombieLoad was also confirmed to work on the new Cascade Lake CPU revisions that have been created after being supposedly patched against Spectre and Meltdown. However, the article has stated that Intel has downplayed this issue yet promises a microcode fix in the future. Intel’s argument hinges on the fact that given the complexity of successfully executing a ZombieLoad attack, ZombieLoad v2 will be increasing more difficult to execute successfully. However, the authors of this article pointed out that the main issue is that ZombieLoad v2 works on CPUs with meltdown patch mitigations. This suggests that ZombieLoad v2 may actually be taking advantage of the microcode fixes that are supposed to mitigate the problem. The authors along with several supporting references feel that the issue is an architectural problem and until Intel fixes the problem (on a hardware level) that these issues will persist. When the authors spoke to some chip developers, they suggested that Intel could benefit from developing a secure core on the die which may assist with isolation and protecting data against speculative attacks. AMD currently is taking advantage of a secure core-like implementation in its new processors.

One of the interesting points in the article was when the author’s made reference to the fact that “AMD is leaps and bounds of Intel” in the market place. After the research that I conducted for our presentation on Spectre and Meltdown, I find this to be true. It is common knowledge that Intel is having challenges perfecting its 7nm chip designs and is even outsourcing some of their chip fabrication to other vendors but what is often overlooked is the fact that AMD chips not only have higher core/thread counts than Intel but also are to date, immune from Spectre attacks. Part of the reason has to do with the way that AMD approaches security. They have designed their chips with security from the ground up. Instead of integrating security into each core, they have a separate processor that exclusively takes care of communication and security. With this new technology, they are able to develop solutions such as Secure Encrypted Memory (SEM) and Secure Encrypted Virtualization (SEV). These two features protect the memory and most communication channels (between CPU and other devices) from inspection by other processes, system administrators, and even the hypervisor itself. I feel that these advancements will cause business industries with critical security concerns to take another look at AMD products and perhaps even pressure Intel to redesign their chips; not necessarily through a discussion but with their substantial checkbooks. The challenges currently faced by Intel really put the lecture material in perspective. For years, we have seen how Intel has made leaps and bound in processor efficiency and performance by making decisions that bend the rules on isolation and security such as (unsafe) speculative execution. Prior to this event, AMD was far behind Intel in the market and there were few (Fortune 100) industries where you could find server farms with AMD processors. Interestingly enough. AMD with a smaller budget workforce and market share decided to integrate security into the hardware design from the beginning and today are reaping the benefits of their decisions even in the midst of the catastrophic security flaws that businesses are scrambling to patch.

Comments

Popular posts from this blog

Angr: A Multi-Architecture Binary Analysis Toolkit

This blog is quoted from several angr blogs and documentations, click  here  and  here . angr is a multi-architecture binary analysis toolkit, with the capability to perform dynamic symbolic execution (like Mayhem, KLEE, etc.) and various static analyses on binaries. We've tried to make using angr as pain-free as possible - our goal is to create a user-friendly binary analysis suite, allowing a user to simply start up iPython and easily perform intensive binary analyses with a couple of commands. That being said, binary analysis is complex, which makes angr complex. This documentation is an attempt to help out with that, providing narrative explanation and exploration of angr and its design. Several challenges must be overcome to programmatically analyze a binary. They are, roughly: Loading a binary into the analysis program. Translating a binary into an intermediate representation (IR). Performing the actual analysis. This could be: A partial or full-prog...

SWAPGS Attack: A Spectre Variant

With the recent developments of Spectre [1] and Meltdown [1] as we discussed in class, it should come to no surprise that various odd methods of accessing kernel memory through user level permissions have popped up.   One such interesting method utilizes the SWAPGS instruction, called the SWAPGS Attack, found by Bitdefender researchers just a few months ago [2].   This article will explore what the attack is, how to exploit it on existing hardware and operating systems, and what mitigations can be implemented for current hardware. SWAPGS Attack Overview The SWAPGS Attack, as the name implies, utilizes the SWAPGS instruction.   This instruction swaps two Model Specific Registers (MSRs), IA32_GS_BASE and IA32_GS_KERNEL_BASE, which point to the user mode's per-thread data structure and kernel mode per-thread data structure respectively.   In Windows, the addresses stored in these registers are used to quickly access information about the current Thread Informa...

ARM TrustZone, its Applications, and the MCU Xpresso55S69

ARM TrustZone, its Applications, and the MCU Xpresso55S69 Overview: The creation of ARM TrustZone stems from a simple question: how can high-value code and data be protected (primarily in IoT devices and systems) without significantly slowing development?  The core idea put forth by the developers of ARM TrustZone is that the objective above can be accomplished by isolating critical firmware and private information. TrustZone’s isolation is hardware-enforced, with a “Secure” and a “Non-Secure”/”Normal” world (shown as “Trusted view” and “None-trusted view” in Figure 1 below). Present on ARM’s Cortex-M and Cortex-A processors, TrustZone is a “SoC (System-on-Chip) and CPU system-wide security solution”, per Pinto and Santos [4]. By restricting access to “secure” (“trusted”) memory and I/O, ARM TrustZone reduces the attack surface of critical components.    Figure 1: An Overview of TrustZone Being implemented at the hardware level gives TrustZone s...