Automated Security Debugging Using Program Structural Constraints Chongkyung Kil ∗ , Emre Can Sezer ∗ , Peng Ning ∗ , and Xiaolan Zhang † Department of Computer Science ∗ IBM T. J. Watson Research Center † North Carolina State University {ckil, esezer, pning}@ncsu.edu cxzhang@us.ibm.com Abstract Understanding security bugs in a vulnerable program is a non-trivial task, even if the target program is known to be vulnerable. Though there exist debugging tools that fa- cilitate the vulnerability analysis and debugging process, human developers still need to manually trace the pro- gram execution most of the times. This makes security debugging a difficult and tiresome task even for experi- enced programmers. In this paper, we present the devel- opment of a novel security debugging tool called CBones (SeeBones, where bones is an analogy of program struc- tures). CBones is intended to fully automate the analysis of a class of security vulnerabilities in C programs, the ex- ploits of which would compromise the integrity of program structures satisfied by all legitimate binaries compiled from C source code. In other words, CBones automatically dis- covers how unknown vulnerabilities in C programs are ex- ploited based on program structural constraints. Unlike the previous approaches, CBones can automatically identify ex- ploit points of unknown security bugs without requiring a training phase, source code access (analysis or instrumen- tation), or additional hardware supports. To validate the effectiveness of this approach, we evaluate CBones with 12 real-world applications that contain a wide range of vul- nerabilities. Our results show that CBones can discover all security bugs with no false alarms, pinpoint the corrupting instructions, and provide information to facilitate the un- derstanding of how an attack exploits a security bug. 1 Introduction Understanding security bugs in a vulnerable program is a non-trivial task, even if the target program is known to be vulnerable. Though there are existing debugging tools (e.g., gdb, Purify [21]) to facilitate the vulnerability analy- sis and debugging process, human developers still need to manually trace the program execution most of times. This makes security debugging a difficult and tiresome task even for experienced programmers. A critical step in the security debugging process is the analysis that recognizes the vulnerable point in a program and identifies the cause of the bug. A major challenge in this analysis process is to identify how unknown vulnera- bilities can be exploited, since these vulnerabilities are often short-lived during the exploit process and thus are difficult to trace. Static analysis techniques (e.g., [24–26]) have been proposed to discover vulnerabilities in a program via source code analysis (e.g., model checking). However, such meth- ods are mainly focused on known vulnerabilities and often require human interventions to write assertions or specifi- cations. In addition, some require access to source code, which is not always available (e.g., commodity software). Runtime checking methods (e.g., [10, 21–23]) have also been studied to detect security bugs dynamically by check- ing legitimate memory accesses, inserting canary values, or using additional hardware support. These approaches, how- ever, still mostly focus on existing vulnerabilities and suf- fer from non-negligible false alarms and performance over- head. A few approaches have been investigated recently to dis- cover security bugs using statistical program invariants [11– 13]. These approaches detect bugs by identifying deviations from program invariants statistically derived during normal program executions. DAIKON [12] and DIDUCE [13] au- tomatically extract likely program invariants among vari- ables through multiple normal program executions in the training phase, and use the violations of such invariants to detect security bugs at analysis time. AccMon [11] intro- duced Program Counter (PC)-based invariant detection (i.e., a memory object is typically accessed only by a small set of instructions), and detects security bugs when memory ob- jects are accessed by instructions not observed during nor- mal program executions in the training phase. These approaches extended the capability of analyzing unknown security bugs. However, they still suffer from several limitations. In particular, all these approaches re- quire a training phase during normal program executions to derive the program invariants, which offers no guaran- tee in generating all program invariants. Moreover, each of 1