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-program static

Information Side Channel

By Elaine Cole and Jarek Millburg An information side channel can be used to gain information about the system or data that it processes. A side-channel attack identifies a physical or micro-architectural signal that leaks such desired information and monitors and analyzes that signal as the system operates. While there are many different types of information side channels and even more ways to maliciously exploit them, this blog explores a recent publication that leverages information side channels within IoT devices to aid crime scene investigators in real-time. In this blog, we provide an overview of the general attack procedure, and explore two of the many forms of side channel attacks. Side Channel Attack General Procedure While there are many different forms of side channels, at a high level, a side channel attack requires the following: 1. identify a side channel:  The attacker must first identify  a physical or micro-architectural signal that leaks desired

Introduction to SGX and potential attack method

The Overview of SGX What is the SGX? With more and more attack on systems and bigger danger inside the internet. We get a new technology which named The Security Guard Extensions (The SGX). Actually the SGX aimed to separate the whole applications to two parts: secure part and unsecure part. The secure part named enclave. Which is stored in protected memory. Between the enclave and application, there is an interface is implemented. Which is consists of e-calls and o-calls. The e-calls are inside the enclave for calling to the unsecured code. The o-calls are located in the unsecured code for collecting data inside the enclave. The enclave is totally protected which means any access from external are not allowed. Only when the untrusted part of application call the trusted function then the code inside the enclave can see the data. When it returns, the enclave data are still stays in safe memory. figure.1 Actually while the application’s host in pr