USENIX Security2017

Oscar: A Practical Page-Permissions-Based Scheme for Thwarting Dangling Pointers

Thurston H. Y. Dang, Petros Maniatis, David A. Wagner

被引用 77 次

摘要

Using memory after it has been freed opens programs up to both data and control-flow exploits. Recent work on temporal memory safety has focused on using explicit lock-and-key mechanisms (objects are assigned a new lock upon allocation, and pointers must have the correct key to be dereferenced) or corrupting the pointer values upon free(). Placing objects on separate pages and using page permissions to enforce safety is an older, wellknown technique that has been maligned as too slow, without comprehensive analysis. We show that both old and new techniques are conceptually instances of lockand-key, and argue that, in principle, page permissions should be the most desirable approach. We then validate this insight experimentally by designing, implementing, and evaluating Oscar, a new protection scheme based on page permissions. Unlike prior attempts, Oscar does not require source code, is compatible with standard and custom memory allocators, and works correctly with programs that fork. Also, Oscar performs favorably -often by more than an order of magnitude -compared to recent proposals: overall, it has similar or lower runtime overhead, and lower memory overhead than competing systems. Explicit lock-and-key: changing the lock e.g., Implicit lock-and-key: revoking the keys e.g., Implicit lock-and-key: changing the lock e.g., Instrumentation CETS DangNull/FreeSentry Electric Fence malloc () Allocate lock address; Issue key; Set lock Register pointer Syscall to create virtual page Simple ptr arithmetic: p+=2  No cost General ptr arithmetic: p=q+1 Propagate lock address and key Update ptr registration  No cost Pointer dereference: *p Check key vs. lock value (at lock address)  No cost <TLB and memory pressure> free () Deallocate lock address Invalidate pointers Syscall to disable virtual page No application source needed Needs source + recompilation  Yes; Req'd by Dhurjati&Adve Physical memory overhead O(# pointers) O(# pointers)  O(# objects)