Mitigating Use-After-Free Attacks Using Memory-Reuse-Prohibited Library

Recently, there has been an increase in use-after-free (UAF) vulnerabilities, which are exploited using a dangling pointer that refers to a freed memory. In particular, large-scale programs such as browsers often include many dangling pointers, and UAF vulnerabilities are frequently exploited by drive-by download attacks. Various methods to prevent UAF attacks have been proposed. However, only a few methods can effectively prevent UAF attacks during runtime with low overhead. In this paper, we propose HeapRevolver, which is a novel UAF attackprevention method that delays and randomizes the timing of release of freed memory area by using a memory-reuse-prohibited library, which prohibits a freed memory area from being reused for a certain period. The first condition for reuse is that the total size of the freed memory area is beyond the designated size. The threshold for the conditions of reuse of the freed memory area can be randomized by HeapRevolver. Furthermore, we add a second condition for reuse in which the freed memory area is merged with an adjacent freed memory area before release. Furthermore, HeapRevolver can be applied without modifying the target programs. In this paper, we describe the design and implementation of HeapRevolver in Linux and Windows, and report its evaluation results. The results show that HeapRevolver can prevent attacks that exploit existing UAF vulnerabilities. In addition, the overhead is small

Mitigating Use-after-Free Attack Using Library Considering Size and Number of Freed Memory

Use-after-free (UAF) vulnerabilities, which are abused by exploiting a dangling pointer that refers to a freed memory, execute an arbitrary code. The vulnerability is caused by bug in a program. In particular, it is contained in a large scale program such as browser. HeapRevolver [1] [2], which prohibits freed memory area from being reused for a certain period, has been proposed. HeapRevolver in Windows uses the number of the freed memory areas for prohibiting as a trigger to release the freed memory area. In other words, HeapRevolver uses the number of the freed memory areas as a threshold for releasing. However, when the size of individual freed memory areas is large, the HeapRevolver on Windows increases the memory overhead. In this paper, we propose improved HeapRevolver for Windows considering the size and number of the freed memory areas. Improved HeapRevolver enables to prohibit the reuse of the certain number of the freed memory areas at any time via the size and number of the freed memory areas as a threshold. The evaluation results show that the improved HeapRevolver can prevent attacks that exploiting UAF vulnerabilities. In particular, when the size of individual freed memory areas is small in the programs, it is effective to decrease the attack success rate

HeapRevolver: Delaying and Randomizing Timing of Release of Freed Memory Area to Prevent Use-After-Free Attacks

Recently, there has been an increase in use-after-free (UAF) vulnerabilities, which are exploited using a dangling pointer that refers to a freed memory. Various methods to prevent UAF attacks have been proposed. However, only a few methods can effectively prevent UAF attacks during runtime with low overhead. In this paper, we propose HeapRevolver, which is a novel UAF attack-prevention method that delays and randomizes the timing of release of freed memory area by using a memory-reuse-prohibited library, which prohibits a freed memory area from being reused for a certain period. In this paper, we describe the design and implementation of HeapRevolver in Linux and Windows, and report its evaluation results. The results show that HeapRevolver can prevent attacks that exploit existing UAF vulnerabilities. In addition, the overhead is small

SafeBet: Secure, Simple, and Fast Speculative Execution

Spectre attacks exploit microprocessor speculative execution to read and transmit forbidden data outside the attacker's trust domain and sandbox. Recent hardware schemes allow potentially-unsafe speculative accesses but prevent the secret's transmission by delaying most access-dependent instructions even in the predominantly-common, no-attack case, which incurs performance loss and hardware complexity. Instead, we propose SafeBet which allows only, and does not delay most, safe accesses, achieving both security and high performance. SafeBet is based on the key observation that speculatively accessing a destination location is safe if the location's access by the same static trust domain has been committed previously; and potentially unsafe, otherwise. We extend this observation to handle inter trust-domain code and data interactions. SafeBet employs the Speculative Memory Access Control Table (SMACT) to track non-speculative trust domain code region-destination pairs. Disallowed accesses wait until reaching commit to trigger well-known replay, with virtually no change to the pipeline. Software simulations using SpecCPU benchmarks show that SafeBet uses an 8.3-KB SMACT per core to perform within 6% on average (63% at worst) of the unsafe baseline behind which NDA-restrictive, a previous scheme of security and hardware complexity comparable to SafeBet's, lags by 83% on average

DASICS: Enhancing Memory Protection with Dynamic Compartmentalization

In the existing software development ecosystem, security issues introduced by third-party code cannot be overlooked. Among these security concerns, memory access vulnerabilities stand out prominently, leading to risks such as the theft or tampering of sensitive data. To address this issue, software-based defense mechanisms have been established at the programming language, compiler, and operating system levels. However, as a trade-off, these mechanisms significantly reduce software execution efficiency. Hardware-software co-design approaches have sought to either construct entirely isolated trusted execution environments or attempt to partition security domains within the same address space. While such approaches enhance efficiency compared to pure software methods, they also encounter challenges related to granularity of protection, performance overhead, and portability. In response to these challenges, we present the DASICS (Dynamic in-Address-Space Isolation by Code Segments) secure processor design, which offers dynamic and flexible security protection across multiple privilege levels, addressing data flow protection, control flow protection, and secure system calls. We have implemented hardware FPGA prototypes and software QEMU simulator prototypes based on DASICS, along with necessary modifications to system software for adaptability. We illustrate the protective mechanisms and effectiveness of DASICS with two practical examples and provide potential real-world use cases where DASICS could be applied.Comment: 16 pages, 6 figure

메모리 보호를 위한 보안 정책을 시행하기 위한 코드 변환 기술

학위논문(박사)--서울대학교 대학원 :공과대학 전기·컴퓨터공학부,2020. 2. 백윤흥.Computer memory is a critical component in computer systems that needs to be protected to ensure the security of computer systems. It contains security sensitive data that should not be disclosed to adversaries. Also, it contains the important data for operating the system that should not be manipulated by the attackers. Thus, many security solutions focus on protecting memory so that sensitive data cannot be leaked out of the computer system or on preventing illegal access to computer data. In this thesis, I will present various code transformation techniques for enforcing security policies for memory protection. First, I will present a code transformation technique to track implicit data flows so that security sensitive data cannot leak through implicit data flow channels (i.e., conditional branches). Then I will present a compiler technique to instrument C/C++ program to mitigate use-after-free errors, which is a type of vulnerability that allow illegal access to stale memory location. Finally, I will present a code transformation technique for low-end embedded devices to enable execute-only memory, which is a strong security policy to protect secrets and harden the computing device against code reuse attacks.컴퓨터 메모리는 컴퓨터 시스템의 보안을 위해 보호되어야 하는 중요한 컴포넌트이다. 컴퓨터 메모리는 보안상 중요한 데이터를 담고 있을 뿐만 아니라, 시스템의 올바른 동작을 위해 공격자에 의해 조작되어서는 안되는 중요한 데이터 값들을 저장한다. 따라서 많은 보안 솔루션은 메모리를 보호하여 컴퓨터 시스템에서 중요한 데이터가 유출되거나 컴퓨터 데이터에 대한 불법적인 접근을 방지하는 데 중점을 둔다. 본 논문에서는 메모리 보호를 위한 보안 정책을 시행하기 위한 다양한 코드 변환 기술을 제시한다. 먼저, 프로그램에서 분기문을 통해 보안에 민감한 데이터가 유출되지 않도록 암시적 데이터 흐름을 추적하는 코드 변환 기술을 제시한다. 그 다음으로 C / C ++ 프로그램을 변환하여 use-after-free 오류를 완화하는 컴파일러 기술을 제시한다. 마지막으로, 중요 데이터를 보호하고 코드 재사용 공격으로부터 디바이스를 강화할 수 있는 강력한 보안 정책인 실행 전용 메모리(execute-only memory)를 저사양 임베디드 디바이스에 구현하기 위한 코드 변환 기술을 제시한다.1 Introduction 1 2 Background 4 3 A Hardware-based Technique for Efficient Implicit Information Flow Tracking 8 3.1 Introduction 8 3.2 Related Work 10 3.3 Our Approach for Implicit Flow Tracking 12 3.3.1 Implicit Flow Tracking Scheme with Program Counter Tag 12 3.3.2 tP C Management Technique 15 3.3.3 Compensation for the Untaken Path 20 3.4 Architecture Design of IFTU 22 3.4.1 Overall System 22 3.4.2 Tag Computing Core 24 3.5 Performance and Area Analysis 26 3.6 Security Analysis 28 3.7 Summary 30 4 CRCount: Pointer Invalidation with Reference Counting to Mitigate Useafter-free in Legacy C/C++ 31 4.1 Introduction 31 4.2 Related Work 36 4.3 Threat Model 40 4.4 Implicit Pointer Invalidation 40 4.4.1 Invalidation with Reference Counting 40 4.4.2 Reference Counting in C/C++ 42 4.5 Design 44 4.5.1 Overview 45 4.5.2 Pointer Footprinting 46 4.5.3 Delayed Object Free 50 4.6 Implementation 53 4.7 Evaluation 56 4.7.1 Statistics 56 4.7.2 Performance Overhead 58 4.7.3 Memory Overhead 62 4.8 Security Analysis 67 4.8.1 Attack Prevention 68 4.8.2 Security considerations 69 4.9 Limitations 69 4.10 Summary 71 5 uXOM: Efficient eXecute-Only Memory on ARM Cortex-M 73 5.1 Introduction 73 5.2 Background 78 5.2.1 ARMv7-M Address Map and the Private Peripheral Bus (PPB) 78 5.2.2 Memory Protection Unit (MPU) 79 5.2.3 Unprivileged Loads/Stores 80 5.2.4 Exception Entry and Return 80 5.3 Threat Model and Assumptions 81 5.4 Approach and Challenges 82 5.5 uXOM 85 5.5.1 Basic Design 85 5.5.2 Solving the Challenges 89 5.5.3 Optimizations 98 5.5.4 Security Analysis 99 5.6 Evaluation 100 5.6.1 Runtime Overhead 103 5.6.2 Code Size Overhead 106 5.6.3 Energy Overhead 107 5.6.4 Security and Usability 107 5.6.5 Use Cases 108 5.7 Discussion 110 5.8 Related Work 111 5.9 Summary 113 6 Conclusion and Future Work 114 6.1 Future Work 115 Abstract (In Korean) 132 Acknowlegement 133Docto

Improved Architectures for Secure Intra-process Isolation

Intra-process memory isolation can improve security by enforcing least-privilege at a finer granularity than traditional operating system controls without the context-switch overhead associated with inter-process communication. Because the process has traditionally been a fundamental security boundary, assigning different levels of trust to components within a process is a fundamental change in secure systems design. However, so far there has been little research on the challenges of securely implementing intra-process isolation on top of existing operating system abstractions. We find that frequently-used assumptions in secure system design do not precisely hold under realistic conditions, and that these discrepancies lead to exploitable vulnerabilities. We evaluate two recently-proposed memory isolation systems and show that both are vulnerable to the same generic attacks that break their security model. We then extend a subset of these attacks by applying them to a fully-precise model of control-flow integrity, demonstrating a data-only attack that bypasses both static and dynamic control-flow integrity enforcement by overwriting executable code in-memory even under typical w^x assumptions. From these two results, we propose a set of kernel modifications called Xlock that systemically addresses weaknesses in memory permissions enforcement on Linux, bringing them into line with w^x assumptions. Finally, we present modifications to intra-process isolation systems that preserve efficient userspace component transitions while drastically reducing risk of accidental kernel mismanagement by modeling intra-process components as separate processes from the kernel\u27s perspective. Taken together, these mitigations represent a more robust architecture for efficient and secure intra-process isolation