1 Security Vulnerability Analysis and Mitigation for Real-World Systems Shuo Chen Center for Reliable and High-Performance Computing Coordinated Science Laboratory University of Illinois at Urbana-Champaign Final Exam, August 18 th, 2005 Committee Chair: Prof. Ravi Iyer Committee: Prof. Vikram Adve Committee: Prof. Vikram Adve Prof. Ravi Iyer Prof. Jose Meseguer Prof. David Nicol Prof. Ravi Iyer Prof. Jose Meseguer Prof. David Nicol

2 Analyzed security vulnerability reports in Bugtraq and CERT advisories Analyzed security vulnerability reports in Bugtraq and CERT advisories Most vulnerabilities can be modeled as a series of simple logic predicates. Most vulnerabilities can be modeled as a series of simple logic predicates. Used FSM models to reason about many categories of vulnerabilities. Used FSM models to reason about many categories of vulnerabilities. A common characteristic of most security vulnerabilities: pointer taintedness A common characteristic of most security vulnerabilities: pointer taintedness Pointer value derived from user input Pointer value derived from user input Allow users to specify memory addresses. Usually due to attacks! Allow users to specify memory addresses. Usually due to attacks! Developed a theorem proving approach to reason about possibility of pointer taintedness Developed a theorem proving approach to reason about possibility of pointer taintedness To uncover potential vulnerabilities. To uncover potential vulnerabilities. Prelim Exam Recap

3 Since Prelim Exam Questions focused Questions focused Is pointer taintedness detection just an alternative approach to existing defense techniques, or is it a significant improvement? Is pointer taintedness detection just an alternative approach to existing defense techniques, or is it a significant improvement? Is pointer taintedness detection applicable to large real-world software? Is pointer taintedness detection applicable to large real-world software?

4 Since Prelim Exam (cont.) Contributions Contributions Demonstrate that a new security attack – non- control-data attack, is applicable to many real-world software, not addressed by many current defense techniques. Demonstrate that a new security attack – non- control-data attack, is applicable to many real-world software, not addressed by many current defense techniques. Demonstrate that pointer taintedness detection can naturally defeat non-control-data attacks as well as traditional attacks. Demonstrate that pointer taintedness detection can naturally defeat non-control-data attacks as well as traditional attacks. Demonstrate that pointer taintedness detection can be deployed in large systems. Demonstrate that pointer taintedness detection can be deployed in large systems. By building into processor architecture By building into processor architecture By combining theorem proving and runtime assertions By combining theorem proving and runtime assertions

5 Summary of My Research Start from the analysis of a large volume of security data Start from the analysis of a large volume of security data Extract common characteristics of security vulnerabilities and attacks Extract common characteristics of security vulnerabilities and attacks Propose new defense techniques (supported by real-world attack models) Propose new defense techniques (supported by real-world attack models)

6 Publications S. Chen, J. Xu, E. C. Sezer, P. Gauriar and R. K. Iyer. "Non-Control-Data Attacks Are Realistic Threats," USENIX Security Symposium, S. Chen, J. Xu, E. C. Sezer, P. Gauriar and R. K. Iyer. "Non-Control-Data Attacks Are Realistic Threats," USENIX Security Symposium, S. Chen, J. Xu, N. Nakka, Z. Kalbarczyk, R. K. Iyer. “Defeating Memory Corruption Attacks via Pointer Taintedness Detection,” DSN, S. Chen, J. Xu, N. Nakka, Z. Kalbarczyk, R. K. Iyer. “Defeating Memory Corruption Attacks via Pointer Taintedness Detection,” DSN, S. Chen, J. Dunagan, C. Verbowski and Y.-M. Wang, “A Black-Box Tracing Technique to Identify Causes of Least-Privilege Incompatibilities,” NDSS, S. Chen, J. Dunagan, C. Verbowski and Y.-M. Wang, “A Black-Box Tracing Technique to Identify Causes of Least-Privilege Incompatibilities,” NDSS, S. Chen, J. Xu, Z. Kalbarczyk, R. K. Iyer. “Security Vulnerabilities: From Analysis to Detection and Masking Techniques,” Proceedings of the IEEE, S. Chen, J. Xu, Z. Kalbarczyk, R. K. Iyer. “Security Vulnerabilities: From Analysis to Detection and Masking Techniques,” Proceedings of the IEEE, S. Chen, K. Pattabiraman, Z. Kalbarczyk, R. K. Iyer, "Formal Reasoning of Various Categories of Widely Exploited Security Vulnerabilities Using Pointer Taintedness Semantics," IFIP SEC, 2004 S. Chen, K. Pattabiraman, Z. Kalbarczyk, R. K. Iyer, "Formal Reasoning of Various Categories of Widely Exploited Security Vulnerabilities Using Pointer Taintedness Semantics," IFIP SEC, 2004 S. Chen, J. Xu, Z. Kalbarczyk, R. K. Iyer and K. Whisnant. “Modeling and Evaluating the Security Threats of Transient Errors in Firewall Software,” Performance Evaluation, S. Chen, J. Xu, Z. Kalbarczyk, R. K. Iyer and K. Whisnant. “Modeling and Evaluating the Security Threats of Transient Errors in Firewall Software,” Performance Evaluation, S. Chen, Z. Kalbarczyk, J. Xu, R. K. Iyer. "A Data-Driven Finite State Machine Model for Analyzing Security Vulnerabilities," DSN, S. Chen, Z. Kalbarczyk, J. Xu, R. K. Iyer. "A Data-Driven Finite State Machine Model for Analyzing Security Vulnerabilities," DSN, S. Chen, J. Xu, R. K. Iyer, K. Whisnant. "Modeling and Analyzing the Security Threat of Firewall Data Corruption Caused by Instruction Transient Errors," DSN, S. Chen, J. Xu, R. K. Iyer, K. Whisnant. "Modeling and Analyzing the Security Threat of Firewall Data Corruption Caused by Instruction Transient Errors," DSN, J. Xu, S. Chen, Z. Kalbarczyk, R. K. Iyer. "An Experimental Study of Security Vulnerabilities Caused by Errors," DSN, J. Xu, S. Chen, Z. Kalbarczyk, R. K. Iyer. "An Experimental Study of Security Vulnerabilities Caused by Errors," DSN, full papers in IEEE DSN, USENIX Security, IFIP Security, ISOC NDSS, Proceedings of IEEE and Journal of Performance Evaluation

7 Non-Control-Data Attacks Are Realistic Threats (Joint work with Jun Xu) In USENIX Security Symposium, 2005

8 Control Data Attack: Well-Known, Dominant Control data attack: corrupt function pointers, jump targets and return addresses to run malicious code Control data attack: corrupt function pointers, jump targets and return addresses to run malicious code Currently the most dominant form of memory corruption attacks [CERT and Microsoft Security Bulletin] Currently the most dominant form of memory corruption attacks [CERT and Microsoft Security Bulletin] By exploiting many vulnerabilities such as buffer overflow, format string bug, integer overflow, double free, etc. By exploiting many vulnerabilities such as buffer overflow, format string bug, integer overflow, double free, etc. Many current defense techniques: to enforce control data integrity to provide security. Many current defense techniques: to enforce control data integrity to provide security. Monitor system call sequences (Intrusion detection systems) Monitor system call sequences (Intrusion detection systems) Protect control data (Secure Program Execution, Minos) Protect control data (Secure Program Execution, Minos) Non-executable stack and heap (Linux, OpenBSD, Windows XP SP2) Non-executable stack and heap (Linux, OpenBSD, Windows XP SP2)

9 Non-Control-Data Attack Non-control-data attacks: attacks not corrupting any control flow data Non-control-data attacks: attacks not corrupting any control flow data Currently very rare in reality Currently very rare in reality Very few instances documented in literature. Very few instances documented in literature. Several papers: possible to construct non-control-data attack against synthetic programs. Several papers: possible to construct non-control-data attack against synthetic programs. Not yet considered as a serious threat Not yet considered as a serious threat How applicable are such attacks against real-world software? How applicable are such attacks against real-world software? Why rare  attackers’ incapability or lack of incentives? Why rare  attackers’ incapability or lack of incentives? No focused investigation yet. No focused investigation yet.

10 Our Claim: General Applicability of Non-Control-Data Attacks The claim: The claim: Many real-world software applications are susceptible to non- control-data attacks. Many real-world software applications are susceptible to non- control-data attacks. The severity of the attack consequence is equivalent to that due to control data attacks. The severity of the attack consequence is equivalent to that due to control data attacks. Goal of our project Goal of our project Experimentally validate the claim Experimentally validate the claim Construct non-control-data attacks to compromise the security of widely-used applications Construct non-control-data attacks to compromise the security of widely-used applications Discuss limitations of current defense techniques Discuss limitations of current defense techniques Show that pointer taintedness detection can defeat both control- data attacks and non-control-data attacks. Show that pointer taintedness detection can defeat both control- data attacks and non-control-data attacks.

11 Non-Control-Data Attack against WU-FTP Server (via a format string bug) int x; FTP_service(...) { authenticate(); x = user ID of the authenticated user; seteuid(x); while (1) { get_FTP_command(...); if (a data command?) getdatasock(...); } getdatasock(... ) { seteuid(0); setsockopt(... ); seteuid(x); } x=109, run as EUID 0 x uninitialized, run as EUID 0 x=109, run as EUID 109. Lose the root privilege! x=0, run as EUID 0 When return to service loop, still runs as EUID 0 (root). Allow me to upload /etc/passwd I can grant myself the root privilege! Only corrupt an integer, not a control data attack. Get a data command (e.g., PUT) Get a special SITE EXEC command. Exploit a format string vulnerability. x= 0, still run as EUID 109.

12 /usr/local/httpd/exe Non-Control-Data Attack against NULL-HTTP Server (via a heap overflow bug) Attack the configuration string of CGI-BIN path. Attack the configuration string of CGI-BIN path. Mechanism of CGI Mechanism of CGI suppose server name = CGI-BIN = suppose server name = CGI-BIN = Requested URL = Requested URL = The server executes The server executes Our attack Our attack Exploit the vulnerability to overwrite CGI-BIN to /bin Exploit the vulnerability to overwrite CGI-BIN to /bin Request URL Request URL The server executes The server executes The server gives me a root shell! Only overwrite four characters in the CGI-BIN string. /usr/local/httpd/exe /bin /sh /bar /bar

13 Non-Control-Data Attack against SSH Communications SSH Server (via an integer overflow bug) void do_authentication(char *user,...) { int auth = 0;... while (!auth) { /* Get a packet from the client */ type = packet_read(); switch (type) {... case SSH_CMSG_AUTH_PASSWORD: if (auth_password(user, password)) auth =1; case... } if (auth) break; } /* Perform session preparation. */ do_authenticated(…); } auth = 0 Password incorrect, but auth = 1 auth = 1 Logged in without correct password auth = 1

14 More Non-Control-Data Attacks Against NetKit Telnet server (default Telnet server of Redhat Linux) Against NetKit Telnet server (default Telnet server of Redhat Linux) Exploit a heap overflow bug Exploit a heap overflow bug Overwrite two strings: /bin/login –h foo.com -p (normal scenario) /bin/sh –h –p -p (attack scenario) Overwrite two strings: /bin/login –h foo.com -p (normal scenario) /bin/sh –h –p -p (attack scenario) The server runs /bin/sh when it tries to authenticate the user. The server runs /bin/sh when it tries to authenticate the user. Against GazTek HTTP server Against GazTek HTTP server Exploit a stack buffer overflow bug Exploit a stack buffer overflow bug Send a legitimate URL Send a legitimate URL The server checks that “/..” is not embedded in the URL The server checks that “/..” is not embedded in the URL Exploit the bug to change the URL to Exploit the bug to change the URL to The server executes /bin/sh The server executes /bin/sh

15 What Non-Control-Data Attacks Imply? Control data integrity is not sufficient to ensure software security for real-world software. Control data integrity is not sufficient to ensure software security for real-world software. Many types of non-control data critical to security Many types of non-control data critical to security User identity data, configuration data, user input text string and decision-making Boolean User identity data, configuration data, user input text string and decision-making Boolean Once attackers have the incentive, they are likely to succeed in non-control-data attacks. Once attackers have the incentive, they are likely to succeed in non-control-data attacks.

16 Runtime Pointer Taintedness Detection at Processor Level Joint work with Jun Xu and Nithin Nakka In IEEE International Conference on Dependable Systems and Networks (DSN), 2005

17 Recap: Pointer Taintedness The root cause of many memory corruption attacks: pointer taintedness The root cause of many memory corruption attacks: pointer taintedness No matter whether they overwrite control-data or non- control-data No matter whether they overwrite control-data or non- control-data Many type of vulnerabilities: e.g., buffer overflow, format string, heap corruption, integer overflow, and globbing attacks. Many type of vulnerabilities: e.g., buffer overflow, format string, heap corruption, integer overflow, and globbing attacks. Pointer taintedness: a pointer value is derived from user input Pointer taintedness: a pointer value is derived from user input In prelim, I showed a theorem proving technique to reason about possibility of pointer taintedness In prelim, I showed a theorem proving technique to reason about possibility of pointer taintedness

18 ap: argument pointer fmt: format string pointer Is a Format String Attack Due to Pointer Taintedness? In vfprintf(), if (fmt points to “%n”) then **ap = (character count) Vulnerable code: recv(socket,filename); sprintf(buf,”%s not found”,filename); printf(buf); /* should be printf(“%s”,buf) */ Suppose user ID, CGI-BIN or critical flag in 0x1002bc20 \x20 \xbc \x02 \x10 %d %d %d %n …%n%d%d%d0x1002bc20 fmt: format string pointer ap: argument pointer High Low Stack growth *ap is the tainted value 0x1002bc20.

19 Runtime Pointer Taintedness Detection A processor architectural level mechanism to detect pointer taintedness A processor architectural level mechanism to detect pointer taintedness On SimpleScalar processor simulator On SimpleScalar processor simulator Implemented a taintedness-aware memory system Implemented a taintedness-aware memory system One-bit extension for each byte, similar to the parity bit, to indicate the taintedness of this byte One-bit extension for each byte, similar to the parity bit, to indicate the taintedness of this byte Taintedness tracking Taintedness tracking Taintedness is propagated by ALU instructions Taintedness is propagated by ALU instructions Taintedness initialization Taintedness initialization read and recv system calls: tag every byte of receiving buffer as tainted read and recv system calls: tag every byte of receiving buffer as tainted Attack detection Attack detection When a tainted value is dereferenced (i.e., used as a pointer). When a tainted value is dereferenced (i.e., used as a pointer).

20 ALU taintedness tracking logic Register File 4 bits 32 bits ALUALU Bitwise OR 32 bits36 bits 4 bits MUXMUX MUXMUX 36 bits Data Memory 36 bits MUXMUX ID/EX EX/MEM MEM/WB MUX Opcode Compare specific logic Shift specific logic XOR specific logic MUXMUX 0 alert jr? MUX 4 bits 0 alert load/ store? Jump pointer taintedness detector Data pointer taintedness detector 8-bit byte Taintedness bit 36 bits store path load path AND specific logic

21 Evaluation Effectiveness of attack detection Effectiveness of attack detection Synthetic vulnerable programs Synthetic vulnerable programs Real-world network applications Real-world network applications Evaluation of false positives Evaluation of false positives Real-world network applications Real-world network applications SPEC 2000 benchmarks SPEC 2000 benchmarks Potential false negative scenarios Potential false negative scenarios A few attack scenarios that are not detected A few attack scenarios that are not detected

22 Effectiveness of Attack Detection First, test on synthetic vulnerable programs First, test on synthetic vulnerable programs All attacks are detected and terminated All attacks are detected and terminated Stack Buffer Overflow Heap Corruption Attack Format String Attack Vulnerable program void exp1() { char buf[10]; char buf[10]; scanf("%s",buf); scanf("%s",buf);} void exp2() { char * buf; char * buf; buf = malloc(8); buf = malloc(8); scanf("%s",buffer); scanf("%s",buffer); free(p); free(p);} void exp3(int s) { char buf[100]; char buf[100]; recv(s,buf,100,0); recv(s,buf,100,0); printf(buf); printf(buf);} Input data aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaabcd%x%x%x%n Violating instruction 400a38: JR $31 401dc0: LW $3,0($3) 402d60: SW $21,0($3) Tainted data $31= 0x $3 = 0x $3=0x

23 Attack Detection Effectiveness (cont.) Test on real network applications Test on real network applications All attacks are detected All attacks are detected No difference between control-data attack and non-control-data attack from the viewpoint of pointer taintedness No difference between control-data attack and non-control-data attack from the viewpoint of pointer taintedness WU-FTP server Format string attack Overwrite user ID (non-control-data)detected GazTek HTTP server Stack buffer overflow attack Overwrite user input data (non-control-data)detected NULL HTTP server Heap corruption attack Overwrite CGI-BIN config (non-control-data)detected traceroute Double free Function pointer (control-data)detected

24 Evaluation of Transparency and False Positives Transparent: precompiled binary executables can run Transparent: precompiled binary executables can run Test on network applications Test on network applications No attack  no alert No attack  no alert Test on SPEC benchmarks Test on SPEC benchmarks Execute 15,139 million instructions without any alert Execute 15,139 million instructions without any alert Conclusion: No known false positive Conclusion: No known false positive BZIP2GCCGZIPMCFPARSERVPRTotal Program size 321KB4184KB485KB304KB595KB697KB6586KB Total number of input bytes 1048KB77.7K282KB39.2KB743.0KB6.4KB2186KB Total number of instructions 5,951M110M6,926M1,653M389M108M15,139M Alert generated? NoNoNoNoNoNoNo

25 Potential False Negative Scenarios Incorrect array index boundary check Incorrect array index boundary check Determining correct array size requires source code analysis – very hard at binary level Determining correct array size requires source code analysis – very hard at binary level Buffer overflow within the local frame Buffer overflow within the local frame If no pointer is tainted, no alert is raised If no pointer is tainted, no alert is raised Unlikely to cause severe security damage because attacker-controllable location is very limited Unlikely to cause severe security damage because attacker-controllable location is very limited Format string attack causing information leak Format string attack causing information leak This attack allows peeking a few words on the top of the stack. This attack allows peeking a few words on the top of the stack. Cause security compromises if these words contain security-critical secret, e.g., key and password Cause security compromises if these words contain security-critical secret, e.g., key and password

26 Combining Static Analysis and Runtime Detection

27 Towards An Easier Deployment of Pointer Taintedness Detection Advantage/limitation of static analysis Advantage/limitation of static analysis to derive assertions (when satisfied, eliminate pointer taintedness) to derive assertions (when satisfied, eliminate pointer taintedness) No need for hardware modification, but not easy to deploy in large programs No need for hardware modification, but not easy to deploy in large programs Advantage/limitation of runtime detection Advantage/limitation of runtime detection Easy to deploy in large programs, but needs modification of the processor Easy to deploy in large programs, but needs modification of the processor Can we combine the two? Can we combine the two? Static analysis to extract security specifications of critical functions Static analysis to extract security specifications of critical functions Enforce these specifications by runtime assertions Enforce these specifications by runtime assertions Purely a software approach (of course, we can also design hardware to enforce runtime assertions) Purely a software approach (of course, we can also design hardware to enforce runtime assertions)

28 Verification Condition (VC) Generation char *p, *q; if (a == 1) p = *p + 10; q = p - 2; *q = 12; 1: branch (~(a is 1)) 3 2: mov [p] <- ^p + 1 3: mov [q] <- ^p - 2 4: mov [^q] <- 12 compile 1: branch (~(^a is 1)) go 3 2: mov [p] <- ^^p : mov [q] <- ^p - 2 4: mov [^q] <- 12 VC(4): T(^q)=false VC(3): T(^p)=false VC(2): T(^^p)=false VC(1): the specification (^a=1 => T(^^p)= false)  (^a≠1 => T(^p)= false)

29 Case Study: free() typedef struct _HEAP_BLOCK { int Size; int Busy; struct _HEAP_BLOCK * Fwd,* Bak; } HEAP_BLOCK, * PHEAP_BLOCK; char * BlockSizes; void free(char * p) { int BlockSize,i; char * BuddyBlock,* FreedBlock; int FreeBlockListIndex,MergeExit; FreedBlock=p-sizeof(HEAP_BLOCK); // Mark this block free. FreedBlock->Busy=0; BlockSize=FreedBlock->Size; FreeBlockListIndex = CalculateFreeBlockListIndex(BlockSize); FreeBlockListIndex=0; while (BlockSize > *(BlockSizes+FreeBlockListIndex)) { BlockSize = BlockSize / 2; FreeBlockListIndex++; } MergeExit=0; while (FreeBlockListIndex < 6 && MergeExit==0) { BuddyBlock = HEAP_BASE + (FreedBlock- HEAP_BASE) ^ BlockSize; if (BuddyBlock->Busy || BuddyBlock->Size != BlockSize) MergeExit=1; else { // Make a bigger block and free it. BlockSize*=2; FreeBlockListIndex++; if (BuddyBlock<FreedBlock) FreedBlock = BuddyBlock; BuddyBlock->Fwd->Bak=BuddyBlock->Bak; BuddyBlock->Bak->Fwd=BuddyBlock->Fwd; } FreedBlock->Size = BlockSize; \ FreedBlock->Busy = 0; InsertTailList(FreeBlockListIndex, FreedBlock); } inst(1) = mov [FreedBlock] <- (^ p - 16). inst(2) = mov [^ FreedBlock + 4] <- 0. inst(3) = mov [BlockSize] <- ^ ((^ FreedBlock + 0)). inst(4) = mov [FreeBlockListIndex] <- 0. inst(5) = no-op. inst(6) = branch (~(^ ((^ BlockSizes + ^ FreeBlockListIndex)) < ^ BlockSize)) 10. inst(7) = mov [BlockSize] <- (^ BlockSize / 2). inst(8) = mov [FreeBlockListIndex] <- (^ FreeBlockListIndex) + 1. inst(9) = branch true 5. inst(10) = no-op. inst(11) = mov [MergeExit] <- 0. inst(12) = no-op. inst(13) = branch (~(^ FreeBlockListIndex < 6 && ^ MergeExit is 0)) 28. inst(14) = mov [BuddyBlock] <- ((HEAP_BASE + ((((^ FreedBlock - HEAP_BASE)) xor ^ BlockSize)))). inst(15) = branch (~(~(^ ((^ BuddyBlock + 4)) is 0) || ~(^ ((^ BuddyBlock + 0)) is ^ BlockSize))) 18. inst(16) = mov [MergeExit] <- 1. inst(17) = branch true 26. inst(18) = no-op. inst(19) = mov [BlockSize] <- 2. inst(20) = mov [FreeBlockListIndex] <- (^ FreeBlockListIndex) + 1. inst(21) = branch (~(^ BuddyBlock < ^ FreedBlock)) 23. inst(22) = mov [FreedBlock] <- ^ BuddyBlock. inst(23) = no-op. inst(24) = mov [^(^ BuddyBlock + 8) + 12] <- ^ (^ BuddyBlock + 12). inst(25) = mov [^(^ BuddyBlock + 12) + 8] <- ^ (^ BuddyBlock + 8). inst(26) = no-op. inst(27) = branch true 12. inst(28) = no-op. inst(29) = mov [^ FreedBlock + 0] <- ^ BlockSize. inst(30) = mov [^ FreedBlock + 4] <- 0. inst(31) = no-op. Compile VC generation VC(1): T (^ p) = false  T (^ (^ x + 8)) = false  T (^ (^ x + 12)) = false x = (((p-16) - HEAP_BASE) xor ^(p-16)) + HEAP_BASE

30 Case Study: free() (cont.) Runtime enforcement of VC using a runtime assertion Runtime enforcement of VC using a runtime assertion void free(char * p) { HEAP_BLOCK * x=(HEAP_BLOCK*) (HEAP_BASE + (((p-16) - HEAP_BASE) ^ (*(UINT*)(p-16)))); assert (x->Fwd->Bak == x && x->Bak->Fwd == x); … … … … ( the original source code of free() ) } Effectiveness Effectiveness /* try to hijack *f() to buffer p */ int main() { char * p; void (*f)(); p = malloc(40); *(UINT*)(p+60)=(UINT)p; *(UINT*)(p+56)=((UINT)&f)-12; free(p); } Heap corruption attack. Assertion is violated!

31 Case Study: vfprintf() int vfprintf (char *s, char *format, char * ap) { char * p, *q; int done,state,data,n; char buf[10]; p=format; done=0; if (p==0) return 0; state=1; while (*p != 0) { if (state==1) { if (*p==’%’) state=0; else done++; } else { if (*p==’%’) { done++; } else if (*p==’d’) { data=*ap; if (data<0) { done++; data=-data; } n=0; while (data>0 && n<10) { *(&buf+n)=data%10+’0’; data/=10; n++; } while (n>0) { n--; done++; } else if (*p==’s’) { q=*ap; if (q==0) break; while (*q!=0) { done++; q++; } else if (*p==’n’) { q = *ap; *(int *) q = done; done++; } else { done++; } state=1; } p++; } return done; }

32 Case Study: vfprintf() (cont.) VC(8) = (~ (^ state = 1) && ^ ^ p = ‘n’) -> (T(^ ap) = false) Extracted VC Extracted VC int vfpintf (FILE *s, const char *format, va_list ap) { … while (*p != 0) { assert (!(state != 1 && *p==‘n’ && !UNTAINTED(ap))); } int printf (const char *format,...) { return vfprintf (stdout, format, arg); } Runtime enforcement of VC using a runtime assertion Runtime enforcement of VC using a runtime assertion void main() { mov %esp, stack_top; ADD_UNTAINTED_ADDR (stack_top-4); printf("string=%s\ni=%d\n%n",buf,i,&j); REMOVE_UNTAINTED_ADDR (stack_top-4); scanf(“%s”,buf); printf(buf); } Legitimate call. Assertion holds Format string attack. Assertion is violated

33 Conclusions

34 Conclusions Most security vulnerabilities (in Bugtraq and CERT) can be modeled as a series of violations of logic predicates Most security vulnerabilities (in Bugtraq and CERT) can be modeled as a series of violations of logic predicates Promising to apply formal method to analyze software security (shown in prelim exam) Promising to apply formal method to analyze software security (shown in prelim exam) Many real-world software can be compromised by corrupting non- control data. Many real-world software can be compromised by corrupting non- control data. Need a more comprehensive defense technique Need a more comprehensive defense technique Pointer taintedness is a unifying perspective to reason about most memory corruption vulnerabilities/attacks. Pointer taintedness is a unifying perspective to reason about most memory corruption vulnerabilities/attacks. Effective for defeating both control-data attacks and non-control-data attacks Effective for defeating both control-data attacks and non-control-data attacks Detecting about pointer taintedness is a promising direction to enhance security on real-world systems Detecting about pointer taintedness is a promising direction to enhance security on real-world systems Techniques explored: Techniques explored: theorem proving (shown in prelim exam) theorem proving (shown in prelim exam) runtime detection runtime detection combination of automatic VC generation and runtime assertion combination of automatic VC generation and runtime assertion