116 research outputs found
Cross-core Microarchitectural Attacks and Countermeasures
In the last decade, multi-threaded systems and resource sharing have brought a number of technologies that facilitate our daily tasks in a way we never imagined. Among others, cloud computing has emerged to offer us powerful computational resources without having to physically acquire and install them, while smartphones have almost acquired the same importance desktop computers had a decade ago. This has only been possible thanks to the ever evolving performance optimization improvements made to modern microarchitectures that efficiently manage concurrent usage of hardware resources. One of the aforementioned optimizations is the usage of shared Last Level Caches (LLCs) to balance different CPU core loads and to maintain coherency between shared memory blocks utilized by different cores. The latter for instance has enabled concurrent execution of several processes in low RAM devices such as smartphones. Although efficient hardware resource sharing has become the de-facto model for several modern technologies, it also poses a major concern with respect to security. Some of the concurrently executed co-resident processes might in fact be malicious and try to take advantage of hardware proximity. New technologies usually claim to be secure by implementing sandboxing techniques and executing processes in isolated software environments, called Virtual Machines (VMs). However, the design of these isolated environments aims at preventing pure software- based attacks and usually does not consider hardware leakages. In fact, the malicious utilization of hardware resources as covert channels might have severe consequences to the privacy of the customers. Our work demonstrates that malicious customers of such technologies can utilize the LLC as the covert channel to obtain sensitive information from a co-resident victim. We show that the LLC is an attractive resource to be targeted by attackers, as it offers high resolution and, unlike previous microarchitectural attacks, does not require core-colocation. Particularly concerning are the cases in which cryptography is compromised, as it is the main component of every security solution. In this sense, the presented work does not only introduce three attack variants that can be applicable in different scenarios, but also demonstrates the ability to recover cryptographic keys (e.g. AES and RSA) and TLS session messages across VMs, bypassing sandboxing techniques. Finally, two countermeasures to prevent microarchitectural attacks in general and LLC attacks in particular from retrieving fine- grain information are presented. Unlike previously proposed countermeasures, ours do not add permanent overheads in the system but can be utilized as preemptive defenses. The first identifies leakages in cryptographic software that can potentially lead to key extraction, and thus, can be utilized by cryptographic code designers to ensure the sanity of their libraries before deployment. The second detects microarchitectural attacks embedded into innocent-looking binaries, preventing them from being posted in official application repositories that usually have the full trust of the customer
CacheZoom: How SGX Amplifies The Power of Cache Attacks
In modern computing environments, hardware resources are commonly shared, and
parallel computation is widely used. Parallel tasks can cause privacy and
security problems if proper isolation is not enforced. Intel proposed SGX to
create a trusted execution environment within the processor. SGX relies on the
hardware, and claims runtime protection even if the OS and other software
components are malicious. However, SGX disregards side-channel attacks. We
introduce a powerful cache side-channel attack that provides system adversaries
a high resolution channel. Our attack tool named CacheZoom is able to virtually
track all memory accesses of SGX enclaves with high spatial and temporal
precision. As proof of concept, we demonstrate AES key recovery attacks on
commonly used implementations including those that were believed to be
resistant in previous scenarios. Our results show that SGX cannot protect
critical data sensitive computations, and efficient AES key recovery is
possible in a practical environment. In contrast to previous works which
require hundreds of measurements, this is the first cache side-channel attack
on a real system that can recover AES keys with a minimal number of
measurements. We can successfully recover AES keys from T-Table based
implementations with as few as ten measurements.Comment: Accepted at Conference on Cryptographic Hardware and Embedded Systems
(CHES '17
ret2spec: Speculative Execution Using Return Stack Buffers
Speculative execution is an optimization technique that has been part of CPUs
for over a decade. It predicts the outcome and target of branch instructions to
avoid stalling the execution pipeline. However, until recently, the security
implications of speculative code execution have not been studied.
In this paper, we investigate a special type of branch predictor that is
responsible for predicting return addresses. To the best of our knowledge, we
are the first to study return address predictors and their consequences for the
security of modern software. In our work, we show how return stack buffers
(RSBs), the core unit of return address predictors, can be used to trigger
misspeculations. Based on this knowledge, we propose two new attack variants
using RSBs that give attackers similar capabilities as the documented Spectre
attacks. We show how local attackers can gain arbitrary speculative code
execution across processes, e.g., to leak passwords another user enters on a
shared system. Our evaluation showed that the recent Spectre countermeasures
deployed in operating systems can also cover such RSB-based cross-process
attacks. Yet we then demonstrate that attackers can trigger misspeculation in
JIT environments in order to leak arbitrary memory content of browser
processes. Reading outside the sandboxed memory region with JIT-compiled code
is still possible with 80\% accuracy on average.Comment: Updating to the cam-ready version and adding reference to the
original pape
Reviving Meltdown 3a
Since the initial discovery of Meltdown and Spectre in 2017, different
variants of these attacks have been discovered. One often overlooked variant is
Meltdown 3a, also known as Meltdown-CPL-REG. Even though Meltdown-CPL-REG was
initially discovered in 2018, the available information regarding the
vulnerability is still sparse. In this paper, we analyze Meltdown-CPL-REG on 19
different CPUs from different vendors using an automated tool. We observe that
the impact is more diverse than documented and differs from CPU to CPU.
Surprisingly, while the newest Intel CPUs do not seem affected by
Meltdown-CPL-REG, the newest available AMD CPUs (Zen3+) are still affected by
the vulnerability. Furthermore, given our attack primitive CounterLeak, we show
that besides up-to-date patches, Meltdown-CPL-REG can still be exploited as we
reenable performance-counter-based attacks on cryptographic algorithms, break
KASLR, and mount Spectre attacks. Although Meltdown-CPL-REG is not as powerful
as other transient-execution attacks, its attack surface should not be
underestimated.Comment: published at ESORICS 202
From Dragondoom to Dragonstar: Side-channel Attacks and Formally Verified Implementation of WPA3 Dragonfly Handshake
It is universally acknowledged that Wi-Fi communications are important to
secure. Thus, the Wi-Fi Alliance published WPA3 in 2018 with a distinctive
security feature: it leverages a Password-Authenticated Key Exchange (PAKE)
protocol to protect users' passwords from offline dictionary attacks.
Unfortunately, soon after its release, several attacks were reported against
its implementations, in response to which the protocol was updated in a
best-effort manner.
In this paper, we show that the proposed mitigations are not enough,
especially for a complex protocol to implement even for savvy developers.
Indeed, we present **Dragondoom**, a collection of side-channel vulnerabilities
of varying strength allowing attackers to recover users' passwords in widely
deployed Wi-Fi daemons, such as hostap in its default settings. Our findings
target both password conversion methods, namely the default probabilistic
hunting-and-pecking and its newly standardized deterministic alternative based
on SSWU. We successfully exploit our leakage in practice through
microarchitectural mechanisms, and overcome the limited spatial resolution of
Flush+Reload. Our attacks outperform previous works in terms of required
measurements.
Then, driven by the need to end the spiral of patch-and-hack in Dragonfly
implementations, we propose **Dragonstar**, an implementation of Dragonfly
leveraging a formally verified implementation of the underlying mathematical
operations, thereby removing all the related leakage vector. Our implementation
relies on HACL*, a formally verified crypto library guaranteeing
secret-independence. We design Dragonstar, so that its integration within
hostap requires minimal modifications to the existing project. Our experiments
show that the performance of HACL*-based hostap is comparable to OpenSSL-based,
implying that Dragonstar is both efficient and proved to be leakage-free.Comment: Accepted at 2023 IEEE 8th European Symposium on Security and Privacy
(EuroS&P
- âŠ