On the Spectre and Meltdown Processor Security Vulnerabilities (original) (raw)
Related papers
Mitigating Risk of Spectre and Meltdown Vulnerabilities
Speculative execution (Spectre) and Meltdown is a chip attempting to predict the future in order to improve the system performance which involves multiple logical branches, it will start working out the math for all those branches before the program even has to decide between them. Normally, it works together with caching which is to speed up the memory access by filled with the data that will need some and often the output of the speculative execution is stored here. The speculative execution and caching in the operating system improve the overall system and operating system performance through the prediction of data or resources to be used and cache memory is for quick access of data or resources. The problem arises where this function could allow potential attackers to get access to data they should not have access by exploiting the Spectre attacks and Meltdown. Spectre attacks and meltdown open up the possibilities for dangerous attacks which involved the breach of security and confidentiality of the user. Various techniques and patches have been introduced to mitigating the Spectre attack and meltdown. In this paper, we present the view various variants of attack from the speculative execution with its mitigation techniques.
Measuring the Impact of Spectre and Meltdown
2018 IEEE High Performance extreme Computing Conference (HPEC)
The Spectre and Meltdown flaws in modern microprocessors represent a new class of attacks that have been difficult to mitigate. The mitigations that have been proposed have known performance impacts. The reported magnitude of these impacts varies depending on the industry sector and expected workload characteristics. In this paper, we measure the performance impact on several workloads relevant to HPC systems. We show that the impact can be significant on both synthetic and realistic workloads. We also show that the performance penalties are difficult to avoid even in dedicated systems where security is a lesser concern.
Speculose: Analyzing the Security Implications of Speculative Execution in CPUs
Cornell University - arXiv, 2018
Whenever modern CPUs encounter a conditional branch for which the condition cannot be evaluated yet, they predict the likely branch target and speculatively execute code. Such pipelining is key to optimizing runtime performance and is incorporated in CPUs for more than 15 years. In this paper, to the best of our knowledge, we are the first to study the inner workings and the security implications of such speculative execution. We revisit the assumption that speculatively executed code leaves no traces in case it is not committed. We reveal several measurable side effects that allow adversaries to enumerate mapped memory pages and to read arbitrary memory-all using only speculated code that was never fully executed. To demonstrate the practicality of such attacks, we show how a user-space adversary can probe for kernel pages to reliably break kernel-level ASLR in Linux in under three seconds and reduce the Windows 10 KASLR entropy by 18 bits in less than a second. Disclaimer: This work on speculative execution was conducted independently from other research groups and was submitted to IEEE S&P '17 in October 2017. Any techniques and experiments presented in this paper predate the public disclosure of attacks that became known as Meltdown [25] and Spectre [22] and that were released begin-January 2018. This observation, however, leads us to discover a severe side channel that allows one to distinguish between mapped
Spectre Attacks: Exploiting Speculative Execution
Modern processors use branch prediction and speculative execution to maximize performance. For example, if the destination of a branch depends on a memory value that is in the process of being read, CPUs will try guess the destination and attempt to execute ahead. When the memory value finally arrives, the CPU either discards or commits the speculative computation. Speculative logic is unfaithful in how it executes, can access to the victim's memory and registers, and can perform operations with measurable side effects. Spectre attacks involve inducing a victim to speculatively perform operations that would not occur during correct program execution and which leak the victim's confidential information via a side channel to the adversary. This paper describes practical attacks that combine methodology from side channel attacks, fault attacks, and return-oriented programming that can read arbitrary memory from the victim's process. More broadly, the paper shows that speculative execution implementations violate the security assumptions underpinning numerous software security mechanisms, including operating system process separation, static analysis, containerization, just-in-time (JIT) compilation, and countermeasures to cache timing/side-channel attacks. These attacks represent a serious threat to actual systems, since vulnerable speculative execution capabilities are found in microprocessors from Intel, AMD, and ARM that are used in billions of devices. While makeshift processor-specific countermeasures are possible in some cases, sound solutions will require fixes to processor designs as well as updates to instruction set architectures (ISAs) to give hardware architects and software developers a common understanding as to what computation state CPU implementations are (and are not) permitted to leak. * After reporting the results here, we were informed that our work partly overlaps the results of independent work done at Google's Project Zero.
Reflections on post-Meltdown trusted computing: A case for open security processors
The recent wave of microarchitectural vulnerabilities in commodity hardware requires us to question our understanding of system security. We deplore that even for processor architec-tures and research prototypes with an explicit focus on security, open-source designs remain the exception. This article and call for action briefly surveys ongoing community efforts for developing a new generation of open security architectures, for which we collectively have a clear understanding of execution semantics and the resulting security implications. We advocate formal approaches to reason about the security guarantees that these architectures can provide, including the absence of microarchitectural bugs and side-channels. We consider such a principled approach essential in an age where society increasingly relies on interconnected and dependable control systems. Finally, we aim to inspire strong industrial and academic collaboration in such an engineering effort, which we believe is too monumental to be suitably addressed by a single enterprise or research community.
2022
Branch Target Injection (BTI or Spectre v2) is one of the most dangerous transient execution vulnerabilities, as it allows an attacker to abuse indirect branch mispredictions to leak sensitive information. Unfortunately, it also has proven difficult to mitigate, with vendors originally resorting to inefficient software mitigations like retpoline. Recently, efficient hardware mitigations such as Intel eIBRS and Arm CSV2 have been deployed as a replacement in production, isolating the branch target state across privilege domains. The assumption is that this is sufficient to deter practical BTI exploitation. In this paper, we challenge this belief and disclose fundamental design flaws in both Intel and Arm solutions. We introduce Branch History Injection (BHI or SpectreBHB), a new primitive to build cross-privilege BTI attacks on systems deploying isolation-based hardware defenses. BHI builds on the observation that, while the branch target state is now isolated across privilege domain...
Software-driven Security Attacks: From Vulnerability Sources to Durable Hardware Defenses
ACM Journal on Emerging Technologies in Computing Systems, 2021
There is an increasing body of work in the area of hardware defenses for software-driven security attacks. A significant challenge in developing these defenses is that the space of security vulnerabilities and exploits is large and not fully understood. This results in specific point defenses that aim to patch particular vulnerabilities. While these defenses are valuable, they are often blindsided by fresh attacks that exploit new vulnerabilities. This article aims to address this issue by suggesting ways to make future defenses more durable based on an organization of security vulnerabilities as they arise throughout the program life cycle. We classify these vulnerability sources through programming, compilation, and hardware realization, and we show how each source introduces unintended states and transitions into the implementation. Further, we show how security exploits gain control by moving the implementation to an unintended state using knowledge of these sources and how defe...
One Glitch to Rule Them All: Fault Injection Attacks Against AMD's Secure Encrypted Virtualization
Proceedings of the 2021 ACM SIGSAC Conference on Computer and Communications Security, 2021
AMD Secure Encrypted Virtualization (SEV) offers protection mechanisms for virtual machines in untrusted environments through memory and register encryption. To separate security-sensitive operations from software executing on the main x86 cores, SEV leverages the AMD Secure Processor (AMD-SP). This paper introduces a new approach to attack SEV-protected virtual machines (VMs) by targeting the AMD-SP. We present a voltage glitching attack that allows an attacker to execute custom payloads on the AMD-SPs of all microarchitectures that support SEV currently on the market (Zen 1, Zen 2, and Zen 3). The presented methods allow us to deploy a custom SEV firmware on the AMD-SP, which enables an adversary to decrypt a VM's memory. Furthermore, using our approach, we can extract endorsement keys of SEV-enabled CPUs, which allows us to fake attestation reports or to pose as a valid target for VM migration without requiring physical access to the target host. Moreover, we reverse-engineered the Versioned Chip Endorsement Key (VCEK) mechanism introduced with SEV Secure Nested Paging (SEV-SNP). The VCEK binds the endorsement keys to the firmware version of TCB components relevant for SEV. Building on the ability to extract the endorsement keys, we show how to derive valid VCEKs for arbitrary firmware versions. With our findings, we prove that SEV cannot adequately protect confidential data in cloud environments from insider attackers, such as rogue administrators, on currently available CPUs. CCS CONCEPTS • Security and privacy → Hardware attacks and countermeasures; Virtualization and security.
An Investigation of the Impact of Meltdown on Operating Systems
Advances in Engineering: an International Journal (ADEIJ)
Meltdown hole is a hardware vulnerability which affects Intel processors, IBM Power processors, and some other ARM based processors. Through this hole, a destructive process sets out to read memory even when the destructive process is not allowed to do so. Meltdown hole is run on a wide range of operating systems including IOS, Linux, MacOS, and Windows; in addition, it affects many service providers and cloud services. The security of operating systems should be provided using hardware and software factors in order to prevent the penetration of destructors. Operating system is entitled to manage and control hardware and run the applications. Software patches should be used in order to enhance the security of operating systems which should undergo updating operations. In operating systems, kernel completely controls the system and connects the applications to the processor, memory, and other hardware inside a system. Meltdown hole allows the attackers to access and read the contents of kernel memory. In this paper, the impact of meltdown hole on various processors and operating systems are investigated and the security solutions of hardware and software companies are compared so as to deal with the security issues of the processors.
A study of hardware architecture based attacks to bypass operating system security
Security and Privacy, 2019
Malware target a vulnerability, bug or loophole in software to exploit the system, escalate privileges, extract inaccessible data, or execute code for malicious purpose. We can assert that over the period of time, both hardware and software have evolved and so are their vulnerabilities. But most of the vulnerabilities identified or researched are software oriented. On similar lines, there can be vulnerabilities in the hardware architecture that can be exploited, hidden from upper layer securities like operating system (OS) reference monitor, antivirus, etc. It is difficult to trace the vulnerabilities in the hardware primarily due to complex architecture and difficulties to observe the effects of operations performed across the system. Just like the software, the hardware architecture can also be exploited to develop malware and to gain access to sensitive data. This paper discusses the attacks that exploit the operations performed at the hardware level. We have discussed the different exploits that use the hardware architecture to extract data, their limitations and the future of hardware architecture based exploits. At the end, the data extraction process is validated through our implementation of one of the hardware architecture based exploits. We question about the impact on system security if the hardware architecture is exploited. K E Y W O R D S architectural vulnerability, hardware attacks, micro-architectural attacks, side channel 1 INTRODUCTION All the operations on a computer, at the lowest level, are hardware dependent. Over the course of time computers have evolved from simple computing machines to very complex machines, thanks to the evolution of software and the hardware that drives it. As the hardware and software have evolved, so are the vulnerabilities associated with them. It is commonly observed that software vulnerabilities are detected frequently and patched, but same is not the case with hardware vulnerabilities. Vulnerabilities in hardware architecture are not much researched as extensively as software, apart from its developers, in the cyber security domain. This leads to many hardware-based attacks such as • Rowhammer, 1,2 an attack that exploits bit flipping in DRAM due to continuous access, which bypasses the memory isolation and breaks security boundaries. • Exploitation of the instruction cache. 3 • Side channel attacks that can extract data using a nontraditional way of communication. 4-6