200 research outputs found

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

    Full text link
    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

    HardScope: Thwarting DOP with Hardware-assisted Run-time Scope Enforcement

    Full text link
    Widespread use of memory unsafe programming languages (e.g., C and C++) leaves many systems vulnerable to memory corruption attacks. A variety of defenses have been proposed to mitigate attacks that exploit memory errors to hijack the control flow of the code at run-time, e.g., (fine-grained) randomization or Control Flow Integrity. However, recent work on data-oriented programming (DOP) demonstrated highly expressive (Turing-complete) attacks, even in the presence of these state-of-the-art defenses. Although multiple real-world DOP attacks have been demonstrated, no efficient defenses are yet available. We propose run-time scope enforcement (RSE), a novel approach designed to efficiently mitigate all currently known DOP attacks by enforcing compile-time memory safety constraints (e.g., variable visibility rules) at run-time. We present HardScope, a proof-of-concept implementation of hardware-assisted RSE for the new RISC-V open instruction set architecture. We discuss our systematic empirical evaluation of HardScope which demonstrates that it can mitigate all currently known DOP attacks, and has a real-world performance overhead of 3.2% in embedded benchmarks

    Hardware-Assisted Dependable Systems

    Get PDF
    Unpredictable hardware faults and software bugs lead to application crashes, incorrect computations, unavailability of internet services, data losses, malfunctioning components, and consequently financial losses or even death of people. In particular, faults in microprocessors (CPUs) and memory corruption bugs are among the major unresolved issues of today. CPU faults may result in benign crashes and, more problematically, in silent data corruptions that can lead to catastrophic consequences, silently propagating from component to component and finally shutting down the whole system. Similarly, memory corruption bugs (memory-safety vulnerabilities) may result in a benign application crash but may also be exploited by a malicious hacker to gain control over the system or leak confidential data. Both these classes of errors are notoriously hard to detect and tolerate. Usual mitigation strategy is to apply ad-hoc local patches: checksums to protect specific computations against hardware faults and bug fixes to protect programs against known vulnerabilities. This strategy is unsatisfactory since it is prone to errors, requires significant manual effort, and protects only against anticipated faults. On the other extreme, Byzantine Fault Tolerance solutions defend against all kinds of hardware and software errors, but are inadequately expensive in terms of resources and performance overhead. In this thesis, we examine and propose five techniques to protect against hardware CPU faults and software memory-corruption bugs. All these techniques are hardware-assisted: they use recent advancements in CPU designs and modern CPU extensions. Three of these techniques target hardware CPU faults and rely on specific CPU features: ∆-encoding efficiently utilizes instruction-level parallelism of modern CPUs, Elzar re-purposes Intel AVX extensions, and HAFT builds on Intel TSX instructions. The rest two target software bugs: SGXBounds detects vulnerabilities inside Intel SGX enclaves, and “MPX Explained” analyzes the recent Intel MPX extension to protect against buffer overflow bugs. Our techniques achieve three goals: transparency, practicality, and efficiency. All our systems are implemented as compiler passes which transparently harden unmodified applications against hardware faults and software bugs. They are practical since they rely on commodity CPUs and require no specialized hardware or operating system support. Finally, they are efficient because they use hardware assistance in the form of CPU extensions to lower performance overhead

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

    Get PDF
    학위논문 (박사)-- 서울대학교 대학원 : 전기·컴퓨터공학부, 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

    Session Armor: Protection Against Session Hijacking using Per-Request Authentication

    Get PDF
    Modern life increasingly relies upon web applications to provide critical services and infrastructure. Activities of banking, shopping, socializing, entertainment, and even medical record keeping are now primarily conducted using the Internet as a medium and HTTP as a protocol. A critical requirement of these tools is the mechanism by which they authenticate users and prevent transaction replay. Despite more than 20 years of widespread deployment, the de-facto technique for accomplishing these goals is the use of a static session bearer token to authenticate all requests for the lifetime of a user session. In addition, the use of any method to prevent request replay is not in common practice. This thesis presents Session Armor, a protocol which builds upon existing techniques to provide cryptographically-strong per-request authentication with both time-based and optional absolute replay prevention. Session Armor is designed to perform well and to be easily deployed by web application developers. It acts as a layer on top of existing session tokens, so as not to require modification of application logic. In addition to Session Armor, two additional tools are presented, JackHammer, a cross-browser extension that allows developers to quickly discover session hijacking vulnerabilities in their web applications, and SessionJack, a tool for analyzing the security properties of session tokens found on the web. A formal specification of the Session Armor protocol is provided. An implementation of the protocol is included as a Python Django middleware and a Chrome browser extension. Performance data is provided with a comparison to previous methods. A formal validation of secrecy and correspondence properties is presented in the Dolev-Yao model.M.S., Computer Engineering -- Drexel University, 201

    Toward least-privilege isolation for software

    Get PDF
    Hackers leverage software vulnerabilities to disclose, tamper with, or destroy sensitive data. To protect sensitive data, programmers can adhere to the principle of least-privilege, which entails giving software the minimal privilege it needs to operate, which ensures that sensitive data is only available to software components on a strictly need-to-know basis. Unfortunately, applying this principle in practice is dif- �cult, as current operating systems tend to provide coarse-grained mechanisms for limiting privilege. Thus, most applications today run with greater-than-necessary privileges. We propose sthreads, a set of operating system primitives that allows �ne-grained isolation of software to approximate the least-privilege ideal. sthreads enforce a default-deny model, where software components have no privileges by default, so all privileges must be explicitly granted by the programmer. Experience introducing sthreads into previously monolithic applications|thus, partitioning them|reveals that enumerating privileges for sthreads is di�cult in practice. To ease the introduction of sthreads into existing code, we include Crowbar, a tool that can be used to learn the privileges required by a compartment. We show that only a few changes are necessary to existing code in order to partition applications with sthreads, and that Crowbar can guide the programmer through these changes. We show that applying sthreads to applications successfully narrows the attack surface by reducing the amount of code that can access sensitive data. Finally, we show that applications using sthreads pay only a small performance overhead. We applied sthreads to a range of applications. Most notably, an SSL web server, where we show that sthreads are powerful enough to protect sensitive data even against a strong adversary that can act as a man-in-the-middle in the network, and also exploit most code in the web server; a threat model not addressed to date
    corecore