메모리 변조 공격 대응을 위한 하드웨어 기술

학위논문 (박사)-- 서울대학교 대학원 : 전기·컴퓨터공학부, 2017. 2. 백윤흥.Many programs are written in unsafe languages like C or C++ mainly due to their advantages in performance, and most of them are too complex to be implemented without implementation errors. For these two reasons, such programs inevitably have vulnerabilities with which attackers can access their memory arbitrary. Unfortunately, it is said to be impossible to eliminate the vulnerabilities. Whereas programs can be verified not to have some vulnerabilities, only small programs can be analyzed statically and not all vulnerabilities can be found and fixed. To address the problem of the vulnerable programs, researchers have proposed a number of mechanisms to mitigate the attacks exploiting the vulnerabilities. This thesis presents novel hardware-assisted mechanisms against those attacks exploiting the vulnerabilities, which are called the memory corruption attacks. The first half discusses the ones against the attacks on OS kernels. In most computer systems, OS kernels have the full control. Every program running on a system has to call the kernel to access or acquire the resources of the system such as the network, file system, or even the memory. This nature makes the OS kernels be an attractive target for attackers. Taking control of it, they can affect every single program running on the system. A difficulty in devising mechanisms to mitigate the attacks on OS kernels comes from the fact that they control the system. Any mechanism that relies on the OS kernels can be nullified by the attackers with the control of the kernels. This lead to the research on the mechanisms that do not rely on the OS kernels themselves. This thesis presents the state of the art of the mechanisms using physically isolated hardware components to avoid relying on the OS kernels. We designed and implemented a novel means for such mechanisms to collect the kernel events efficiently and effectively, and utilized them to mitigate the common types of attacks. The second half presents hardware-assisted mechanisms for memory corruption attacks in general. Though many mechanisms have been proposed to mitigate memory corruption attacks, most of them are not practical. Some of them have limited backward compatibility which requires the existing programs to be fixed to adopt them, and most of them are not efficient enough to be widely deployed. This thesis aims to design practical mechanisms to mitigate memory corruption attacks, and presents two of such mechanisms. The first one enables the programs to isolate the data-flow of sensitive data from the others. Such isolation makes it more difficult for the attackers to corrupt the sensitive data because only the vulnerabilities in the code blocks accessing them can be exploited to corrupt them. The second one prevents the attackers from building up the attacks reliably by randomizing data space. Once a program adopts the mechanism, only the memory accesses complying with the results of the static analysis can be completed correctly. As the attacks usually cause the victim programs to violate the results, the attacker-induced memory accesses will cause unpredictable values to be stored or loaded. In summary, this thesis presents four mechanisms to mitigate the memory corruption attacks either on OS kernels or user-level programs.1 Introduction 1 1.1 Hardware-basedMonitorsforOSKernels 3 1.2 Hardware-assisted Enforcement of Data-Flow Integrity 4 1.3 Outline 5 2 Snoop-Based Kernel Integrity Monitors 7 2.1 Motivations 7 2.2 Assumptions and Threat Model 11 2.2.1 Assumptions 11 2.2.2 Threat Model 11 2.3 Transient Attacks 11 2.3.1 Definition 12 2.3.2 Difficulties of Detecting Transient Attacks 13 2.4 Vigilare System Requirements 13 2.4.1 Selective Bus-traffic Collection and Sufficient Computing Power 14 2.4.2 Handling Bursty Traffic 15 2.4.3 Integrity of the Vigilare System 15 2.5 Detection of the Attacks on Immutable Regions 16 2.5.1 Immutable Regions of Linux Kernel 16 2.5.2 Physical Addresses of Immutable Regions 18 2.5.3 SnoopMon 18 2.5.4 SnoopMon-A 21 2.5.5 SnoopMon-S 22 2.6 Detection of the Attacks on Mutable Regions 24 2.6.1 Attacks on Mutable Regions 25 2.6.2 KI-Mon 26 2.6.3 Detection Mechanisms 29 2.7 Protection of the Kernel from Permanent Damage 31 2.8 Evaluation 35 2.8.1 Comparison with Snapshot-based Monitoring 35 2.8.2 Effectiveness of Snoop-based Monitoring 39 2.8.3 Discussions 41 2.9 Limitations and FutureWork 42 2.9.1 RelocationAttack 42 2.9.2 CodeReuseAttacks 43 2.9.3 PrivilegeEscalation. 44 2.9.4 CacheResidentAttacks 44 2.10 RelatedWork 46 2.10.1 Hypervisor-basedApproaches 46 2.10.2 Hardware-basedApproaches 48 2.10.3 SnoopingBusTraffic 49 2.11 Summary 49 3 Protection of OS Kernels from Code-Injection and Code-Reuse Attacks 51 3.1 Motivations 51 3.2 Problem Definition 55 3.2.1 Threat Model 55 3.2.2 Assumptions 56 3.3 Code-Injection Attacks 56 3.3.1 Architectural Supports 56 3.3.2 Detection Mechanism 61 3.4 ROPAttacks 67 3.4.1 Branch Address Classification 69 3.4.2 Call Site Emission 69 3.4.3 Protection of Shadow Stacks 70 3.4.4 Context Switches 71 3.4.5 Shadow Stack Creation 71 3.5 Evaluation 72 3.5.1 ImplementationDetails 72 3.5.2 Performance 74 3.5.3 Security 77 3.6 Limitations and Future Work 80 3.6.1 Bypassing the Scheme 80 3.6.2 Kernel Modules 81 3.7 Related Work 81 3.7.1 Page Table Protection 81 3.7.2 Hypervisor-based Approaches 82 3.7.3 Snapshot Analyses 82 3.7.4 Bus Snooping 83 3.7.5 Control-Flow Integrity for Privileged Software Layer 83 3.7.6 Software Diversification 83 3.7.7 Formally Verified Microkernels 84 3.7.8 Debug Interfaces 84 3.7.9 Architectural Supports for Shadow Stacks 85 3.8 Summary 85 4 Data-Flow Isolation 87 4.1 Motivations 87 4.2 Threat Model and Assumptions 91 4.3 Background and Related Work 92 4.3.1 Data-flow Integrity 92 4.3.2 Tag-based Memory Protection 93 4.3.3 Tag-based Hardware 95 4.3.4 Memory Safety 96 4.4 HDFI Architecture 96 4.4.1 ISA Extension 97 4.4.2 Memory Tagger 98 4.4.3 Optimizations 99 4.4.4 Protecting the Tag Tables 101 4.5 Implementation 101 4.5.1 Hardware 102 4.5.2 Software Support 106 4.6 Evaluation 106 4.6.1 Verification 108 4.6.2 Performance Overhead 108 4.7 Limitations and Future Work 111 4.8 Summary 112 5 Data Space Randomization 114 5.1 Motivations 114 5.2 Background 117 5.2.1 Mitigation with DSR 120 5.2.2 Limitations of Existing DSR Schemes 121 5.3 Threat Model 122 5.4 Design 123 5.4.1 Hardware Overview 124 5.4.2 Hardware Initialization 125 5.4.3 New Instructions 126 5.4.4 DSR Overview 128 5.5 Prototype Implementation 128 5.5.1 Instruction Encoding 129 5.5.2 Processor Pipeline 131 5.5.3 DSR Prototype 133 5.6 Security Evaluation 135 5.6.1 Real-World Protection 138 5.7 Performance Evaluation 139 5.8 Limitations 142 5.9 Future Work 143 5.10 Related Work 144 5.11 Summary 147 6 Conclusion 148 7 Bibliography 150 Abstract (In Korean) 173Docto

TRust: A Compilation Framework for In-process Isolation to Protect Safe Rust against Untrusted Code

Rust was invented to help developers build highly safe systems. It comes with a variety of programming constructs that put emphasis on safety and control of memory layout. Rust enforces strict discipline about a type system and ownership model to enable compile-time checks of all spatial and temporal safety errors. Despite this advantage in security, the restrictions imposed by Rust???s type system make it difficult or inefficient to express certain designs or computations. To ease or simplify their programming, developers thus often include untrusted code from unsafe Rust or external libraries written in other languages. Sadly, the programming practices embracing such untrusted code for flexibility or efficiency subvert the strong safety guarantees by safe Rust. This paper presents TRUST, a compilation framework which against untrusted code present in the program, provides trustworthy protection of safe Rust via in-process isolation. Its main strategy is allocating objects in an isolated memory region that is accessible to safe Rust but restricted from being written by the untrusted. To enforce this, TRUST employs software fault isolation and x86 protection keys. It can be applied directly to any Rust code without requiring manual changes. Our experiments reveal that TRUST is effective and efficient, incurring runtime overhead of only 7.55% and memory overhead of 13.30% on average when running 11 widely used crates in Rust

Kernel Code Integrity Protection at the Physical Address Level on RISC-V

An operating system kernel has the highest privilege in most computer systems, making its code integrity critical to the entire system’s security. Failure to protect the kernel code integrity allows an attacker to modify the kernel code pages directly or trick the kernel into executing instructions stored outside the kernel code pages. Existing prevention mechanisms rely on the memory management unit in which certain memory pages are marked as not-executable in supervisor mode to prevent such attacks. However, an attacker can bypass these existing mechanisms by directly manipulating the page table contents to mark the memory pages with malicious code as supervisor-executable. This paper shows that a small architectural extension enables a physical address-level mechanism to stop this threat without relying on page table integrity. PRIV LOCK lets, at boot time, the kernel specifies the physical address ranges containing its code. At run time, PRIV LOCK ensures that the content within the range is not manipulated and that only the instructions from those pages are executed while the processor runs in supervisor mode. Despite this protection, the kernel can still create new code pages (e.g., for loadable kernel modules) and make them executable with the help of PRIV LOCK ’s secure loader. The experimental results show that PRIV LOCK incurs low performance (<0.5%), area (0.14–0.3%), and energy/power (0.053–2%) overhead

Extrax: Security extension to extract cache resident information for snoop-based external monitors

Advent of rootkits has urged researchers to conduct much research on defending the integrity of OS kernels. Even though recently proposed snoop-based monitors have shown to provide higher performance and security level compared to conventional hypervisor-based monitors, we discovered that the use of write-back caches in a system would seriously undermine the effectiveness of snoop-based monitors. To address the problem, we propose a special hardware unit called Extrax which makes use of existing hardware logic, core debugging interface, to extract necessary information for security monitoring. Being implemented to refine the debug information for security purposes, Extrax assists snoop-based monitors to detect attacks that exploit write-back caches. Experimental results show that our system can detect more advanced attacks, which the state-of-the-art snoop-based hardware monitors cannot capture, with moderate area overhead and power consumption

libmpk: Software Abstraction for Intel Memory Protection Keys (Intel MPK)

Intel Memory Protection Keys (MPK) is a new hardware primitive to support thread-local permission control on groups of pages without requiring modification of page tables. Unfortunately, its current hardware implementation and software support suffer from security, scalability, and semantic problems: (1) vulnerable to protection-key-use-after-free; (2) providing the limited number of protection keys; and (3) incompatible with mprotect()???s process-based permission model. In this paper, we propose libmpk, a software abstraction for MPK. It virtualizes the hardware protection keys to eliminate the protection-key-use-after-free problem while providing accesses to an unlimited number of virtualized keys. To support legacy applications, it also provides a lazy inter-thread key synchronization. To enhance the security of MPK itself, libmpk restricts unauthorized writes to its metadata. We apply libmpk to three real-world applications: OpenSSL, JavaScript JIT compiler, and Memcached for memory protection and isolation. Our evaluation shows that it introduces negligible performance overhead (<1%) compared with the original, unprotected versions and improves performance by 8.1?? compared with the secure equivalents using mprotect(). The source code of libmpk is publicly available and maintained as an open source project

Fuzzing file systems via two-dimensional input space exploration

File systems, a basic building block of an OS, are too big and too complex to be bug free. Nevertheless, file systems rely on regular stress-testing tools and formal checkers to find bugs, which are limited due to the ever-increasing complexity of both file systems and OSes. Thus, fuzzing, proven to be an effective and a practical approach, becomes a preferable choice, as it does not need much knowledge about a target. However, three main challenges exist in fuzzing file systems: mutating a large image blob that degrades overall performance, generating image-dependent file operations, and reproducing found bugs, which is difficult for existing OS fuzzers. Hence, we present JANUS, the first feedback-driven fuzzer that explores the two-dimensional input space of a file system, i.e., mutating metadata on a large image, while emitting image-directed file operations. In addition, JANUS relies on a library OS rather than on traditional VMs for fuzzing, which enables JANUS to load a fresh copy of the OS, thereby leading to better reproducibility of bugs. We evaluate JANUS on eight file systems and found 90 bugs in the upstream Linux kernel, 62 of which have been acknowledged. Forty-three bugs have been fixed with 32 CVEs assigned. In addition, JANUS achieves higher code coverage on all the file systems after fuzzing 12 hours, when compared with the state-of-the-art fuzzer Syzkaller for fuzzing file systems. JANUS visits 4.19x and 2.01x more code paths in Btrfs and ext4, respectively. Moreover, JANUS is able to reproduce 88-100% of the crashes, while Syzkaller fails on all of them