1. ASIACCS 2007
AutoPaG: Towards Automated Software Patch Generation with Source Code Root Cause Identification and Repair
Zhiqiang Lin 1,3
Xuxian Jiang 2, Dongyan Xu 3, Bing Mao 1, Li Xie 1
1Nanjing University
2George Mason University
3Purdue University
March 22nd, 2007

2. Agenda Motivation Design & Implementation Evaluation Related Work
Conclusion

3. Lifecycle of a vulnerability
time
I. Vulnerability Introduced
II. Vulnerability Discovered
III. Official Patch released
IV. Patch Installed
A rather lengthy process

4. Manual process is too slow
time
I. Vulnerability Introduced
II. Vulnerability Discovered
III. Official Patch released
IV. Patch Installed
28 days
/enterprise/threatreport/index.jsp 75
The time-lines of 10 recent Microsoft patches (MS to MS06-054) that are released between August and September 2006

5. Goal of AutoPaG For fast and spreading attack (e.g., zero-day) time
I. Vulnerability Introduced
II. Vulnerability Discovered
III. Official Patch released
IV. Patch Installed
time

6. I. Vulnerability Introduced
Goal of AutoPaG
For fast and spreading attack (e.g., zero-day)
Make the whole thing automated
(1) Find/Identify the root cause of the vulnerability
(2) Fix/repair it automatically
Generate temporary source code patch
(3) Facilitate official patch development
time
I. Vulnerability Introduced
II (III) (IV)

7. Overview of AutoPaG
Note: we currently focus on the out-of-bound vulnerability, the most common and severe one, but our system is also practical to other vulnerabilities, e.g, format string

8. 1. Out-of-Bound Detector (1/2)
Challenges:
Detect exploitation
Provide root cause context information
Where is the direct root cause statement?
Which variable or data is overflowed?
A toy example
The statement (source code) or instructions (binary code) which directly causes the attack or memory corruption
1 #include <string.h>
2 int main(int argc, char **argv) {
char buf[4];
char *p;
p = buf;
strcpy(p, argv[1]);
return 0;
8 }
Root Cause

9. 1. Out-of-Bound Detector (2/2)
How
Modify CCured + Call Stack
#0 0x0804b0fb in ccured_fail_str (str=0x805cc73 "Ubound", file=0x805cc12 "lib/ccuredlib.c", line=3941, function=0x805daa5 "__read_at_least_f") at lib/ccuredlib.c:909
#1 0x0804b15d in ccured_fail (msgId=3, file=0x805cc12 "lib/ccuredlib.c", line=3941, function=0x805daa5 "__read_at_least_f") at lib/ccuredlib.c:923
#2 0x0804fa0f in __read_at_least_f (ptr={_p = 0xbfaa9f90, _e = 0xbfaa9f94}, n=11) at lib/ccuredlib.c:3941
#3 0x0804fa75 in __copytags_ff (dest={_p = 0xbfaa9f90, _e = 0xbfaa9f94}, src={_p = 0xbfaabed2, _e = 0xbfaabedd}, n=11) t lib/ccuredlib.c:3947
#4 0x0804a0dc in strcpy_wrapper_sff (dest=0xbfaa9f90 "", dest_e=0xbfaa9f94, src=0xbfaabed2 "aaaaaaaaaa", src_e=0xbfaabedd) at string_wrappers.h:79
#5 0x0804a006 in main (argc=2, __argv_input=0xbfaaa014) at test.c:6
1 #include <string.h>
2 int main(int argc, char **argv) {
char buf[4];
char *p;
p = buf;
strcpy(p, argv[1]);
return 0;
8 }

10. 2. Root Cause Locator s0Set: v0Set: sSet: vSet: Challenge: How:
Find out those statements (in source code) that contribute to the computation of the overflow
Catch the transitive closure of the overflowed data
How:
Backward data dependency analysis
strcpy(p, argv[1]);
s0Set:
sSet:
vSet:
v0Set:
main:p
1 #include <string.h>
2 int main(int argc, char **argv) {
char buf[4];
char *p;
p = buf;
strcpy(p, argv[1]);
return 0;
8 }
For the root cause locator, Challenge: Find out those statements (in source code) that contribute to the computation of the overflow. Catch the transitive of the overflowed data How: Backward data dependency analysis. Also, for the given example, our algorithm work as follows: based on the information provided by detector, we know that we should examine the code from line 6, and then the algorithm begins to work. Initially, the s0Set contains the identified statement, and the v0set contains the overflowed variable. When the algorithm examines line 6, since argv[1] has a dependency to p, it adds the argv[1] to vSet, and then for line 5 p=buf, we know buf has a backward dependency to p, and then we add this statement as well as buf to the relevant set. And then it goes through to line 4, since it is a declaration statement for p, we add it..
At last, we will get the sSet as this… And only these code is related to the detected vulnerability, and should be examined by our generator.
General, powerful, large scale….
Simple
p = buf;
char *p;
char buf[4];
main:argv[1]
main:buf

11. 3. Patch Generator Attempt to automatically repair the vulnerability.
Challenges
Determining vulnerable buffer boundaries
Keep track of the meta-data with the identified variables
Fixing out-of-bound access

12. Generated Patch: An example
1 #include <string.h>
2 int main(int argc, char **argv) {
3 char (__FSEQ buf)[4];
4 char * __FSEQ p;
5 unsigned int __cil_tmp6;
6 char *__FSEQ __cil_tmp7;
7 void *p_e14;
8 void *__cil_tmp7_e15;
9 p_e14=(void*)0;
10 p=(char*) 0;
11 __cil_tmp7=buf;
12 __cil_tmp7_e15=buf+4;
13 p=__cil_tmp7;
14 __cil_tmp6 = cil_tmp7_e15 - __cil_tmp7;
15 strncpy(p, argv[1], __cil_tmp6)
16 return 0;
17}
5: p = buf;
Transform…
These piece of code is for the fixing, and meta data tracking.
And some of them are for keeping the original program semantics. E.g., p=buf.
We implement the transformation via CIL, C Intermediate Language

13. Effectiveness

14. Performance of generated patch

15. Related Work Proactive Source Transformation
FOC[Rinard04], DIRA[Smirnov & Chiueh04]
Just-In-Time Execution Filtering
TaintCheck[Newsome&Song05], DACODA[Crandall05], VSEF[Newsome&Song06], Argos[Portokalidis06] …
Reactive Runtime Patching
DYBOC[Sidiroglou & Keromytis 04], STEM[Sidiroglou & Keromytis 05]
OK, let’s examine the related work.
We divided the most related work to 3 categories.
(1) Proactive source transformation
(2) Just in time execution filtering
(3) Reactive runtime patching
For proactive source transformation, they do a heavily instrumentation and impose considerably high performance overhead (e.g., 1X-8X slowdown in FOC). They did not to investigate the vulnerability behind the attack .
For just in time execution filtering,. A number of systems have been developed in this category. AutoPaG takes a different approach from these systems .Instead of focusing on the detection and prevention of an attack at the machine instruction level, AutoPaG is more intended to automatically walk through the program source code and then identify and patch those relevant source state-ments that directly or indirectly \contribute" to the de-tected vulnerability.
For reactive runtime patching.. AutoPaG has a different goal. Instead of patching current execution during runtime to recovery from an attack, Au-toPaG focuses on the vulnerability exploited by the attack by locating those relevant source code statements and gener-ating a patch at the source code level. Note that an existing software vulnerability will ultimately require a source patch to fix it, which is the intended goal of AutoPaG.
AutoPaG generates source level patch…

16. Conclusion Towards automated source code patch generation AutoPaG
Effective
Fast
Low overhead

17. {zlin, dxu}@cs.purdue.edu
Q & A
Thank you
For more information:
{zlin,
Google: “AutoPaG”