Stack Bounds Protection with Low Fat Pointers Gregory J. Duck and Roland H. C. Yapy Lorenzo Cavallaroz Department of Computer Science Information Security Group National University of Singapore Royal Holloway University of London fgregory, [email protected] [email protected] with “buffer overflow” on the NVD (National Vulnerability Database) returns at least 972 entries for the past three years Abstract—Object bounds overflow errors are a common source of security vulnerabilities. In principle, bounds check alone. The 2014 Heartbleed [12] bug, which was perhaps one instrumentation eliminates the problem, but this introduces high of the most serious and widespread vulnerabilities of recent overheads and is further hampered by limited compatibility times, was also a buffer overflow. against un-instrumented code. On 64-bit systems, low-fat pointers Given the well understood nature of buffer overflow and are a recent scheme for implementing efficient and compatible bounds checking by transparently encoding meta information the numerous proposed solutions, it is reasonable to ask why within the native pointer representation itself. However, low-fat protection mechanisms that prevent buffer overflow are not in pointers are traditionally used for heap objects only, where the widespread use. There are a number of barriers to adoption allocator has sufficient control over object location necessary for that have been identified [24], including: the encoding. This is a problem for stack allocation, where there • exist strong constraints regarding the location of stack objects Performance: Does the solution slow the program down that is apparently incompatible with the low-fat pointer approach. too much? Does the solution use too much memory? To address this problem, we present an extension of low-fat • Software Compatibility: Does the solution work with pointers to stack objects by using a collection of techniques, existing code bases without additional modification? such as pointer mirroring and memory aliasing, thereby allowing • Binary Compatibility: Does the solution change the stack objects to enjoy bounds error protection from instrumented Application Binary Interface (ABI) meaning that binary code. Our extension is compatible with common special uses of modules (e.g., system or proprietary libraries) need to be the stack, such as alloca, setjmp and longjmp, exceptions, and re-compiled? multi-threading, which rely on direct manipulation of the stack pointer. Our experiments show that we successfully extend the Low runtime performance overheads are important (and in advantages of the low-fat pointer encoding to stack objects. The general the lower the better), however the impact is application end result is a competitive bounds checking instrumentation for dependent. For example, the AddressSanitizer [22]-hardened the stack and heap with low memory and runtime overheads, Tor browser [25] is an example application where security and high compatibility with un-instrumented legacy code. is prioritized over performance. Memory overheads are also important, especially in server contexts where available sys- I. INTRODUCTION tem memory may be at a premium. Memory overheads can translate into time overheads under low memory conditions. System code and applications with high-performance re- Software compatibility means that programs which use a quirements are usually written in low-level languages such variety of compiler and language specific features continue as C and C++. These programming languages do not provide to work, e.g., undefined behavior (out-of-bounds pointers, any protection against memory errors (e.g., buffer overflows), integer overflows, etc.), abnormal control-flow (longjmp, C++ and this is a well known source of security vulnerabilities exceptions, etc.), and inline assembly. Binary compatibility is and exploits. Although memory errors have been well re- a necessity in the real world given that source code is not searched with numerous proposed solutions [24], [26], the always available for libraries. Solutions that change the ABI threat nevertheless persists. For example, a search for CVEs are automatically incompatible with such applications. y This research was partially supported by a grant from the National Re- Recently, a bounds overflow protection mechanism [10] for search Foundation, Prime Minister’s Office, Singapore under its National Cy- C/C++ was proposed that achieves good runtime performance bersecurity R&D Program (TSUNAMi project, No. NRF2014NCR-NCR001- 21) and administered by the National Cybersecurity R&D Directorate. and software compatibility, along with excellent memory per- z This research was partially supported by the UK EPSRC research grant formance and binary compatibility. The protection mechanism EP/L022710/1. is based on low-fat pointers that transparently encodes bounds meta information (i.e., an object’s base address and size) into the native machine representation of a pointer itself. This meta Permission to freely reproduce all or part of this paper for noncommercial information can be later retrieved to check all read and write purposes is granted provided that copies bear this notice and the full citation on the first page. Reproduction for commercial purposes is strictly prohibited accesses are within the bounds of the corresponding object, without the prior written consent of the Internet Society, the first-named author a.k.a. bounds checking. Since low-fat pointers are also regular (for reproduction of an entire paper only), and the author’s employer if the machine pointers, good runtime performance and excellent paper was prepared within the scope of employment. memory performance with binary compatibility is achieved. NDSS ’17, 26 February - 1 March 2017, San Diego, CA, USA The low-fat pointer approach is feasible on 64-bit systems with Copyright 2017 Internet Society, ISBN 1-891562-46-0 http://dx.doi.org/10.14722/ndss.2017.23287 sufficient pointer bit-width, such as the x86_64. The main challenge for low-fat pointers is that sufficient - Data Flow attacks [6], [13], where a data value is control over the memory allocator is required in order to overwritten causing the program to misbehave in a way enforce the pointer encoding. This is feasible for the heap allo- beneficial to the attacker, e.g., privilege escalation. cator (e.g., malloc), but is more difficult for stack allocations OOB reads can lead to: where the placement of objects in memory is highly restricted. This is a major deficiency since many buffer/object overflow - Information Leakage attacks, such as the exploitation of bugs still affect the stack [1]. the Heartbleed bug [12]. This can also be seen as a In this paper, we show how to extend low-fat pointers subclass of data flow attacks. to stack objects, thereby enjoying the same bounds overflow One effective method for preventing OOB-errors is bounds protection as heap objects. To achieve this, we introduce a low- checking instrumentation. The basic idea is as follows: given fat stack allocator, that replaces the default stack allocation a pointer p associated with an object O with base address scheme automatically inserted by the compiler, but ensures (base) and size (size), then p is out-of-bounds with respect to that pointers to allocated stack objects satisfy the location and O if the following test (isOOB) succeeds: alignment requirements of the low-fat pointer encoding. The low-fat stack allocator uses a variety of techniques introduced (p < base) || (p > base+size−sizeof(*p)) (isOOB) in this paper, such as fast allocation size over-approximation, Object bounds errors can be prevented by instrumenting every dynamic stack object alignment, stack object pointer mirroring memory read or write involving p as follows (instrumentation (for location), and memory aliasing optimization to keep code is shaded): memory overheads low. Our solution specially focuses on the key practical barriers against adoption, such as overheads and if (isOOB(p,base ,size)) software/binary compatibility. Good software compatibility is error (); achieved by transparently supporting C and C++ features, which v = *p; or *p = v; make direct use of the stack, e.g., setjmp/longjmp, C++ exceptions. Binary compatibility is achieved because: (a) the Here function error() reports the bounds error and aborts the representation of pointers and the ABI is unchanged (low-fat program—preventing any control/data or information leakage pointer are regular machine pointers); and (b) un-instrumented attacks. The object’s size and base is otherwise known as the code can be freely mixed with instrumented code that supports bounds meta information. bounds checking (e.g., can link un-instrumented libraries). A. Traditional Bounds Checking Methods We have implemented a version of the low-fat heap+stack allocators for C and C++ on the Linux x86_64 system architec- Over the years many different bounds check instrumenta- ture. We experimentally evaluate the implementation against tion systems have been proposed. Most differ on the underlying the SPEC 2006 benchmarks [23], the Apache web server, implementation technology, which we summarize below. the Wilander [28] and RIPE [29] benchmarks, as well as Systems such as Safe-C [4], CCured [20] and Cyclone [15] several recent CVEs concerning stack object overflows. We use “fat pointers” which fuse pointer values and associated show that runtime overheads are competitive: a 54% overhead bounds meta information into one unified object, e.g.: for memory read+write instrumentation