Computer Architecture Today

Informing the broad computing community about current activities, advances and future directions in computer architecture.

Security remains a popular research area in our conferences – MICRO-53 featured two sessions and eight papers dedicated to security. To contribute new ideas in this area, it is important for computer architects to keep up with recent developments in both architecture and security conferences. Our earlier blog post highlighted contributions from security conferences from the first part of 2020 that can be of interest to computer architects. In this post, we overview contributions from security venues that appeared in the later part of 2020. We begin with CCS 2020, and then highlight selected papers from other conferences. 

CCS 2020

ACM Symposium on Computer and Communications Security (CCS) is one of the premier security conferences, its 2020 edition was a virtual event during the week of November 9th. This year, the number of papers related to hardware and system security was smaller than in some previous years. We start with papers discussing advanced exploitation techniques and defense mechanisms. 

Speculative probing demonstrated how speculative execution amplifies common software vulnerabilities for more effective code reuse attacks. Specifically, the authors showed how a single memory corruption vulnerability can be turned into primitives that leak information by observing side-effects of speculative execution. In the absence of such capability, attackers have to resort to blind probing and derandomizing address spaces by observing crash side-effects, which only works for crash-resistant programs.  Effectively, the proposed technique is a synergy of Spectre attacks and Code Reuse attacks. The second paper in this category explored methodologies for quantifying security of dynamic re-randomization against Just-in-time Return-Oriented Programming attacks. This work follows a long line of research in security conferences on JIT-ROP attacks. Another paper proposed a generic framework for discovering defense-aware code reuse attacks. The key insight is that code reuse attacks can be defined as a state reachability problem, and defenses prevent some transitions between states. It would be great to see advanced threat models represented by these papers addressed in our community.   Finally, Finding Cracks in Shields analyzed the security of Control Flow Integrity (CFI), a well-established technique to protect against code injection and code reuse attacks. The analysis covers many available CFI implementations and reveals issues that affect CFI mechanisms in practical implementations. 

Several CCS’20 papers focused on formal models and formal proofs of execution correctness. InSpectre presented a comprehensive formal microarchitectural model for out-of-order processors to establish the existence of vulnerabilities and assess effectiveness of defense mechanisms. The model incorporates features that are at the root of all known Spectre attacks. Another work described a zero-knowledge processor, which executes arbitrary programs written in a simple instruction set, and uses zero-knowledge proofs (which are fundamental in cryptography) to prove correctness of the execution.

TrustOre demonstrated how to leverage an external FPGA device to implement trusted storage in an isolated execution environment without creating side-channels. The paper showed how to extend trust from SGX to FPGA without architectural changes, how to provide a secure connection between SGX applications and FPGA, and how to support various operations by SGX applications on FPGA. 

Other Highlights: RAID, ACSAC, S&P’21 and USENIX Security’21

Several other security conferences were held (or will be held shortly) in the second part of 2020, particularly RAID and ACSAC. In addition, the first  batch of papers accepted to IEEE Symposium on Security and Privacy 2021 and USENIX Security Symposium 2021 are available. A few papers from these venues are of interest to our community. SpecROP (RAID 2020) presented a new speculative execution attack technique to chain multiple smaller gadgets together by poisoning control-flow instructions. This allows the attacker to perform the same computation as would be accomplished with larger monolithic gadgets, which are scarce. A key difference to traditional code reuse attacks is that control-flow transfers between gadgets use speculative targets. 

Transient execution attacks received further attention both on attacking and defensive sides. CrossTalk (S&P 2021) shows that recently introduced transient execution attacks can leak data across CPU cores, therefore isolating victims and attackers on different cores is not a sufficient defense. A specific attack demonstrated in this paper uses cpuid instruction to sample (across cores) the entire staging buffer containing sensitive data, including output from the hardware random number generator. This, in turn, allows to attack SGX enclaves running on a different core. On the defensive side, DOLMA (USENIX Security’21) presented a new defense against transient execution attacks, exploiting the new principle of transient non-observability. The idea is to ensure that a time slice on a core provides a unit of isolation and protection from existing attacks. This allows speculative TLB and L1 cache accesses and variable-time arithmetic operations to proceed without impact on security.

Cache-based side-channel attacks have been a subject of active recent research, these attacks are at the core of more advanced exploitations, such as transient execution attacks. Randomization-based cache designs have been proposed as a way to protect caches from these attacks. Another paper from S&P’21 presents a generic model for randomization-based secure cache designs and studies the effectiveness of recently proposed randomization schemes (CEASER, CEASER-S, ScatterCache).  One of the conclusions of this study is that the security of CEASER-S can be subverted even if frequent re-keying is performed. 

Three papers presented new attacks against Intel SGX systems. VoltPillager (USENIX Security’21) demonstrated a new fault injection attack against SGX enclaves. Specifically, authors developed a low-cost tool for injecting messages on the Serial Voltage Identification bus between the CPU and the voltage regulator on the motherboard. This capability affords precise control of the CPU core voltage and can be used to mount fault-injection attacks that breach confidentiality and integrity of enclaves. As another example, Platypus attack on Intel SGX has been announced and widely publicized this week. This attack exploits unprivileged access to the Intel Running Average Power Limit (RAPL) interface that can expose values directly correlated with power consumption. This forms a low-resolution power side channel. Faulty Point Unit (ACSAC 2020) demonstrated a new attack vector against SGX enclaves, where the adversary can impact floating point computations performed inside an enclave through Application Binary Interface. The attack surface arises  from enclave interactions with x87 FPU and SSE vector extensions. The root cause of the attack is insufficient FPU and SSE control register initialization at the enclave boundary, allowing the attacker to impact the integrity and confidentiality of floating-point operations. These three contributions add to the long line of previously reported vulnerabilities in SGX-based systems. 

In summary, attacks, threat models, formalisms and defenses continue to evolve. Computer architects should be aware of these recent developments; it would be great to see a wider range of attacks and threat models covered by future papers in our conferences.

About the author: Dmitry Ponomarev is a Professor of Computer Science at Binghamton University. His research interests are in computer architecture, with a recent emphasis on security. 

Disclaimer: These posts are written by individual contributors to share their thoughts on the Computer Architecture Today blog for the benefit of the community. Any views or opinions represented in this blog are personal, belong solely to the blog author and do not represent those of ACM SIGARCH or its parent organization, ACM.