Heaptherapy: an Efficient End-To-End Solution Against Heap Buffer

HeapTherapy: An Efﬁcient End-to-end Solution against Heap Buffer Overﬂows

Qiang Zeng*, Mingyi Zhao*, Peng Liu The Pennsylvania State University University Park, PA, 16802, USA Email: {quz105, muz127, pliu}@psu.edu

Abstract—For decades buffer overflows have been one of the The first category contains a variety of approaches, which most prevalent and dangerous software vulnerabilities. Although range from bounds checking [21], [38], [6]; to shadow memory many techniques have been proposed to address the problem, based checking [25], [39], [5], [12]; to control/data flow they mostly introduce a very high overhead while others assume monitoring [23], [4], [11]; to N-version/N-variant systems [16], the availability of a separate system to pinpoint attacks or provide [7], [30]. Even with many optimization methods they still lead detailed traces for defense generation, which is very slow in itself to a very high overhead, or require significant extra computing and requires considerable extra resources. We propose the first efficient solution against heap buffer overflows that integrates resources. For instance, AddressSanitizer [39] uses a much attack detection, exploit diagnosis, and defense generation in more efficient shadow mapping and a more compact shadow a single system, named HeapTherapy. It conducts on-the-fly encoding than Valgrind (Memcheck) [25] and TaintTrace [12], lightweight trace collection on the production system (instead but still incurs 73% slowdown and over 3X memory overhead. of a separate replaying system), and initiates automated diagnosis As another example, N-variant execution [16] requires dou- upon exploit detection to generate defenses in realtime. It can bling resource consumption and system maintenance, which is handle both over-write and over-read attacks, such as the recently costly. explosed Heartbleed attack. The system has no false positives, and keeps effective under polymorphic exploits. It is compatible with Instead of performing expensive full execution monitoring, mainstream hardware and operating systems, and does not rely approaches in the second category generate tailored defenses on specific allocation algorithms. We evaluated HeapTherapy on against learned vulnerabilities. Given a zero-day vulnerability, a variety of services (database, web, and ftp) and benchmarks (SPEC CPU2006); it incurs a very low average overhead in terms they trade the prevention of the first buffer overflow(s) for of both speed (6.2%) and memory (7.7%). subsequent low-cost protection. An example of the second category is patching. However, generating patches is a lengthy procedure. According to Symantec the average time for gener- I.INTRODUCTION ating a critical patch for enterprise applications is 28 days [43]. A few approaches that generate defenses quickly after exploit Programs written in C and C++ contain a large number detection have been proposed. One popular approach is to of buffer overflow bugs, which involve writes or reads going generate input filters to filter out suspicious input [22], [27], beyond buffer boundaries.1 In addition to erroneous execution, [50]. However, the false negative rate rises when dealing with buffer overflow bugs can lead to various security threats, input obfuscation, and false positives are a common issue for including data corruption, control-flow hijack, and informa- identifying innocuous requests as attacks. A type of meth- tion leakage. The recently published Heartbleed vulnerability, ods, such as Vulnerability-Specific Execution-based Filtering which has affected hundreds of thousands of servers, was (VSEF) [26] and Vigilante: [14], are based on the observation due to a heap buffer over-read bug that leads to information that, given a sample exploit, only a small portion of instructions leakage [17], [28]. are relevant to the exploit. A defense that monitors the relevant Although there are many tools dedicated to finding buffer part of the program execution is generated to block further overflow bugs through static analysis [47], it is very unlikely to exploits. It is more efficient than full execution monitoring eliminate all the bugs through static analysis. The reality is that and performs better when handling input obfuscation. in 2014 one third of newly exposed software vulnerabilities published by CERT were related to buffer overflows [45]. However, VSEF relies on a separate system to provide Therefore, runtime measures that protect program execution sample exploits for analysis and defense generation; how to against overflow attacks are important. Such measures can pinpoint malicious inputs efficiently is a challenging problem be roughly divided into three categories: (1) Full execution in itself, and such a system might be unavailable due to monitoring; (2) Approaches that learn from history to improve resource constraints. Second, a defense in VSEF takes effect themselves; and (3) Measures that greatly increase the diffi- by instrumenting instructions accessing a specific overflow culty of exploiting buffer overflows. Examples of the third cat- target. While instructions that access a target near a vulnerable egory include StackGuard [15], Data Execution Prevention [2], buffer on the stack, such as a return address, can be easily Address Space Layout Randomization [49], [8], and concurrent identified, it is very unlikely to determine the instructions heap scanning [52], [44]. that access adjacent regions of a vulnerable heap buffer, for a heap buffer can be allocated almost anywhere on the heap. *These two authors have contributed equally. A proper solution to heap buffer overflows is missing in that 1The term “overflow” in this paper refers to both over-writes and over-reads. work. Vigilante has the same issues.

1 As stack-based buffer overflows are better addressed nowa- current calling context ID against the one contained in any days, heap buffer overflows gain growing attention of at- defense. If they match, the new buffer is regarded vulnerable tackers [35], [52]. By noticing that full program execution and a guard page is attached after it. Subsequently, without monitoring usually incurs a high overhead, we target an tracking access instructions or the information flow, out-of- efficient heap buffer overflow countermeasure falling into the bounds buffer access due to continuous read or writes are second category, i.e., learning from history to protect against prevented by system protection automatically. While the guard attacks. It should meet the following goals simultaneously: page is an expensive enhancement [32], HeapTherapy applies (G1) All-in-one solution: trace collection and defense gen- it only to vulnerable heap buffers with a low overall overhead. eration should be built directly into the production system, so that it does not need a separate system and can respond We have implemented HeapTherapy, and evaluated it on a to any detection of attacks instantly. (G2) High efficiency: variety of services (database, web, and ftp) and benchmarks the overall overhead should be low. (G3) High accuracy: the (SPEC CPU2006). The throughput overheads incurred by generated defense should have few to no false positives and HeapTherapy on service programs are all less than 8% with negatives even with polymorphic attacks. (G4) Compatible zero false positives. A thorough evaluation on SPEC shows with mainstream hardware and runtime environment: it should that the speed overhead averages 6.2% and the memory over- not require special hardware and can work with existing head 7.7% when dealing with 10 synthesized vulnerabilities runtime environment; ideally, it does not depend on custom simultaneously. heap allocation algorithms. To our knowledge there is no such We made the following contributions: solution satisfying all the desirable requirements. • We propose an end-to-end solution that integrates In this paper, we present HeapTherapy, a highly efficient defense generation and overflow prevention in a single end-to-end solution against heap buffer overflows that meets system. The defense is generated automatically on the all the goals above. Unlike approaches applying costly bounds user side, so the user system can be enhanced instantly, checking or data/control flow tracking, HeapTherapy employs and the user does not need to maintain a separate inexpensive techniques to identify vulnerable heap buffers system for defense generation. swiftly and enhance them locally. HeapTherapy contains in- memory trace collection, online exploit detection and realtime • Compared to existing work, HeapTherapy incurs a defense generation as part of the defense system. HeapTherapy very low speed and memory overhead. identifies vulnerable heap buffers based on the intrinsic characteristics of an exploit, as opposed to filtering out malicious • The defense generated by HeapTherapy does not have inputs based on signatures, so it is effective under polymorphic false positives, and keeps effective under polymorphic attacks. Finally, it can be easily deployed and does not rely on attacks. specific allocation algorithms. • It is compatible with existing hardware, systems, and libraries. It does not require a custom heap allocation To detect over-read attacks HeapTherapy places inaccessi- 2 ble guard pages randomly throughout the heap space, so that, algorithm. Thus, its deployment is convenient. when repetitive attacks such as Heartbleed are launched to • While none of the techniques employed in HeapTher- collect jigsaw pieces on the heap, it is highly probable that a apy, such as canaries, guard pages, probabilistic detec- guard page is touched and hence the attack is detected before tion, and calling context encoding, is new or complex, significant information is leaked. The widely deployed Address we creatively combine them and deliver a practical Space Layout Randomization (ASLR) is used to facilitate low-cost solution. To our knowledge it is the first one detection of over-write attacks, as a control flow hijack attack that meets all the goals G1-G4 simultaneously. exploiting buffer over-writes causes the program to crash with a high probability due to the difficulty of guessing randomized The remainder of the paper is organized as follows. Sec- addresses. This is used in many other defense techniques as tion II summarizes the related work. Section III gives an well [34], [50]. overview of HeapTherapy’s design. Section IV describes the design and implementation of HeapTherapy. In Section V, we Instead of relying on a separate system to pinpoint and present the result of evaluation. Limitations of HeapTherapy replay offending requests, HeapTherapy collects lightweight are discussed in Section VI and potential applications in in-memory traces during program execution to assist defense Section VII. We conclude this paper in Section VIII. generation. Therefore, it avoids the cost and overhead due to a separate system. II.RELATED WORK Given a heap buffer overflow vulnerability, the vulnerable heap buffers must share some characteristics, and the charac- Due to extensive research in buffer overflows, we do not teristic used in HeapTherapy is their common allocation-time intend to make an exhaustive list of work on the problem. calling context. Thus, a defense generated by HeapTherapy Instead, we examine how techniques applied in HeapTherapy contains the calling context when a vulnerable heap buffer are used in other work. was allocated. We employ a recent advance in calling context Canaries: StackGuard [15] uses canaries to detect stack- representation and retrieval — the calling context encoding based buffer overflows. It has been widely deployed in modern technique [9], [42], [51], which continuously tracks the current calling context with a very low overhead representing it 2While our current implementation uses recompilation, it is feasible to concisely as an integer, named a calling context ID. Whenever implement through binary instrumentation; thus, recompilation is not an a heap buffer is allocated, our malloc wrapper compares the intrinsic limitation of the solution.

2 Temporary compilers, and greatly increased the difﬁculty of stack-based patches buffer overﬂow attacks. Robertson et al. proposed to detect heap buffer corruption by checking canaries placed between Calling context Program heap buffers [37]; however, the checks are only performed encoding Memory Heap at buffer allocations or deallocations, which leaves a large allocator buffers Overrun Diagnosis exploitable time window. Cruiser [52] and Kruiser [44] dra- interposition detection engine Collaborative Installed matically reduce the time window, but they do not prevent patch patches generation data corruption itself. In our work, canaries are only used to detect buffer over-writes. Once an over-write is detected, Fig. 1: The architecture of HeapTherapy. HeapTherapy generates a defense preventing data corruption from repetitive attacks.

Guard pages: Electric Fence puts one inaccessible page As an example, we show how HeapTherapy can be used immediately after or before a buffer [32]. DYnamic Buffer to harden the text-based browser Lynx against a heap buffer Overflow Containment (DYBOC) surrounds every buffer with over-write attack. When parsing an HTML link whose host- two inaccessible pages [40]. The full enhancement for all heap name includes a % character in the last two bytes, the URL buffers incurs prohibitively high overhead, while HeapTherapy decoding code of Lynx 2.8.8dev.1 will write attacker applies guard pages only to over-read detection probabilisti- controlled data after a heap buffer’s boundary, leading to a cally and vulnerable buffers deterministically, incurring a very crash or arbitrary code execution (CVE-2010-2810). In the low overhead. following steps, we use an exploit provided here [24]. Context sensitive defense: The value of calling context A user applies HeapTherapy to hardening Lynx as follows: beyond debugging was recognized early. For example, region- based heap allocation tags heap objects with allocation calling Compilation: The user compiles Lynx with a LLVM com- context information [53]. Calling context was recently used piler, to which we added a calling context encoding instrumen- to generating context sensitive defenses [50], [26], [31], [46], tation pass (PCC.so), and links it with the heaptherapy [20]. However, they commonly use costly call stack walking. shared library for memory allocator interposition by providing HeapTherapy is the first work that employs the calling context the flags: encoding technique to generate context sensitive defense. It CFLAGS= -Xclang -load -Xclang PCC.so largely reduces the overhead compared to using other call- LDFLAGS= -ldl -L. -lheaptherapy ing context retrieval techniques such as stack walking [9], [42], [51]. Through the calling context encoding technique HeapTherapy is able to represent the characteristics of buffers being exploited with one integer and to identify vulnerable buffers through integer comparison. Learning from attacks: The principle has been widely applied to defense generation systems [22], [27], [26], [50], [31], [14]. They usually use or assume a separate system to pinpoint the attacking request, but the separate system can introduce Fig. 2: A crash due to the malformed HTML link, and the significant costs or deployment difficulties. HeapTherapy col- detection and diagnosis result of HeapTherapy. lect lightweight traces in memory to assist defense generation without the need of finding out the malicious request. It is an Online detection and diagnosis: The user then starts end-to-end solution built into the system being protected. Lynx. Once the malformed link is visited, an over-write will HeapTherapy is built on a series of different techniques. occur. HeapTherapy detects this over-write, terminates the Canaries incur a low overhead but provides no overflow pre- program and generates a core dump file. The core dump file vention; it is used in data corruption detection. Guard pages are is then analyzed by the diagnosis engine to locate the over- expensive but can prevent overflows; it is applied to over-read written buffer and to generate a temporary patch containing detection probabilistically and buffers identified as vulnerable the vulnerable buffer’s allocation calling context encoding. deterministically. The glue is the calling context encoding, Figure 2 shows the result of this step. which characterizes and identifies vulnerable buffers. Those techniques work together to deliver a new efficient solution against heap buffer overflows.

III.HEAPTHERAPY OVERVIEW Figure 1 shows the architecture of HeapTherapy, which contains three main components: a compiler pass for adding Fig. 3: Lynx displays the malformed links without crashes. the calling context encoding functionality, a shared library for interposing the memory allocator, and a diagnosis engine for generating temporary patches upon detection. The memory Defense: The temporary patch is then stored in a conﬁg- allocator interposition library enforces the installed patches by uration ﬁle, which will be loaded once the user starts Lynx enhancing the heap buffer being allocated. again. This time when Lynx parses a link exploiting the same

3 clone 1 foo() { 2 int tmp = V; // Added: backup encoding start_thread 3 ... 4 V = 3 * tmp + cs_1; // Added: update it 5 cs_1: bar1(); handle_one_connection 6 V = 3 * tmp + cs_2; // Added: update it 7 cs_2: bar2(); do_handle_one_connection 8 ... 9 V = tmp; // Added: recover the encoding thd_prepare_connection do_command 10 }

my_malloc MDL_key::mdl_key_init Fig. 5: An example of PCC encoding. Four lines are added to maintain the encoding.

malloc stpcpy The vulnerable calling context. (the Nginx example in Section V-A); however, the number The over-write calling context. is very small, and HeapTherapy handles such cases easily by generating one defense for each vulnerable calling context. Fig. 4: The calling context tree of MySQL5.5.19 related to CVE-2012-561. Dashed lines indicate omitted functions. HeapTherapy requires frequent retrieval and comparison of calling contexts. It is notable that if these operations incur high overhead, e.g., through stack walking, the overall performance degradation will be significant. Therefore, we employ calling vulnerability, HeapTherapy prevents the over-write and allows context encoding techniques to speed up. A few encoding Lynx to display the page normally without a crash, as shown techniques, which represent a calling context using one or in Figure 3. We mutate the attack and find the patch still very few integers, have been proposed to track calling contexts effective. continuously with a very low overhead [9], [42], [51]. We Collaborative patch generation: In addition to locally use the approach called probabilistic calling context (PCC) generated patches, the patches can also come from other ma- encoding [9], for it does not need static analysis and encodes chines. The shared and collaborative patch generation makes each calling context into only one word. It uses a very simple an early response to large scale attacks exploiting zero-day hash scheme to update the calling context encoding value right vulnerabilities possible. before each call site: V ← 3×V +cs, where V is a thread-local integer variable storing the current calling context encoding cs IV. DESIGNAND IMPLEMENTATION value and is a hash value of the call site, which is calculated at compilation time based on the file name and line number. In this section, we present the design and implementation of HeapTherapy. We first introduce the idea of applying Figure 5 shows an example of PCC encoding. To imple- calling context encoding to identifying vulnerable heap buffers ment this, we write a compiler pass in LLVM that instruments instantly, and then explain overflow detection, attack diagnosis, the program code. The original work of PCC, which works and defense generation. with Java programs, shows a high efficiency. It is confirmed by our implementation for C and C++ programs, incurring only 1.9% average slowdown on SPEC CPU2006 benchmarks. A. Calling-context Sensitive Defenses Due to the hash nature of PCC encoding, collisions may HeapTherapy uses calling context as a characterization occur such that the encoding values of two different calling of vulnerabilities and the guidance for applying defenses. A contexts are the same. Thus a patch might lead to unnecessary calling context is a sequence of unreturned method invocations protection applied to safe buffers, resulting in some overhead. that lead to a runtime operation. It is also loosely referred to However, it has been shown in theory and practice that PCC as call stack and back trace. can encode millions of contexts in a program with very few Given an attack that exploits a bug to overflow a buffer, hash collisions [9]. our observation is that the allocation calling context of the In HeapTherapy, the encoding value of a calling context buffer is the same when the attack recurs. Figure 4 illustrates is called a calling-context identifier, or CCID; and hence the such an example. It contains part of the calling context tree encoding value of a vulnerable calling context is called a of MySQL 5.5.19 with a heap buffer overflow vulnerability vulnerable CCID (VCCID). Since each calling context is en- (CVE-2012-5612). The left branch shows the calling context coded into a single integer, the comparison operation of a pair when a vulnerable buffer is allocated, while the right one the of calling contexts is transformed to an integer comparison. over-write calling context,. We mutated the script exploiting By storing all the VCCIDs into a hash table, a buffer being the vulnerability and the calling contexts were reproduced. The allocated can be identified as vulnerable or not in O(1) time. observation is confirmed by our experiments on a wide variety of programs (Section V-A), and it is consistent with existing The calling-context sensitive defense has two major bene- work that employs calling context for security purposes [50], fits. First, the VCCID can be used to precisely guide security [26], [31]. We do encounter cases where a single vulnerability enhancement to vulnerable objects during program execution. corresponds to multiple vulnerable allocation calling contexts This avoids a global enhancement and minimizes the perfor-

4 Program Unique allocation CCIDs will be identified as VCCID. In rare cases, multiple over-write vsftpd 176 vulnerabilities exist and are exploited simultaneously. In such Nginx 1361 cases, the same detection and diagnosis procedure is applied to MySQL 8180 each of them. A patch is then generated based on the VCCID TABLE I: Unique allocation calling contexts of three service to defeat attacks exploiting the same over-write vulnerability, programs in one execution. The inputs used to obtain this result which is discussed later. are described in Section V-B. Note that the total number of unique allocation calling contexts in these programs should be 3) Discussion . much larger, and can be approximated using a test suite with Although canaries have proven effective in practice, this high code coverage. approach has several limitations. First, there have been attacks revealing canaries, for example, the format string attack and attacks based on repetitive probings that guess the canary value Head Buffer Tail CCID User buffer byte by byte. The format string bugs have been largely reduced canary size canary recently. Plus, each canary in our system is an XOR of the Fig. 6: Buffer structure I: a buffer structure for over-write canary address and a value randomly assigned at the program detection. start; thus, given a revealed canary, it is still difficult to guess the canary of another buffer. A single probing attack has a very low probability to succeed, while HeapTherapy generates a defense once a single probing is detected. mance overhead. To further understand this benefit, we create a profiler to collect unique allocation calling contexts of three Second, HeapTherapy checks canaries only when a buffer service programs during normal execution, and display the is deallocated. An advanced attack may have hijacked the con- result in Table I. Given a vulnerability, typically only one of trol flow before the canary checking is conducted. However, them is vulnerable, and the calling-context sensitive defense due to the wide deployment of ASLR, the attacker usually will apply enhancements to buffers with that vulnerable calling needs a large number of tries before a successful control flow context only. hijack. Other attacks that increase the chance of bypassing ASLR exist, for example, heap spraying attacks. With the The second benefit is that the calling context information improvement of ASLR itself as well as other defenses, such as captures certain semantic invariants of a vulnerability. Given Data Execution Prevention and Nozzle [35], it is increasingly a vulnerability, no matter how a piece of attack code is difficult to achieve control hijacking with a single over-write obfuscated, the corresponding calling context information can attempt. Again, HeapTherapy reacts upon a single failed at- be used to defend against polymorphic attacks. tempt by generating a patch to defeat further attacks. In this sense, HeapTherapy complements ASLR for enhancing heap Next, we explain how HeapTherapy detects and diagnoses security. buffer over-write and over-read attacks.

B. Buffer Over-write Detection and Diagnosis C. Buffer Over-read Detection and Diagnosis 1) Buffer Structure . Since a buffer over-read does not corrupt canaries, checking To detect buffer over-write, HeapTherapy interposes the canaries cannot be used to detect it. Other techniques, such allocation functions of the underlying memory allocator to bounds checking, incur a very high overhead. We propose to surround each buffer that has not been associated with an place guard pages probabilistically between heap buffers to overflow vulnerability with a head canary and a tail canary, detect heap over-read attacks. and fills the allocation CCID and buffer size after the head canary. The buffer size indicates the number of bytes in a user 1) Buffer Structure . buffer. A buffer size is always a multiple of the word size, so A guard page is a memory page set as inaccessible using, we borrow the last two bits of the buffer size field to indicate for example, mprotect in Linux. A naive over-read detection the buffer type; other types of buffers are introduced later. approach, as in Electric Fence [32], is to append a guard Figure 6 shows the layout of such a buffer. page to every buffer, then any over-read will touch a guard 2) Detection and Diagnosis . page and trigger a segmentation fault. However, this would incur a prohibitively high performance overhead. HeapTherapy Before a buffer is freed, HeapTherapy checks the tail attaches a guard after a buffer with a monitoring probability canary of the buffer and terminates the program if the canary is Pm, which is a small value such as 0.01. A higher Pm offers corrupted. An attack may exploit an over-write vulnerability to a higher chance to detect any single buffer over-reads, but hijack the control flow, which upon success can evade the pre- also incurs a higher overhead. The user can determine this deallocation checking. However, due to ASLR such an attack probability according to its own preference of the trade-off will trigger a segmentation fault signal highly probably, which between security and performance. is also considered as a successful detection. In both cases, a core dump file is generated at the time of detection. Then Figure 7 shows the structure of a monitored buffer. The user our diagnosis engine scans the core dump for a buffer with buffer is placed with its end aligned with the page boundary an intact head canary but a corrupted tail canary. This buffer followed by a guard page, which contains a magic word and the is the origin of this over-write attack, and its CCID value allocation CCID for diagnosis and patch generation purposes.

5 Page The detection and diagnosis has some disadvantages. First, boundary Guard page if the attacker ﬁnishes the exploitation with one or very few attack without being detected, the approach fails. However, in

Buffer with GUARD practice the attacker usually launches a large number of attacks CCID canaries _MAGIC to get enough chunks until target information is obtained. For example, in Heartbleed exploitation millions of attacks are Fig. 7: Buffer structure II: a buffer structure for over-read launched to steal critical information [13]. detection. Second, extra performance overhead can be incurred due to protection applied to suspect buffers. The period of the stage Vulnerable can be very short, as long as repetitive attacks are launched in buffer Over-read length a short time. Moreover, our evaluation in Section V-A shows that when Pm = 0.01 the average number of suspect CCIDs ... Guard page is 28.74, which is small compared with the total number of allocation CCIDs (Table I), and this number reduces to 3.7 Fig. 8: A buffer over-read that spans multiple buffers and when Pm increases to 0.04. touches a guard page. 4) Buffer Release . When a free is invoked, HeapTherapy first turns the appended guard page, if it exists, to be accessible and resets the 2) Detection and Diagnosis . magic word and canaries, and then deallocates the buffer using Once an over-read touches a guard page, a segmentation the underlying memory allocator’s original free function. To fault is triggered and the signal handler installed by HeapTher- locate the guard page, the buffer size field at the head of the apy is invoked. The magic word helps the handler determine buffer is used. whether the signal was due to an access to a guard page or It is worth mentioning that our implementation does not de- not. The handler then terminates the program and produces pend on specific allocation algorithms. The memory allocator a core dump for diagnosis. In Linux, we can determine the of HeapTherapy is implemented as a wrapper of the underlying segmentation fault was due to a read or write based on allocator, which hooks the buffer allocation and deallocation the information saved in the context variable passed to requests. The additional buffer size field in the buffer structure the signal handler. Thus, this works as another approach to is critical for our implementation to keep independent from the detecting over-write attacks. underlying allocation algorithm. Given a single over-read attack, the actual detection probability Pd may be larger than Pm, because an over-read might D. Defenses span several adjacent buffers. We evaluate the actual detection Given a VCCID, the diagnosis engine generates a tempo- probability Pd in Section V-A1. Large volumes of attacks is a rary patch as defined below: common exploitation of an over-read bug for information theft. Due to the random distribution of guard pages, n repetitive Definition 4.1: Temporary Patch. A temporary patch n over-read attacks is detected at a probability 1−(1−Pd) ; that is a tuple of integers hVCCID,T,L,Gi, where T ∈ is, the detection probability increases quickly when n grows. {OVERREAD,OVERWRITE} indicates the bug type, L ≥ 0 is the number of bytes used as padding, and G ∈ {YES,NO} It is challenging to locate the vulnerable buffer directly indicates whether a guard page is needed. by scanning the core dump. As shown in Figure 8, the over- read might span several buffers, so the buffer right before the The use of padding and the case of avoiding guard pages touched guard page is actually not vulnerable. HeapTherapy safely are explained later. Temporary patches for a program uses a two-stage identification method to find the vulnerable are stored in a configuration file. When the program starts, buffer. In the first stage, the diagnosis engine searches back HeapTherapy loads each patch into a hash table with its VC- from the starting address of the guard page to the ending CID used as the key. During program execution, HeapTherapy address of a previous guard page or inaccessible area. Since an interposes all memory allocation functions including malloc, overflow due to continuous read cannot pass a guard page or calloc, realloc, and memalign. inaccessible area, the vulnerable buffer must lie between these We use malloc as an example to demonstrate how two addresses, and all buffers between these two addresses are HeapTherapy handles an allocation request. As illustrated in suspect buffers. Figure 9, it searches the current CCID in the hash table. It it The CCID of each suspect buffer is used to generate a tem- does not match any installed patch, a structure I or II buffer is porary patch. These temporary patches will guide HeapTher- allocated to detect over-write and over-read attacks. Otherwise, apy to append a guard page to every buffer with a suspect a structure III buffer is allocated to shield vulnerable buffers CCID in the next run, so that the same attack will touch the from attacks. guard page appended to a vulnerable buffer. In the second Figure 10 shows the structure of such a shielded stage, the diagnosis engine retrieves the CCID from the guard buffer, which is constructed according to some patch page and removes temporary patches due to other suspect hVCCID,T,L,Gi. If G = YES and L = 0, a guard page is CCIDs. appended to the user buffer directly, so that whenever an over- 3) Discussion . read or over-write occurs, the guard page is touched, which

6 1 void* malloc(size_t size) { the overflow length is limited due to the program interface 2 int t = V; // Read the current CCID or logic. Web servers, for example, typically set the limit 3 Patch *p = hashtable.search(t); on length for URLs up to 4096 characters [3]. For a DNS 4 if(p == NULL) { serve, the full domain name may not exceed the length of 253 5 if(rand() > Pm) { size 6 // For over-write detection characters [1]. Due to the 16-bit field in a Heartbleed 7 allocate a structure I buffer; request, the maximum length of read in a Heartbleed response 8 } else is 64KB. If in a patch T = OVERREAD, to avoid information 9 // For over-read detection leakage the padding is zeroed when a buffer is allocated. 10 allocate a structure II buffer; Finally, if a thorough analysis shows that some reasonable size 11 } of padding is large enough to contain all overflows exploiting 12 } else{ a given vulnerability, the guard page is not needed in this case. 13 // Shield the buffer according to p 14 allocate a structure III buffer; In the cases where the overflow length is unlimited or 15 } very large, in order to avoid exhausting memory, HeapTherapy 16 return buffer address; enforces an upper bound for padding defined by the user. 17 } Some more advanced protection can be applied conveniently when the padding is not large enough and the guard page is Fig. 9: The pseudo code of the malloc function. touched. For example, failure-oblivious computing omits the overrun operations and continues [36]; the reactive immune system returns an error code for the current function invocation Page that leads to an overflow [41]. Both techniques incur a high boundary overhead mainly due to expensive methods identifying such Guard page attack operations as overflows, while HeapTherapy provides an efficient and automatic way to capture overflows. Therefore, it Buffer GUARD User buffer padding CCID size _MAGIC will be an interesting research topic by combing these ideas with HeapTherapy to support program execution continuity. Fig. 10: Buffer structure III: a shielded buffer. E. Additional Features 1) Instant patch generation . triggers a segmentation fault signal automatically to prevent data corruption, control hijacking and information leak. This Conventional patch generation is a long process. The user protection is similar to that provided by those memory-safe needs to provide the input that reproduces the problem to the languages, such as Java and C#, which throw an exception software company, and then waits until the software gets back and terminate program execution whenever a buffer overflow with the patch, which usually takes more than one month [43]. occurs. It is also the best protection that can be provided by HeapTherapy can be used as an offline tool to quickly generate most countermeasures against buffer overflows. temporary patches once an input reproducing the overflow attack is available. The user can simply set P to be 1 and then We consider some other enhancement which potentially m run the program with the input. In this situation, HeapTherapy provides better protection. A desirable protection is that, accurately locates the vulnerable buffer, which is right before under attacks, the program execution continues safely without the touched guard page, and generates the temporary patch. being exploited. While protecting the continuity of program execution is not the focus of this work, as a preliminary step 2) Collaborative patching . towards this goal, we explore the application of padding to buffer allocation in order to mitigate program termination. A temporary patch generated at one site can be shared with other machines running the same vulnerable program. Padding is a straightforward and commonly used idea, Therefore, the effort of detection and patch generation can but it will be very expensive if it is applied to every buffer be aggregated across machines to handle large scale zero-day allocation. A unique advantage of HeapTherapy is that it attacks. Once a machine detects and generates a patch, the identifies vulnerable buffers, which are usually a small portion patch can be distributed to protect other machines. So that a of the whole set of buffers; therefore, expensive enhancement, large scale attack can be defeated before it plagues the Internet. such as guard pages and padding, can be applied to vulnerable buffers only without incurring a high overall overhead. 3) Patching without restart . Currently HeapTherapy infers the size of padding based on In our current implementation the program is restarted after some simple heuristics. Given an over-write attack, it finds out a patch is generated. For complicated programs, the time to the length of overflow based on corrupted canaries. Given an restart may be long. To speed up the service recovery upon over-read attack, it combines the information collected in the patching, the checkpointing and recovery technique can be two stages to infer the length. In both cases, it is possible that used to resume the service from a clean state [33]. This is the padding is not large enough to contain the overflow, and particularly useful for request-handling services, where most the guard page will still be touched. In that case, HeapTherapy heap buffers allocations and deallocations are associated with will increase the padding size based on predefined policies. In per request. Once the patch is installed, when the attacker sends our current implementation, HeapTherapy doubles the padding a new malicious request, shielded buffers will be allocated to size. The adaptive padding growth works well in cases when prevent attacks.

7 Program Vulnerability Reference Heartbleed over-read CVE-2014-0160 main MySQL 5.5.19 over-write CVE-2012-5612 Lynx 2.8.8dev.1 over-write CVE-2010-2810 ngx_master_process_cycle libtiff 4.02 over-write CVE-2013-4243 12 heap buffer SAMATE Dataset N/A overﬂow cases ngx_start_worker_processes ngx_reap_children TABLE II: Vulnerabilities for effectiveness evaluation. ngx_spawn_process

V. EVALUATION We first evaluate the effectiveness of HeapTherapy against default_malloc_ex buffer overflow attacks, and then measure the efficiency of HeapTherapy on service programs and the SPEC CPU2006 malloc Integer benchmark suite. Fig. 11: Two vulnerable calling contexts identified by the A. Effectiveness diagnosis engine. Dashed lines indicate omitted functions. We evaluate the effectiveness of HeapTherapy using 4 real-world vulnerabilities and 12 test cases provided by NIST listed in Table II. The Lynx case was covered in Section III. core dump is generated. Then the diagnosis engine produces a temporary patch containing the VCCID based on the core 1) Heartbleed . dump. Next we set the initial padding size as 4KB, and double the size whenever it is not large enough to contain the overflow Heartbleed attack. The recently exposed Heartbleed attack, that is, the guard page is touched and the process vulnerability in OpenSSL threatens millions of Internet crashes. It takes 1 round to obtain the VCCID and another services [17]. By sending an ill-formed heartbeat request, the 4 rounds to determine that the 32KB padding is large enough attacker can over-read a buffer on the heap and steals up to prevent crashes due to the Heartbleed request. We repeat to 64KB data from the memory. While a Heartbleed attack the experiment 100 times and reproduce the same result every is widely classified as an over-read attack, our investigation time. Once the patch generated, it can be installed to protect shows that the attack can actually exploit two heap-based the production system from Heartbleed attacks efficiently. The vulnerabilities: an uninitialized read bug and an over-read system is then immune from information leakage when waiting bug. Specifically, the victim buffer has 34KB, while the for the official patch that fixes the bug to be generated and attacker can manipulate the length l of the read over this installed. buffer. If l ≤ 34KB, it is just an uninitialized read attack that leaks old data inside the buffer. Otherwise, the attack is a The result contains the following two temporary patches: mix of uninitialized read and over-read. In this case study, we focus on over-read, and avoid the uninitialized read simply by < 0xE2FF92B2,OVERREAD,32KB,YES > zero-filling the buffer. A more systematic study of this issue < 0x6E3D3954,OVERREAD,32KB,YES > can be found in [48]. These two temporary patches indicate that there are two vulnerable calling contexts in the service. The first VC- Experiment setting. Nginx is the third most widely CID (0xE2FF92B2) was found in the core dump due to used web server. We use Nginx 1.3.9 and OpenSSL the first attack; while the following attacks are all related 1.0.1f to create a vulnerable HTTPS service. The program to the second VCCID (0x6E3D3954). Figure 11 shows the is compiled through our PCC encoding pass and linked with details of the two calling contexts. Our further investiga- HeapTherapy’s shared library. OpenSSL optionally uses a tions shows that a Nginx service, when it is started, has freelist to manage heap buffers, so that when a buffer of certain a master process and a worker process. The initial worker lengths is freed, it will be stored in the freelist. In order that process is forked by the master process using the func- HeapTheray interposes heap memory management, we use the tion ngx_start_worker_processes. Once the mas- flag OPENSSL_NO_BUF_FREELIST provided by OpenSSL ter process detects that a worker process has crashed, it to disable the use of the freelist. We obtain a Heartbleed will reap the worker process and fork a new one using attack script from [19] and set the l as 64KB, which enables ngx_reap_children. That is why all the vulnerable maximum amount of data leakage. buffers, except for in the first attack, is related to the second VCCID. HeapTherapy handles the case of multiple VCCIDs Offline patch generation. We first evaluate how smoothly by generating a patch for each unique VCCID. HeapTherapy can be used to generate a patch offline instantly, when the attack input is available. In this case Pm is set Online protection. We next evaluate how HeapTherapy as 1 and the patch generation is run on an experimental detects and defeats zero-day attacks. We set the Pm to be a system rather than a production system. The malicious request small value ranging from 0.01 to 0.15. For each value of Pm, immediately crashes the worker process of Nginx, and a we record the following measurements: (1) the detection delay

8 40 MySQL 5.5.19 contains a heap buffer over-write vulner- Nd ability that allows a remote attacker to launch denial of service 35 FP attacks using crafted database commands to over-write a heap 30 buffer and corrupt the heap meta data. The heap corruption 25 leads to a segmentation fault and crashes the MySQL service when the connection is closed. We applied HeapTherapy to 20 the service and ran the attack script [18] 20 times against 15 it. In the first run, HeapTherapy detects the attack when the Average segmentation fault is triggered. The diagnosis engine retrieves 10 the VCCID of the vulnerable buffer from the core dump file, 5 and generates a temporary patch, which is then installed to the 0 service. In all the following runs, HeapTherapy successfully 0.01 0.03 0.05 0.07 0.09 0.11 0.13 0.15 prevents data corruption from occurring. P m 3) Libtiff . Fig. 12: Heartbleed detection and diagnosis result. Libtiff is a popular library for processing TIFF im- ages. A heap buffer overflow vulnerability was found in the gif2tiff tool in libtiff 3.4-4.03. By manipulating height and width of a GIF image, a remote attacker can exploit Nd, which is the number of successful over-reads before the this vulnerability to overwrite a heap buffer. We first reproduce first guard page is touched, and (2) the average number of the exploitation using an attacking GIF image input [10]. Upon temporary patches, FP, generated in the first stage due to the detection, the diagnosis engine automatically finds the VCCID suspect buffers, as discussed in Section IV-C. in the core dump. When we use gif2tiff to open the crafted image again, the tool is able to avoid crash and reports We conduct 100 experiments for each value of Pm and “illegal GIF block type”. obtain the average values of Nd and FP, as shown in Figure 12. In all experiments, HeapTherapy successfully detects the at- 4) NIST SAMATE reference dataset . tack. When P = 0.01, N averages 28.74. As P increases to m d m The SAMATE dataset [29] maintained by NIST contains 0.04, N quickly drops to 3.7, and it does not change much d 12 programs with heap buffer overflow vulnerabilities caused when P further increases. This shows that for this particular m by contiguous writes through, for example, assignments, scenario by randomly monitoring a small set (4%) of buffers, memcpy, strcpy, and snprintf. HeapTherapy can quickly detect a zero-day Heartbleed attack. Since attackers usually need to send many Heartbleed requests In all these cases, HeapTherapy retrieves the vulnerable before achieving their goals, e.g. 100k ∼ 2.5M attacks for calling contexts accurately and uses padding to prevent both obtaining the SSL private key [13], the short detection delay data corruption and program crashes. allows HeapTherapy to detect and respond to the attacks before important information is leaked. In addition, Nd in all cases B. Efficiency on service programs is much smaller than the expected value 1/Pm, because an Heartbleed attack may access multiple buffers. We evaluate the overhead due to HeapTherapy using three real world service programs, Nginx, proftpd and MySQL. We next analyze the number of temporary patches gen- We simulate 10 VCCIDs using the method described in erated at the first stage of detection and diagnosis. When Section V-C, and set Pm as 0.05. To measure the service Pm = 0.01, FP is 39; and it decreases to around 5 when Pm throughput, we use ApacheBench to send web requests increases to 0.12. Compared with the total number of unique to Nginx, and use the official test script for MySQL; For allocation calling contexts shown in Table I and Table III proftpd, we write a script that generates concurrent clients below, FP is very small. In addition, all of these temporary to upload files, and measures the throughput. patches except one will be removed after the second stage of detection and diagnosis. We will further evaluate the overhead The result shows that HeapTherapy has a low overhead for Nginx proftpd due to temporary patches in Section V-B and Section V-C. these service programs. The overhead on , and MySQL is 7.6%, 4.7%, and 6.0%, respectively. Defense. After installing the two patches, the Heartbleed attack can only read zeros in the padding space, which is 32KB C. Efficiency on SPEC CPU2006 long and large enough to contain the over-read. We sends 10,000 Heartbleed requests to the patched Nginx service, the 1) Methodology . result shows that HeapTherapy successfully prevented infor- Benchmarks and platform. We then measure the effi- mation leakage in all attempts without crashing the service. ciency of HeapTherapy on SPEC CPU2006 Integer benchmark We then tried another three different Heartbleed attack suite with respect to speed and memory. All results presented scripts collected from the Internet, and launched all the attacks are normalized by the execution time of the original benchmark against proftpd and MySQL in addition to Nginx. In all programs without HeapTherapy. We also measure the memory the cases HeapTherapy detects the attack and prevents further overhead in terms of the average Resident Set Size (RSS) for VmRSS attacks after generating and installing the patches. all benchmark programs. We write a script to read the value of /proc/[pid]/status 50 times per second and 2) MySQL . then calculate the average.

9 Buffer Unique programs and the concern of information leakage is rare. With Benchmark allocation allocation-time regard to speed overhead, the result in Figure 13 shows that count CCID count 400.perlbench 360,728,131 13,909 HeapTherapy caused 4.3% average overhead in the case of 401.bzip2 168 10 0 patch. This shows the overhead when HeapTherapy works 403.gcc 28,458,470 913,747 in the detection status with no patch installed. The average 429.mcf 5 5 overhead increases slightly to 6.2% when the 10-VCCID set 445.gobmk 658,034 5,404 and 5-page padding are used, which demonstrates the high 456.hmmer 2,474,268 191 efficiency of HeapTherapy even when multiple vulnerabilities 458.sjeng 5 5 are handled simultaneously. 462.libquantum 179 10 464.h264ref 177,779 258 When no patch is applied, the average memory overhead 471.omnetpp 267,064,936 162,332,040 incurred by HeapTherapy is 5.9%. The overhead in the case of 473.astar 4,799,955 184 10 patches and 5 padding pages increases to 7.7%. For majority 483.xalancbmk 135,155,557 131,848,405 of the benchmark programs, the memory overhead changes TABLE III: Buffer allocation and CCID profiling. Benchmark little when the size of padding increases, mainly because a programs in bold text are allocation intensive. physical page is not mapped until the corresponding virtual memory region is accessed. We also compare HeapTherapy with DieHarder, a memory The experiments are performed on a Dell Precision allocator against heap-based attacks [30]. Figure 13 shows Workstation T5500 with 2.26GHz Intel Xeon E5507 that DieHarder incurs a much higher speed overhead for processor and 16GB RAM. The operating system is Ubuntu allocation-intensive benchmark programs. The average speed 12.04 with Linux kernel 3.2.0. performance penalty due to DieHarder is 20.3%, which is also much higher than HeapTherapy. For allocation-intensive programs, the average overhead due to DieHarder is 86.1% Vulnerability simulation. To simulate the performance while HeapTherapy only incurs 15.8% overhead on average. of HeapTherapy when handling multiple vulnerabilities, we In addition, DieHarder only provides probabilistic defense create several sets of simulated VCCIDs for each benchmark against known vulnerabilities, while HeapTherapy provides program. Specifically, we first develop a profiler to count the deterministic protection in such cases. Other comprehensive number of buffer allocations, the number of unique allocation- defense methods, such as AddressSanitizer [39], provides a time CCID values and obtain the number of buffer allocations wider range of protection than HeapTherapy. However, their associated with each unique CCID. Table III lists our profiling high overheads (e.g., 73% speed overhead and 337% memory result. From the table we can see that these benchmark overhead on SPEC 2006 for AddressSanitizer) making them programs have a diverse profile of buffer allocation. Programs, more suitable for offline testing. such as perlbench, gcc, omnetpp and xalancbmk, have intensive memory allocations. In summary, we conclude that HeapTherapy incurs a low overhead in terms of both speed and physical memory. We then generate several sets of simulated VCCIDs for later experiments. To pick the VCCIDs fairly, for each bench- VI.LIMITATIONS mark program we sort the CCIDs according to their allocation counts in descending order. Next, for each benchmark pro- First, it is possible that an overflow vulnerability can be gram we generate 3 sets of VCCIDs containing 1, 5 and 10 exploited in different VCCIDs, and the attacker may invest elements, respectively. For the 1-VCCID set, the median CCID to develop different attack input to overflow buffers in new is selected. For the 5-VCCID set, CCIDs at 0.01%, 20%, 40%, allocation calling contexts. However, as we have shown in the 60% and 80% points are chosen. The 10-VCCID set is created Nginx case, whenever the attack overflows a buffer allocated in a similar fashion with an interval of 10%. Since benchmark in a new calling context, HeapTherapy simply treats it as a programs mcf and sjeng have less than 10 unique CCIDs, new vulnerability and starts another defense and diagnosis we use all of their CCIDs for their 10-VCCID sets. cycle. Moreover, based on our evaluation and observations in previous research [50], [26], [31] on the high reproducibility 2) Overhead due to PCC Encoding . of calling contexts, this is not common. Our first evaluation was focused on the speed and memory The second limitation is that HeapTherapy can only deal overhead due to PCC encoding alone. All benchmark pro- with buffer overflow due to continual write or read operations, grams are instrumented with PCC encoding but not linked which are the main form of buffer overflows. It cannot handle with HeapTherapy, so no detection overhead is incurred. The overflows due to discrete read or write. Also, if an overflow average speed and memory overhead is 1.9% and 0.2%, occurs inside a data structure, HeapTherapy cannot detect it. respectively. The low overhead is consistent with the result This limitation is common in many existing countermeasures of the original PCC encoding on Java programs [9]. against buffer overflows. 3) HeapTherapy Efficiency . Third, although, with the current recompilation based Next, we evaluate the speed and memory overhead due implementation, users of open-source software or software to HeapTherapy using the 3 sets of VCCIDs. For each VC- companies can recompile their programs with HeapTherapy CID, a patch is created manually. Over-read detection is not to protect heap memory security, binary programs cannot turned on because these benchmark programs are not service be protected conveniently. However, recompilation is not an

10 0 patch 1 patch, 1-page padding 5 patches, 1-page padding 5 patches, 5-page padding 10 patches, 5-page padding DieHarder

1.8 1.6 1.4 1.2

1 0.8 0.6 0.4

NormalizedExecution Time 0.2 0

Fig. 13: Speed overhead due to HeapTherapy. Each bar represents one experimental setting. For example, “5 patches, 5-page padding” represents the setting where 5 simulated patches are applied based on the 5-VCCID set and each vulnerable buffer is padded with 5 pages. The guard page is enabled for all vulnerable buffers. The last bar of each group is based on the related work DieHarder.

inherent limitation of the technique covered in the paper. It does not have false positives, and remains effective under A binary-instrumentation based implementation is possible. polymorphic attacks. Our evaluation shows that it incurs a low We are building tools to build PCC encoding into programs speed and memory overhead even when dealing with multiple through binary instrumentation, while the shared library of vulnerabilities simultaneously. It does not need infrastructure HeapTherapy can be loaded through LD PRELOAD. for request recording and replaying, so HeapTherapy can be used to protect personal applications as well as enterprise VII.OTHER POTENTIAL APPLICATIONS services conveniently. The technique can be extended to deal with other heap bugs, such as immature deallocation and While the focus of this paper is the heap buffer overflow uninitialized read. problem, HeapTherapy can generate patches to deal with many other memory errors, such as double frees, dangling pointers and uninitialized heap buffer read. We can extend ACKNOWLEDGMENT the specification of the temporary patch to support more bug types, and add bug-specific predefined handling to the memory The authors would like to thank the anonymous reviewers allocation wrapper. We discuss some examples in the section. for their invaluable comments. This work was supported by ARO W911NF-09-1-0525 (MURI), NSF CNS-1223710, NSF One type of dangling pointer bugs is due to a premature CNS-1422594, and ARO W911NF-13-0421 (MURI). deallocation of some buffers. Assume the temporary patch that fixes a dangling pointer bug is generated. We can code a simple handling, which is invoked when a free call is hooked: the REFERENCES handling identifies whether the buffer’s CCID matches the VCCID in the patch; if so, the buffer’s deallocation is delayed. [1] Domain name resolution request length limit. http://tools.ietf.org/html/ Such that the pointer variable previously containing a dangling rfc1034. pointer can be dereferenced safely. [2] The pax project. https://pax.grsecurity.net/. [3] Url request length limit. http://www.checkupdown.com/status/E414. To address an uninitialized heap buffer read bug, we write html. a simple handling that zero-fills the newly allocated buffer. [4] M. Abadi, M. Budiu, U. Erlingsson, and J. Ligatti. Control-flow malloc calls the handling only when the buffer’s CCID integrity. In Proceedings of the 12th ACM Conference on Computer matches the VCCID of a patch that treats an uninitialized read and Communications Security, pages 340–353. ACM, 2005. bug. So that the effort of zero-filling is tailed to buffers where [5] P. Akritidis, C. Cadar, C. Raiciu, M. Costa, and M. Castro. Preventing an uninitialized read may occur. memory error exploits with wit. In IEEE Symposium on Security and Privacy, 2008., pages 263–277. IEEE, 2008. The memory management wrappers search in the hash table [6] P. Akritidis, M. Costa, M. Castro, and S. Hand. Baggy bounds checking: assembled with patches to determines what actions are needed, an efficient and backwards-compatible defense against out-of-bounds and then enforce them on the buffers. Therefore, HeapTherapy errors. In Proceedings of the 18th USENIX Security Symposium, pages is extensible and new handling functions and patches can be 51–66, 2009. defined to deal with new types of heap bugs. [7] E. D. Berger and B. G. Zorn. Diehard: Probabilistic memory safety for unsafe languages. In Proceedings of the Conference on Programming Language Design and Implementation, pages 158–168, 2006. VIII.CONCLUSIONS [8] E. Bhatkar, D. C. Duvarney, and R. Sekar. Address obfuscation: an We propose HeapTherapy, an end-to-end solution that per- efficient approach to combat a broad range of memory error exploits. In Proceedings of the 12th USENIX Security Symposium, pages 105– forms diagnosis and generates defenses against zero-day heap 120, 2003. buffer overflow attacks in realtime. HeapTherapy creatively [9] M. D. Bond and K. S. McKinley. Probabilistic calling context. In employs the calling context encoding to describe and identify Proceedings of the 22nd Annual ACM SIGPLAN Conference on Object- vulnerable buffers precisely and efficiently. oriented Programming Systems and Applications, pages 97–112, 2007.

11 [10] Bugzilla. Bug 2451 - CVE-2013-4243 libtiff (gif2tiff): possible heap- [33] D. K. Pradhan and N. Vaidya. Roll-forward checkpointing scheme: based buffer overflow in readgifimage(). http://bugzilla.maptools.org/ A novel fault-tolerant architecture. IEEE Transactions on Computers, show bug.cgi?id=2451. 43(10):1163–1174, 1994. [11] M. Castro, M. Costa, and T. Harris. Securing software by enforcing [34] F. Qin, J. Tucek, J. Sundaresan, and Y. Zhou. Rx: Treating bugs as data-flow integrity. In Proceedings of the 7th Symposium on Operating allergies—a safe method to survive software failures. In Proceedings Systems Design and Implementation, pages 147–160. USENIX Associ- of the Twentieth ACM Symposium on Operating Systems Principles, ation, 2006. pages 235–248, 2005. [12] W. Cheng, Q. Zhao, B. Yu, and S. Hiroshige. Tainttrace: Efficient [35] P. Ratanaworabhan, V. B. Livshits, and B. G. Zorn. Nozzle: A defense flow tracing with dynamic binary rewriting. In Proceedings of the 11th against heap-spraying code injection attacks. In Proceedings of the 18th Symposium on Computers and Communications (ISCC), pages 749–754. USENIX Security Symposium, pages 169–186, 2009. IEEE, 2006. [36] M. Rinard, C. Cadar, D. Dumitran, D. M. Roy, T. Leu, and W. S. [13] CloudFare. The results of the cloudflare challenge. https://blog. Beebee, Jr. Enhancing server availability and security through failure- cloudflare.com/the-results-of-the-cloudflare-challenge/. oblivious computing. In Proceedings of the 6th Conference on Sympo- [14] M. Costa, J. Crowcroft, M. Castro, A. Rowstron, L. Zhou, L. Zhang, sium on Opearting Systems Design & Implementation, pages 303–316, and P. Barham. Vigilante: End-to-end containment of internet worms. 2004. In Proceedings of the ACM SIGOPS Symposium on Operating Systems [37] W. K. Robertson, C. Kruegel, D. Mutz, and F. Valeur. Run-time Principles, pages 133–147, 2005. detection of heap-based overflows. In The 17th Large Installation [15] C. Cowan and C. Pu. StackGuard: automatic adaptive detection and Systems Administration Conference, volume 3, pages 51–60, 2003. prevention of buffer-overflow attacks. In Proceedings of the 7th USENIX [38] O. Ruwase and M. S. Lam. A practical dynamic buffer overflow Security Symposium, pages 63–78, January 1998. detector. In Proceedings of the 12th Symposium on Network and [16] B. Cox, D. Evans, A. Filipi, J. Rowanhill, W. Hu, J. Davidson, J. Knight, Distributed System Security, pages 159–169, 2004. A. Nguyen-Tuong, and J. Hiser. N-variant systems: a secretless [39] K. Serebryany, D. Bruening, A. Potapenko, and D. Vyukov. Address- framework for security through diversity. In Proceedings of the 15th sanitizer: A fast address sanity checker. In USENIX Annual Technical USENIX Security Symposium, volume 6, pages 105–120, 2006. Conference, pages 309–318, 2012. [17] Z. Durumeric, J. Kasten, D. Adrian, J. A. Halderman, M. Bailey, F. Li, [40] S. Sidiroglou, G. Giovanidis, and A. D. Keromytis. A dynamic N. Weaver, J. Amann, J. Beekman, M. Payer, et al. The matter of mechanism for recovering from buffer overflow attacks. In Proceedings heartbleed. In Internet Measurement Conference (IMC), pages 475– of the 8th International Conference on Information Security, pages 1– 488. ACM, 2014. 15, 2005. [18] Exploit. MySQL (Linux) Heap Based Overrun PoC Zeroday. http: [41] S. Sidiroglou, M. E. Locasto, S. W. Boyd, and A. D. Keromytis. Build- //www.exploit-db.com/exploits/23076/. ing a reactive immune system for software services. In Proceedings of the USENIX annual technical conference, pages 149–161, 2005. [19] Exploit. Openssl heartbeat poc with starttls support. https://gist.github. com/takeshixx/10107280. [42] W. N. Sumner, Y. Zheng, D. Weeratunge, and X. Zhang. Precise calling context encoding. In Proceedings of the 32nd ACM/IEEE International [20] H. H. Feng, O. M. Kolesnikov, P. Fogla, W. Lee, and W. Gong. Anomaly Conference on Software Engineering, pages 525–534, 2010. detection using call stack information. In Proceedings of the IEEE Symposium on Security and Privacy, pages 62–75, 2003. [43] Symantec. Internet security threat report. http://www.symantec.com/ security response/publications/threatreport.jsp. [21] R. W. M. Jones and P. H. J. Kelly. Backwards-compatible bounds checking for arrays and pointers in C programs. In the International [44] D. Tian, Q. Zeng, D. Wu, P. L. 0005, and C. Hu. Kruiser: Semi- Workshop on Automatic Debugging, pages 13–26, 1997. synchronized non-blocking concurrent kernel heap buffer overflow monitoring. In Proceedings of the 19th Annual Network and Distributed [22] H.-A. Kim and B. Karp. Autograph: Toward automated, distributed System Security Symposium, 2012. worm signature detection. In Proceedings of the 13th Conference on USENIX Security Symposium, 2004. [45] US-CERT. Vulnerability ranking. http://www.kb.cert.org/vuls/bymetric/. [23] V. Kiriansky, D. Bruening, and S. P. Amarasinghe. Secure execution via program shepherding. In Proceedings of the 11th USENIX Security [46] D. Wagner and D. Dean. Intrusion detection via static analysis. In Symposium, volume 92, 2002. IEEE Symposium on Security and Privacy, pages 156–168, 2001. [24] Launchpad.net. Heap overflow when parsing malformed URLs. https: [47] D. Wagner, J. S. Foster, E. A. Brewer, and A. Aiken. A first step towards //bugs.launchpad.net/ubuntu/+source/lynx-cur/+bug/613254. automated detection of buffer overrun vulnerabilities. In In Proceedings of Network and Distributed System Security Symposium, pages 3–17. [25] N. Nethercote and J. Seward. Valgrind: a framework for heavyweight dynamic binary instrumentation. In Proceedings of the ACM SIGPLAN [48] J. Wang, M. Zhao, Z. Qiang, D. Wu, and P. Liu. Risk assessment Conference on Programming Language Design and Implementation, of buffer “heartbleed” over-read vulnerabilities (practical experience pages 89–100, 2007. report). In 45th Annual IEEE/IFIP International Conference on De- pendable Systems and Networks (DSN). IEEE, 2015. [26] J. Newsome, D. Brumley, and D. Song. Vulnerability-specific execution filtering for exploit prevention on commodity software. In Proceedings [49] J. Xu, Z. Kalbarczyk, and R. K. Iyer. Transparent runtime randomization of the 13th Symposium on Network and Distributed System Security, for security. In Proceedings of 22nd International Symposium on 2005. Reliable Distributed Systems, pages 260–269, 2003. [27] J. Newsome and D. Song. Dynamic taint analysis for automatic [50] J. Xu, P. Ning, C. Kil, Y. Zhai, and C. Bookholt. Automatic diagnosis detection, analysis, and signature generation of exploits on commodity and response to memory corruption vulnerabilities. In Proceedings of software. In Proceedings of Network and Distributed System Security the 12th ACM Conference on Computer and Communications Security, Symposium, 2005. pages 223–234, 2005. [28] NIST. CVE-2014-0160. http://web.nvd.nist.gov/view/vuln/detail? [51] Q. Zeng, J. Rhee, H. Zhang, N. Arora, G. Jiang, and P. Liu. DeltaPath: vulnId=CVE-2014-0160. Precise and Scalable Calling Context Encoding. In Symposium on Code Generation and Optimization, 2014. [29] NIST. SAMATE Reference Dataset. http://samate.nist.gov/SRD. [52] Q. Zeng, D. Wu, and P. Liu. Cruiser: concurrent heap buffer overflow [30] G. Novark and E. D. Berger. Dieharder: securing the heap. In Proceed- monitoring using lock-free data structures. In Proceedings of the ings of the 17th ACM Conference on Computer and Communications 32nd ACM SIGPLAN conference on Programming language design and Security, pages 573–584. ACM, 2010. implementation, pages 367–377, 2011. [31] G. Novark, E. D. Berger, and B. G. Zorn. Exterminator: Automatically [53] B. Zorn and M. Seidl. Segregating heap objects by reference behavior correcting memory errors with high probability. In Proceedings of the and lifetime. In Eighth International Conference on Architectural Programming Language Design and Implementation, 2007. Support for Programming Languages and Operating Systems, pages [32] B. Perens. efence(3) - Linux man page. http://linux.die.net/man/3/ 12–23, 1998. efence.