Automatic runtime error repair and containment via recovery shepherding

Abstract

We present a system, RCV, for enabling software applications to survive divide-by-zero and null-dereference errors. RCV operates directly on off-the-shelf, production, stripped x86 binary executa-bles. RCV implements recovery shepherding, which attaches to the application process when an error occurs, repairs the execution, tracks the repair effects as the execution continues, contains the repair effects within the application process, and detaches from the process after all repair effects are flushed from the process state. RCV therefore incurs negligible overhead during the normal execution of the application. We evaluate RCV on all divide-by-zero and null-dereference errors available in the CVE database [2] from January 2011 to March 2013 that 1) provide publicly-available inputs that trigger the error which 2) we were able to use to trigger the reported error in our experimental environment. We collected a total of 18 errors in seven real world applications, Wireshark, the FreeType library , Claws Mail, LibreOffice, GIMP, the PHP interpreter, and Chromium. For 17 of the 18 errors, RCV enables the application to continue to execute to provide acceptable output and service to its users on the error-triggering inputs. For 13 of the 18 errors, the continued RCV execution eventually flushes all of the repair effects and RCV detaches to restore the application to full clean functionality. We perform a manual analysis of the source code relevant to our benchmark errors, which indicates that for 11 of the 18 errors the RCV and later patched versions produce identical or equivalent results on all inputs.

Runtime Adaptation for Actor Systems

“…No type checking is carried out on the synthesised monitors in either of these works. Runtime Adaptation through monitoring are also explored in [23,19] for C programs to attain "failure-oblivious computing" that can adapt to errors such as null-dereferencing through a technique called reverse shepherding. Again, no static analysis is performed on the monitors themselves.…”

Automatic error elimination by horizontal code transfer across multiple applications

“…(plen == 0))) { exit(-1); } Empirically, returning zero as the result of divide by zero errors often enables the application to continue to execute productively [40]. We therefore implemented an alternate strategy that returns 0 if the check fires rather than exiting.…”

“…It recompiles the application to discard out of bounds writes, manufacture values for out of bounds reads, and enable applications to continue along their normal execution paths. RCV [40] enables applications to dynamically recover from divide-by-zero and null-dereference errors. When such an error occurs, RCV attaches the application, applies a fix strategy that typically ignores the offending instruction, forces the application to continue along the normal execution path, contains the error repair effect, and detaches from the application once the repair succeeds.…”

Targeted Automatic Integer Overflow Discovery Using Goal-Directed Conditional Branch Enforcement

“…Given a the ability to automatically expose errors via tools such as DIODE and the ability to automatically repair these errors via tools such as CodePhage [37] (as well as the ability to automatically generate repairs using techniques such as ClearView [27], Error Virtualization [35,36], FailureOblivious Computing [29], and RCV [23]), the next step is to build continuous automatic improvement systems that automatically search for errors and generate patches that repair the encountered errors. ClearView's automatic patch generation capability provides continuous improvement driven by responses to attacks and errors that users encounter in production use [27].…”

“…The first two checks occur in png_get_uint_31 (line 37), which checks that the PNG height and width values are less than 0x7fffffffL. The third and fourth sanity checks occur in png_check_IHDR (lines [21][22][23][24][25][26][27][28][29][30][31][32][33][34][35][36], which check that the PNG height and width values are less than one million. The fifth and final sanity check occurs at line 72, immediately before the target memory allocation site at line 87.…”