Heap layout randomization renders a good portion of heap vulnerabilities unexploitable. However, some remnants of the vulnerabilities are still exploitable even under the randomized layout. According to our analysis, such heap exploits often abuse pointer-width allocation granularity to spray crafted pointers. To address this problem, we explore the efficacy of byte-granularity (the most fine-grained) heap randomization. Heap randomization, in general, has been a well-trodden area; however, the efficacy of byte-granularity randomization has never been fully explored as raises various concerns. This paper unravels the pros and cons of byte-granularity heap randomization by conducting comprehensive analysis in three folds: (i) security effectiveness, (ii) performance impact, and (iii) compatibility analysis to measure deployment cost. Security discussion based on 20 CVE case studies suggests that byte-granularity heap randomization raises the bar against heap exploits more than we initially expected; as pointer spraying approach is becoming prevalent in modern heap exploits. Afterward, to demystify the skeptical concerns regarding misalignment, we conduct cycle-level microbenchmarks and report that the performance cost is highly concentrated to edge cases depending on L1-cache line. Based on such observations, we design and implement an allocator suited to optimize the performance cost of byte-granularity heap randomization; then evaluate the performance with the memory-intensive benchmark (SPEC2006). Finally, we discuss compatibility issues using Coreutils, Nginx, and ChakraCore.
. @cite_40 shows various heap spraying techniques that leverage the allocation granularity of memory allocators. For example, if allocation granularity is fixed, an attacker can split nop-sleds into several pieces and stitch them together with jump instructions. HeapTaichi claimed that reduced allocation granularity in heap randomization is better for security. However, the minimal allocation granularity considered in HeapTaichi is pointer-width. Although HeapTaichi discussed in-depth heap allocation granularity issues, no discussion regarding byte-granularity allocation and its ramification regarding security performance was made.
@cite_40
2114604089 1966822983 1965071495 2154795299
Heap spraying is an attack technique commonly used in hijacking browsers to download and execute malicious code. In this attack, attackers first fill a large portion of the victim process's heap with malicious code. Then they exploit a vulnerability to redirect the victim process's control to attackers' code on the heap. Because the location of the injected code is not exactly predictable, traditional heap-spraying attacks need to inject a huge amount of executable code to increase the chance of success. Injected executable code usually includes lots of NOP-like instructions leading to attackers' shellcode. Targeting this attack characteristic, previous solutions detect heap-spraying attacks by searching for the existence of such large amount of NOP sled and other shellcode. In this paper, we analyze the implication of modern operating systems' memory allocation granularity and present Heap Taichi, a new heap spraying technique exploiting the weakness in memory alignment. We describe four new heap object structures that can evade existing detection tools, as well as proof-of-concept heap-spraying code implementing our technique. Our research reveals that a large amount of NOP sleds is not necessary for a reliable heap-spraying attack. In our experiments, we showed that our heap-spraying attacks are a realistic threat by evading existing detection mechanisms. To detect and prevent the new heap-spraying attacks, we propose enhancement to existing approaches and propose to use finer memory allocation granularity at memory managers of all levels. We also studied the impact of our solution on system performance. Memory management system performance is of increasing importance in today's managed languages. Two lingering sources of overhead are the direct costs of memory allocations and write barriers. This paper introduces it allocation folding, an optimization technique where the virtual machine automatically folds multiple memory allocation operations in optimized code together into a single, larger it allocation group. An allocation group comprises multiple objects and requires just a single bounds check in a bump-pointer style allocation, rather than a check for each individual object. More importantly, all objects allocated in a single allocation group are guaranteed to be contiguous after allocation and thus exist in the same generation, which makes it possible to statically remove write barriers for reference stores involving objects in the same allocation group. Unlike object inlining, object fusing, and object colocation, allocation folding requires no special connectivity or ownership relation between the objects in an allocation group. We present our analysis algorithm to determine when it is safe to fold allocations together and discuss our implementation in V8, an open-source, production JavaScript virtual machine. We present performance results for the Octane and Kraken benchmark suites and show that allocation folding is a strong performance improvement, even in the presence of some heap fragmentation. Additionally, we use four hand-selected benchmarks JPEGEncoder, NBody, Soft3D, and Textwriter where allocation folding has a large impact. Different uses of memory protection schemes have different needs in terms of granularity. For example, heap security can benefit from chunk separation (by using protected "padding" boundaries) and meta-data protection. However, such protection can be done at different granularity (eg. per-word, per-block, or per-page), with different performance, cost and memory overhead tradeoffs for different applications. In this paper, we explore these tradeoffs for the purpose of heap security in order to discover whether the "right" granularity exists and how the granularity of protection affects design decisions.We evaluate such tradeoffs based on the current heap-security approaches in a single address spare operating system. The access control granularities we use are word, 8-byte, 16-byte, 32-byte, and page. We find that none of these schemes is optimal across all applications. In some applications, excessive padding degrades caching performance for coarse-granularity schemes, while in others, large-block permission changes introduce large overheads for finer granularities. To overcome these limitations, we propose a new two-granularity scheme, which uses word- and page-granularity protection to eliminate padding but allow fast page-size permission changes for large memory blocks. On all applications, this new scheme performs as well or better than the best single-granularity scheme. It also performs on par with the more complex Mondrian Memory Protection, which uses a complex trie structure and multiple permissions caching mechanisms to support a hierarchy of protection granularities. Heap-based attacks depend on a combination of memory management error and an exploitable memory allocator. Many allocators include ad hoc countermeasures against particular exploits but their effectiveness against future exploits has been uncertain. This paper presents the first formal treatment of the impact of allocator design on security. It analyzes a range of widely-deployed memory allocators, including those used by Windows, Linux, FreeBSD and OpenBSD, and shows that they remain vulnerable to attack. It them presents DieHarder, a new allocator whose design was guided by this analysis. DieHarder provides the highest degree of security from heap-based attacks of any practical allocator of which we are aware while imposing modest performance overhead. In particular, the Firefox web browser runs as fast with DieHarder as with the Linux allocator.