InversOS: Efficient Control-Flow Protection for AArch64 Applications with Privilege Inversion

With the increasing popularity of AArch64 processors in general-purpose computing, securing software running on AArch64 systems against control-flow hijacking attacks has become a critical part toward secure computation. Shadow stacks keep shadow copies of function return addresses and, when protected from illegal modifications and coupled with forward-edge control-flow integrity, form an effective and proven defense against such attacks. However, AArch64 lacks native support for write-protected shadow stacks, while software alternatives either incur prohibitive performance overhead or provide weak security guarantees. We present InversOS, the first hardware-assisted write-protected shadow stacks for AArch64 user-space applications, utilizing commonly available features of AArch64 to achieve efficient intra-address space isolation (called Privilege Inversion) required to protect shadow stacks. Privilege Inversion adopts unconventional design choices that run protected applications in the kernel mode and mark operating system (OS) kernel memory as user-accessible; InversOS therefore uses a novel combination of OS kernel modifications, compiler transformations, and another AArch64 feature to ensure the safety of doing so and to support legacy applications. We show that InversOS is secure by design, effective against various control-flow hijacking attacks, and performant on selected benchmarks and applications (incurring overhead of 7.0% on LMBench, 7.1% on SPEC CPU 2017, and 3.0% on Nginx web server).Comment: 18 pages, 9 figures, 4 table

Signature-Based Protection from Code Reuse Attacks

Abstract—Code Reuse Attacks (CRAs) recently emerged as a new class of security exploits. CRAs construct malicious programs out of small fragments (gadgets) of existing code, thus eliminating the need for code injection. Existing defenses against CRAs often incur large performance overheads or require extensive binary rewriting and other changes to the system software. In this paper, we examine a signature-based detection of CRAs, where the attack is detected by observing the behavior of programs and detecting the gadget execution patterns. We first demonstrate that naive signature-based defenses can be defeated by introducing special “delay gadgets ” as part of the attack. We then show how a software-configurable signature-based approach can be designed to defend against such stealth CRAs, including the attacks that manage to use longer-length gadgets. The proposed defense (called SCRAP) can be implemented entirely in hardware using simple logic at the commit stage of the pipeline. SCRAP is realized with minimal performance cost, no changes to the software layers and no implications on binary compatibility. Finally, we show that SCRAP generates no false alarms on a wide range of applications.

Bypassing Modern CPU Protections With Function-Oriented Programming

Over the years, code reuse attacks such as return-oriented programming (ROP) and jump-oriented programming (JOP) have been a primary target to gain execution on a system via buffer overflow, memory corruption, and code flow hijacking vulnerabilities. However, new CPU-level protections have introduced a variety of hurdles. ARM has designed the “Pointer Authentication” and “Branch Target Identification” mechanisms to handle the authentication of memory addresses and pointers, and Intel has followed through with its Shadow Stack and Indirect Branch Targeting mechanisms, otherwise known as Control-Flow Enforcement Technology. As intended, these protections make it nearly impossible to utilize regular code reuse methods such as ROP and JOP. The inclusion of these new protections has left gaps in the system\u27s security where the use of function-based code reuse attacks are still possible. This research demonstrates a novel approach to utilizing Function-Oriented Programming (FOP) as a technique to utilize in such environments. The design and creation of the “FOP Mythoclast” tool to identify FOP gadgets within Intel and ARM environments demonstrates not only a proof of concept (PoC) for FOP, but further cements its ability to thrive in diverse constrained environments. Additionally, the demonstration of FOP within the Linux kernel showcases the ability of FOP to excel in complex and real-world situations. This research concludes with potential solutions for mitigating FOP without adversely affecting system performance

Binary Exploitation in Industrial Control Systems: Past, Present and Future

Despite being a decades-old problem, binary exploitation still remains a serious issue in computer security. It is mainly due to the prevalence of memory corruption errors in programs written with notoriously unsafe but yet indispensable programming languages like C and C++. For the past 30 years, the nip-and-tuck battle in memory between attackers and defenders has been getting more technical, versatile, and automated. With raised bar for exploitation in common information technology (IT) systems owing to hardened mitigation techniques, and with unintentionally opened doors into industrial control systems (ICS) due to the proliferation of industrial internet of things (IIoT), we argue that we will see an increased number of cyber attacks leveraging binary exploitation on ICS in the near future. However, while this topic generates a very rich and abundant body of research in common IT systems, there is a lack of systematic study targeting this topic in ICS. The present work aims at filling this gap and serves as a comprehensive walkthrough of binary exploitation in ICS. Apart from providing an analysis of the past cyber attacks leveraging binary exploitation on ICS and the ongoing attack surface transition, we give a review of the attack techniques and mitigation techniques on both general-purpose computers and embedded devices. At the end, we conclude this work by stressing the importance of network-based intrusion detection, considering the dominance of resource-constrained real-time embedded devices, low-end embedded devices in ICS, and the limited ability to deploy arbitrary defense mechanism directly on these devices