Given their vital importance for governments and enterprises around the world, we need to trust public clouds to provide strong security guarantees even in the face of advanced attacks and hardware vulnerabilities. While transient execution vulnerabilities, such as Spectre, have been in the spotlight since 2018, until now there have been no reports of realistic attacks on real-world clouds, leading to an assumption that such attacks are not practical in noisy real-world settings and without knowledge about the (host or guest) victim. In particular, given that today's clouds have large fleets of older CPUs that lack comprehensive, in-silicon fixes to a variety of transient execution vulnerabilities, the question arises whether sufficient software-based defenses have been deployed to stop realistic attacks---especially those using older, supposedly mitigated vulnerabilities. In this paper, we answer this question in the negative. We show that the practice of mitigating vulnerabilities in isolation, without removing the root cause, leaves systems vulnerable. By combining such mitigated'' (and by themselves harmless) vulnerabilities, attackers may still craft an end-to-end attack that is more than the sum of its parts. In particular, we show that attackers can use L1TF, one of the oldest known transient execution vulnerabilities (discovered in January 2018), in combination with a simple speculative out-of-bounds load, to leak data from other guests in a commercial cloud computing platform. Moreover, with an average end-to-end duration of 15 hours to leak the TLS key of an Nginx server in a victim VM under noisy conditions, without detailed knowledge of either host or guest, the attack is realistic even in one of today's biggest and most important commercial clouds.

Current approaches for emulating cellular base-bands inherently fall short in comparison to over-the-air testing due to their limited support for the complex peripherals involved in a modern baseband, such as DSPs, SIM cards and RF frontends. Improving such support is a daunting task, requiring deep reverse-engineering which is extremely time consuming - resulting in slow progress. Consequently, techniques such as fuzzing are only able to find relatively shallow bugs, since they are unable to reach the states required for the majority of the baseband to function. To fill this gap, we propose Basebridge, which enables far more comprehensive simulation of baseband behavior by restoring relevant state from memory dumps of real devices. Our prototype implementation supports baseband firmware from two major vendors (MediaTek and Samsung), and - in contrast to current state-of-the-art emulators - correctly responds to 97% of tested RRC and NAS messages while improving coverage by an average factor of 2.41 (Samsung) and 5.54 (MediaTek). Basebridge also passes several LTE conformance tests. Our empirical evaluation demonstrates that this enhanced fidelity enables faster discovery of a wider range of bugs thanks to the scalability of emulation; our fuzzing campaign shows that coverage improves by a factor of 2.3-5x overall, and by a factor of 9.0-22.5x for functionality targeted by our approach. Basebridge unveiled 5 new vulnerabilities, which we have disclosed to affected vendors.

Fuzzing has proven to be a highly effective approach to uncover software bugs over the past decade. After AFL popularized the groundbreaking concept of lightweight coverage feedback, the field of fuzzing has seen a vast amount of scientific work proposing new techniques, improving methodological aspects of existing strategies, or porting existing methods to new domains. All such work must demonstrate its merit by showing its applicability to a problem, measuring its performance, and often showing its superiority over existing works in a thorough, empirical evaluation. Yet, fuzzing is highly sensitive to its target, environment, and circumstances, e. g., randomness in the testing process. After all, relying on randomness is one of the core principles of fuzzing, governing many aspects of a fuzzer’s behavior. Combined with the often highly difficult to control environment, the reproducibility of experiments is a crucial concern and requires a prudent evaluation setup. To address these threats to validity, several works, most notably Evaluating Fuzz Testing by Klees et al., have outlined how a carefully designed evaluation setup should be implemented, but it remains unknown to what extent their recommendations have been adopted in practice.In this work, we systematically analyze the evaluation of 150 fuzzing papers published at the top venues between 2018 and 2023. We study how existing guidelines are implemented and observe potential shortcomings and pitfalls. We find a surprising disregard of the existing guidelines regarding statistical tests and systematic errors in fuzzing evaluations. For example, when investigating reported bugs, we find that the search for vulnerabilities in real-world software leads to authors requesting and receiving CVEs of questionable quality. Extending our literature analysis to the practical domain, we attempt to reproduce claims of eight fuzzing papers. These case studies allow us to assess the practical reproducibility of fuzzing research and identify archetypal pitfalls in the evaluation design. Unfortunately, our reproduced results reveal several deficiencies in the studied papers, and we are unable to fully support and reproduce the respective claims. To help the field of fuzzing move toward a scientifically reproducible evaluation strategy, we propose updated guidelines for conducting a fuzzing evaluation that future work should follow.

Since the Spectre and Meltdown disclosure in 2018, the list of new transient execution vulnerabilities that abuse the shared nature of microarchitectural resources on CPU cores has been growing rapidly. In response, vendors keep deploying “spot” (per-variant) mitigations, which have become increasingly costly when combined against all the attacks—especially on older-generation processors. Indeed, some are so expensive that system administrators may not deploy them at all. Worse still, spot mitigations can only address known (N-day) attacks as they do not tackle the underlying problem: different security domains that run simultaneously on the same physical CPU cores and share their microarchitectural resources.

Closely monitoring the behavior of a software system during its execution enables developers and analysts to observe, and ultimately understand, how it works. This kind of dynamic analysis can be instrumental to reverse engineering, vulnerability discovery, exploit development, and debugging. While these analyses are typically well-supported for homogeneous desktop platforms (e.g., x86 desktop PCs), they can rarely be applied in the heterogeneous world of embedded systems. One approach to enable dynamic analyses of embedded systems is to move software stacks from physical systems into virtual environments that sufficiently model hardware behavior. This process which we call "rehosting" poses a significant research challenge with major implications for security analyses. Although rehosting has traditionally been an unscientific and ad-hoc endeavor undertaken by domain experts with varying time and resources at their disposal, researchers are beginning to address rehosting challenges systematically and in earnest. In this paper, we establish that emulation is insufficient to conduct large-scale dynamic analysis of real-world hardware systems and present rehosting as a firmware-centric alternative. Furthermore, we taxonomize preliminary rehosting efforts, identify the fundamental components of the rehosting process, and propose directions for future research.

This paper presents a new side channel that affects mixed-signal chips used in widespread wireless communication protocols, such as Bluetooth and WiFi. This increasingly common type of chip includes the radio transceiver along with digital logic on the same integrated circuit. In such systems, the radio transmitter may unintentionally broadcast sensitive information from hardware cryptographic components or software executing on the CPU. The well-known electromagnetic (EM) leakage from digital logic is inadvertently mixed with the radio carrier, which is amplified and then transmitted by the antenna. We call the resulting leak screaming channels. Attacks exploiting such a side channel may succeed over a much longer distance than attacks exploiting usual EM side channels. The root of the problem is that mixed-signal chips include both digital circuits and analog circuits on the same silicon die in close physical proximity. While processing data, the digital circuits on these chips generate noise, which can be picked up by noise-sensitive analog radio components, ultimately leading to leakage of sensitive information. We investigate the physical reasons behind the channel, we measure it on several popular devices from different vendors (including Nordic Semiconductor nRF52832, and Qualcomm Atheros AR9271), and we demonstrate a complete key recovery attack against the nRF52832 chip. In particular, we retrieve the full key from the AES-128 implementation in tinyAES at a distance of 10 m using template attacks. Additionally, we recover the key used by the AES-128 implementation in mbedTLS at a distance of 1 m with a correlation attack. Screaming channel attacks change the threat models of devices with mixed-signal chips, as those devices are now vulnerable from a distance. More specifically, we argue that protections against side channels (such as masking or hiding) need to be used on this class of devices. Finally, chips implementing other widespread protocols (e.g., 4G/LTE, RFID) need to be inspected to determine whether they are vulnerable to screaming channel attacks.