Module: Return-oriented Programming. Professor Trent Jaeger. CSE543 - Introduction to Computer and Network Security
|
|
|
- Egbert Richards
- 5 years ago
- Views:
Transcription
1 CSE543 - Introduction to Computer and Network Security Module: Return-oriented Programming Professor Trent Jaeger 1
2 Anatomy of Control-Flow Exploits 2
3 Anatomy of Control-Flow Exploits Two steps in control-flow exploitation 2
4 Anatomy of Control-Flow Exploits Two steps in control-flow exploitation First -- attacker gets control of program flow (return address, function pointer) 2
5 Anatomy of Control-Flow Exploits Two steps in control-flow exploitation First -- attacker gets control of program flow (return address, function pointer) Stack (buffer), heap, format string vulnerability, 2
6 Anatomy of Control-Flow Exploits Two steps in control-flow exploitation First -- attacker gets control of program flow (return address, function pointer) Stack (buffer), heap, format string vulnerability, Second -- attacker uses control of program flow to launch attacks 2
7 Anatomy of Control-Flow Exploits Two steps in control-flow exploitation First -- attacker gets control of program flow (return address, function pointer) Stack (buffer), heap, format string vulnerability, Second -- attacker uses control of program flow to launch attacks E.g., Code injection 2
8 Anatomy of Control-Flow Exploits Two steps in control-flow exploitation First -- attacker gets control of program flow (return address, function pointer) Stack (buffer), heap, format string vulnerability, Second -- attacker uses control of program flow to launch attacks E.g., Code injection Adversary injects malcode into victim 2
9 Anatomy of Control-Flow Exploits Two steps in control-flow exploitation First -- attacker gets control of program flow (return address, function pointer) Stack (buffer), heap, format string vulnerability, Second -- attacker uses control of program flow to launch attacks E.g., Code injection Adversary injects malcode into victim E.g., onto stack or into other data region 2
10 Anatomy of Control-Flow Exploits Two steps in control-flow exploitation First -- attacker gets control of program flow (return address, function pointer) Stack (buffer), heap, format string vulnerability, Second -- attacker uses control of program flow to launch attacks E.g., Code injection Adversary injects malcode into victim E.g., onto stack or into other data region 2
11 Anatomy of Control-Flow Exploits Two steps in control-flow exploitation First -- attacker gets control of program flow (return address, function pointer) Stack (buffer), heap, format string vulnerability, Second -- attacker uses control of program flow to launch attacks E.g., Code injection Adversary injects malcode into victim E.g., onto stack or into other data region How is code injection done? 2
12 Code Injection 3
13 Code Injection Advantage 3
14 Code Injection Advantage Adversary can install any code they want 3
15 Code Injection Advantage Adversary can install any code they want What code do adversaries want? 3
16 Code Injection Advantage Adversary can install any code they want What code do adversaries want? Defenses 3
17 Code Injection Advantage Adversary can install any code they want What code do adversaries want? Defenses NX bit - set memory as non-executable (stack) 3
18 Code Injection Advantage Adversary can install any code they want What code do adversaries want? Defenses NX bit - set memory as non-executable (stack) W (xor) X - set memory as either writeable or executable, but not both 3
19 Code Injection Advantage Adversary can install any code they want What code do adversaries want? Defenses NX bit - set memory as non-executable (stack) W (xor) X - set memory as either writeable or executable, but not both 3
20 Code Injection Advantage Adversary can install any code they want What code do adversaries want? Defenses NX bit - set memory as non-executable (stack) W (xor) X - set memory as either writeable or executable, but not both What can adversary do to circumvent these defenses and still execute useful code (for them)? 3
21 Return-to-libc Attacks 4
22 Return-to-libc Attacks Method 4
23 Return-to-libc Attacks Method Overwrite target of indirect call/jmp target to a library routine (e.g., system) 4
24 Return-to-libc Attacks Method Overwrite target of indirect call/jmp target to a library routine (e.g., system) Return address, function pointer, 4
25 Return-to-libc Attacks Method Overwrite target of indirect call/jmp target to a library routine (e.g., system) Return address, function pointer, Advantage 4
26 Return-to-libc Attacks Method Overwrite target of indirect call/jmp target to a library routine (e.g., system) Return address, function pointer, Advantage Get useful function without code injection 4
27 Return-to-libc Attacks Method Overwrite target of indirect call/jmp target to a library routine (e.g., system) Return address, function pointer, Advantage Get useful function without code injection Defenses 4
28 Return-to-libc Attacks Method Overwrite target of indirect call/jmp target to a library routine (e.g., system) Return address, function pointer, Advantage Get useful function without code injection Defenses Remove unwanted library functions 4
29 Return-to-libc Attacks Method Overwrite target of indirect call/jmp target to a library routine (e.g., system) Return address, function pointer, Advantage Get useful function without code injection Defenses Remove unwanted library functions How to overcome this defense??? 4
30 Return-to-libc Attacks Method Overwrite target of indirect call/jmp target to a library routine (e.g., system) Return address, function pointer, Advantage Get useful function without code injection Defenses Remove unwanted library functions How to overcome this defense??? Topic of today s lecture 4
31 Return-Oriented Programming Arbitrary exploitation without code injection or whole-function reuse (return-to-libc) 5
32 Return-Oriented Programming 6
33 ROP Thesis 7
34 Return-to-libc 8
35 ROP vs return-to-libc 9
36 ROP Attacks 10
37 Machine Instructions 11
38 ROP Execution 12
39 Building ROP Functionality 13
40 Building ROP Functionality 14
41 Building ROP Functionality 15
42 Creating Programs 16
43 Finding Gadgets 17
44 ROP Conclusions 18
45 ROP Example Use ESP as program counter E.g., Store 5 at address 0x (without introducing new code) Code Stack pop %eax ret pop %ebx ret movl %eax, (%ebx) ret Registers %eax = %ebx = G1 5 jmp G2 0x jump G3... Memory 0x = Return Address buf
46 ROP Example Use ESP as program counter E.g., Store 5 at address 0x (without introducing new code) Code Stack pop %eax ret pop %ebx ret movl %eax, (%ebx) ret Registers %eax = %ebx = G1 5 jmp G2 0x jump G3... Memory 0x = Return Address buf
47 ROP Example Use ESP as program counter E.g., Store 5 at address 0x (without introducing new code) Code Stack pop %eax ret pop %ebx ret movl %eax, (%ebx) ret Registers %eax = %ebx = G1 5 jmp G2 0x jump G3... Memory 0x = Return Address buf
48 ROP Example Use ESP as program counter E.g., Store 5 at address 0x (without introducing new code) Code Stack pop %eax ret pop %ebx ret movl %eax, (%ebx) ret G1 5 jmp G2 0x jump G3 Return Address buf Registers %eax = %ebx = 5... Memory 0x =
49 ROP Example Use ESP as program counter E.g., Store 5 at address 0x (without introducing new code) Code Stack pop %eax ret pop %ebx ret movl %eax, (%ebx) ret G1 5 jmp G2 0x jump G3 Return Address buf Registers %eax = %ebx = 5... Memory 0x =
50 ROP Example Use ESP as program counter E.g., Store 5 at address 0x (without introducing new code) Code Stack pop %eax ret pop %ebx ret movl %eax, (%ebx) ret G1 5 jmp G2 0x jump G3 Return Address buf Registers %eax = %ebx = 5 0x Memory 0x =
51 ROP Example Use ESP as program counter E.g., Store 5 at address 0x (without introducing new code) Code Stack pop %eax ret pop %ebx ret movl %eax, (%ebx) ret G1 5 jmp G2 0x jump G3 Return Address buf Registers %eax = %ebx = 5 0x Memory 0x =
52 ROP Example Use ESP as program counter E.g., Store 5 at address 0x (without introducing new code) Code Stack pop %eax ret pop %ebx ret movl %eax, (%ebx) ret G1 5 jmp G2 0x jump G3 Return Address buf... Registers Memory %eax = 5 0x = 5 %ebx = 0x
53 Advanced Defenses 20
54 Advanced Defenses Control-flow attack defenses operate at two stages 20
55 Advanced Defenses Control-flow attack defenses operate at two stages Prevent attacker from getting control 20
56 Advanced Defenses Control-flow attack defenses operate at two stages Prevent attacker from getting control StackGuard, heap sanity checks, ASLR, shadow stacks,... 20
57 Advanced Defenses Control-flow attack defenses operate at two stages Prevent attacker from getting control StackGuard, heap sanity checks, ASLR, shadow stacks,... Prevent attacker from using control for malice 20
58 Advanced Defenses Control-flow attack defenses operate at two stages Prevent attacker from getting control StackGuard, heap sanity checks, ASLR, shadow stacks,... Prevent attacker from using control for malice NX, W (xor) X, ASLR, Control Flow Integrity (CFI),... 20
59 Advanced Defenses Control-flow attack defenses operate at two stages Prevent attacker from getting control StackGuard, heap sanity checks, ASLR, shadow stacks,... Prevent attacker from using control for malice NX, W (xor) X, ASLR, Control Flow Integrity (CFI),... For maximum security, a system should use a combination of these defenses 20
60 Advanced Defenses Control-flow attack defenses operate at two stages Prevent attacker from getting control StackGuard, heap sanity checks, ASLR, shadow stacks,... Prevent attacker from using control for malice NX, W (xor) X, ASLR, Control Flow Integrity (CFI),... For maximum security, a system should use a combination of these defenses Q. Is subverting control-flow the only goal of an attacker? 20
61 Control-Flow Integrity 21
62 Control-Flow Integrity Goal: Ensure that process control follows source code Adversary can only choose authorized control-flow sequences 21
63 Control-Flow Integrity Goal: Ensure that process control follows source code Adversary can only choose authorized control-flow sequences Build a model from source code that describes control flow E.g., control-flow graph 21
64 Control-Flow Integrity Goal: Ensure that process control follows source code Adversary can only choose authorized control-flow sequences Build a model from source code that describes control flow E.g., control-flow graph Enforce the model on program execution Instrument control-flow code Jumps, calls, returns,... 21
65 Control-Flow Integrity Goal: Ensure that process control follows source code Adversary can only choose authorized control-flow sequences Build a model from source code that describes control flow E.g., control-flow graph Enforce the model on program execution Instrument control-flow code Jumps, calls, returns,... Challenges Building accurate model Efficient enforcement 21
66 Software Control Flow Integrity Techniques, Proofs, & Security Applications Jay Ligatti summer 2004 intern work with: Úlfar Erlingsson and Martín Abadi 22
67 Our Mechanism F A F B call fp return 23
68 Our Mechanism F A F B call fp return CFG excerpt A call B 1 A call+1 B ret 23
69 Our Mechanism F A F B nop IMM 1 if(*fp!= nop IMM 1 ) halt call fp return CFG excerpt A call B 1 A call+1 B ret 23
70 Our Mechanism F A F B nop IMM 1 if(*fp!= nop IMM 1 ) halt call fp nop IMM 2 if(**esp!= nop IMM 2 ) halt return CFG excerpt NB: Need to ensure bit patterns for nops appear nowhere else in code memory A call A call+1 23 B 1 B ret
71 More Complex CFGs Maybe statically all we know is that F A can call any int int function F A CFG excerpt A call B 1 C 1 F B succ(a call ) = {B 1, C 1 } call fp F C 24
72 More Complex CFGs Maybe statically all we know is that F A can call any int int function F A CFG excerpt A call B 1 C 1 F B succ(a call ) = {B 1, C 1 } if(*fp!= nop IMM 1 ) halt call fp nop IMM 1 F C nop IMM 1 Construction: All targets of a computed jump must have the same destination id (IMM) in their nop instruction 24
73 Imprecise Return Information F A Q: What if F B can return to many functions? CFG excerpt A call+1 D call+1 B ret call F B F B succ(b ret ) = {A call+1, D call+1 } F D return call F B 25
74 Imprecise Return Information F A Q: What if F B can return to many functions? CFG excerpt A call+1 D call+1 B ret call F B nop IMM 2 F B succ(b ret ) = {A call+1, D call+1 } F D if(**esp!= nop IMM 2 ) halt return call F B nop IMM 2 25
75 Imprecise Return Information F A call F B nop IMM 2 Q: What if F B can return to many functions? A: Imprecise CFG F B CFG excerpt A call+1 D B ret call+1 succ(b ret ) = {A call+1, D call+1 } F D if(**esp!= nop IMM 2 ) halt return call F B nop IMM 2 25
76 Imprecise Return Information F A call F B nop IMM 2 Q: What if F B can return to many functions? A: Imprecise CFG F B CFG excerpt A call+1 D B ret call+1 succ(b ret ) = {A call+1, D call+1 } F D call F B nop IMM 2 if(**esp!= nop IMM 2 ) halt return CFG Integrity: Changes to the PC are only to valid successor PCs, per succ(). 25
77 No Zig-Zag Imprecision CFG excerpt A call B 1 E call C 1 26
78 No Zig-Zag Imprecision CFG excerpt A call B 1 E call C 1 26
79 No Zig-Zag Imprecision Solution I: Allow the imprecision CFG excerpt A call B 1 E call C 1 26
80 No Zig-Zag Imprecision Solution I: Allow the imprecision CFG excerpt A call B 1 Solution II: Duplicate code to remove zig-zags CFG excerpt A call B 1 C 1 C 1A E call E call C 1E 26
81 More Challenges 27
82 More Challenges Returns used as jumps E.g., signal handling 27
83 More Challenges Returns used as jumps E.g., signal handling Exceptions 27
84 More Challenges Returns used as jumps E.g., signal handling Exceptions Runtime generation of indirect jumps E.g., dynamic shared libraries 27
85 More Challenges Returns used as jumps E.g., signal handling Exceptions Runtime generation of indirect jumps E.g., dynamic shared libraries Indirect jumps using arithmetic operators E.g., assembly 27
86 More Challenges Returns used as jumps E.g., signal handling Exceptions Runtime generation of indirect jumps E.g., dynamic shared libraries Indirect jumps using arithmetic operators E.g., assembly Take away: CFI is a principled approach to stop control flow attacks, but challenges remain 27
87 Alternatives to CFI? 28
88 Alternatives to CFI? What are the fundamental enablers of ROP attacks? CFI: violate control flow Adversary can choose gadgets 28
89 Alternatives to CFI? What are the fundamental enablers of ROP attacks? CFI: violate control flow Adversary can choose gadgets Can we prevent adversaries from choosing useful gadgets? In general, adversaries can create/ obtain the same binary as is run by the victim But, that need not be the case 28
90 Apply Crypto to Code? 29
91 Apply Crypto to Code? Can we randomize the program s execution in such a way that an adversary cannot select gadgets? 29
92 Apply Crypto to Code? Can we randomize the program s execution in such a way that an adversary cannot select gadgets? Given a secret key and a program address space, encrypt the address space such that the probability that an adversary can locate a particular instruction (start of gadget) is sufficiently low and the program still runs correctly and efficiently 29
93 Apply Crypto to Code? Can we randomize the program s execution in such a way that an adversary cannot select gadgets? Given a secret key and a program address space, encrypt the address space such that the probability that an adversary can locate a particular instruction (start of gadget) is sufficiently low and the program still runs correctly and efficiently Called address space randomization 29
94 Prevent Injection on Stack Stack Heap 30
95 Prevent Injection on Stack One idea applied in practice Stack Heap 30
96 Prevent Injection on Stack One idea applied in practice Suppose an adversary wants to inject code onto the stack Write onto the stack (buffer overflow) Jump to that malcode (return address) Stack Heap 30
97 Prevent Injection on Stack One idea applied in practice Suppose an adversary wants to inject code onto the stack Write onto the stack (buffer overflow) Jump to that malcode (return address) Randomize the base address of the stack on each execution Prevents adversary from predicting malicious return address Stack Heap 30
98 Prevent Injection on Stack One idea applied in practice Suppose an adversary wants to inject code onto the stack Write onto the stack (buffer overflow) Jump to that malcode (return address) Randomize the base address of the stack on each execution Prevents adversary from predicting malicious return address Can we apply this idea more generally???? Stack Heap 30
99 ASLR Stack Heap Data Text 31
100 ASLR For control-flow attacks, attacker needs absolute addresses Stack Heap Data Text 31
101 ASLR For control-flow attacks, attacker needs absolute addresses Address-space Layout Randomization (ASLR) randomizes base addresses of memory segments on each invocation of the program Attacker cannot predict absolute addresses Stack Heap Data Text 31
102 ASLR For control-flow attacks, attacker needs absolute addresses Address-space Layout Randomization (ASLR) randomizes base addresses of memory segments on each invocation of the program Attacker cannot predict absolute addresses Heap, stack, data, text, mmap,...????????? Stack Heap Data??? Text 31
103 ASLR Implementations 32
104 ASLR Implementations Linux 32
105 ASLR Implementations Linux Introduced in Linux (June 2005) 32
106 ASLR Implementations Linux Introduced in Linux (June 2005) Shacham et al. [2004]:16 bits of randomization defeated by a (remote) brute force attack in minutes 32
107 ASLR Implementations Linux Introduced in Linux (June 2005) Shacham et al. [2004]:16 bits of randomization defeated by a (remote) brute force attack in minutes Reality: ASLR for text segment (PIE) is rarely used 32
108 ASLR Implementations Linux Introduced in Linux (June 2005) Shacham et al. [2004]:16 bits of randomization defeated by a (remote) brute force attack in minutes Reality: ASLR for text segment (PIE) is rarely used Only few programs in Linux use PIE 32
109 ASLR Implementations Linux Introduced in Linux (June 2005) Shacham et al. [2004]:16 bits of randomization defeated by a (remote) brute force attack in minutes Reality: ASLR for text segment (PIE) is rarely used Only few programs in Linux use PIE Enough gadgets for ROP can be found in unrandomized code [Schwartz 2011] 32
110 ASLR Implementations 33
111 ASLR Implementations Windows 33
112 ASLR Implementations Windows Introduced from Vista onwards (Jan 2007) 33
113 ASLR Implementations Windows Introduced from Vista onwards (Jan 2007) Reality: Only few programs opt in for ASLR 33
114 ASLR Implementations Windows Introduced from Vista onwards (Jan 2007) Reality: Only few programs opt in for ASLR E.g., Oracle s Java JRE, Adobe Reader, Mozilla Firefox, and Apple Quicktime (or one of their libraries) are not marked ASLR-compatible 33
115 ASLR Implementations Windows Introduced from Vista onwards (Jan 2007) Reality: Only few programs opt in for ASLR E.g., Oracle s Java JRE, Adobe Reader, Mozilla Firefox, and Apple Quicktime (or one of their libraries) are not marked ASLR-compatible From Vista study 33
116 ASLR Implementations Windows Introduced from Vista onwards (Jan 2007) Reality: Only few programs opt in for ASLR E.g., Oracle s Java JRE, Adobe Reader, Mozilla Firefox, and Apple Quicktime (or one of their libraries) are not marked ASLR-compatible From Vista study Good randomization for stack base 33
117 ASLR Implementations Windows Introduced from Vista onwards (Jan 2007) Reality: Only few programs opt in for ASLR E.g., Oracle s Java JRE, Adobe Reader, Mozilla Firefox, and Apple Quicktime (or one of their libraries) are not marked ASLR-compatible From Vista study Good randomization for stack base Insufficient randomization for some - e.g., heap and image 33
118 ASLR Implementations Windows Introduced from Vista onwards (Jan 2007) Reality: Only few programs opt in for ASLR E.g., Oracle s Java JRE, Adobe Reader, Mozilla Firefox, and Apple Quicktime (or one of their libraries) are not marked ASLR-compatible From Vista study Good randomization for stack base Insufficient randomization for some - e.g., heap and image Lesson: bad crypto use will lead to vulnerabilities - again 33
119 ASLR Limitations 34
120 ASLR Limitations Attacks may leak randomization information 34
121 ASLR Limitations Attacks may leak randomization information Disclosure attacks 34
122 ASLR Limitations Attacks may leak randomization information Disclosure attacks Use vulnerability to read an unauthorized program memory (extract code or randomizing state) 34
123 ASLR Limitations Attacks may leak randomization information Disclosure attacks Use vulnerability to read an unauthorized program memory (extract code or randomizing state) ASLR can be bypassed by information leaks about memory layout 34
124 ASLR Limitations Attacks may leak randomization information Disclosure attacks Use vulnerability to read an unauthorized program memory (extract code or randomizing state) ASLR can be bypassed by information leaks about memory layout E.g., format string vulnerabilities 34
125 ASLR Limitations Attacks may leak randomization information Disclosure attacks Use vulnerability to read an unauthorized program memory (extract code or randomizing state) ASLR can be bypassed by information leaks about memory layout E.g., format string vulnerabilities So, what can we do? 34
126 ASLR Limitations Attacks may leak randomization information Disclosure attacks Use vulnerability to read an unauthorized program memory (extract code or randomizing state) ASLR can be bypassed by information leaks about memory layout E.g., format string vulnerabilities So, what can we do? How do we avoid leaking the key? 34
127 Conclusion Defense against control-flow and data attacks is an ongoing arms race Principled approaches such as CFI and ASLR are promising Significantly raised bar for attackers However, they have implementation limitations Active area of research 35
Module: Advanced Program Vulnerabilities and Defenses. Professor Trent Jaeger. CSE543 - Introduction to Computer and Network Security
CSE543 - Introduction to Computer and Network Security Module: Advanced Program Vulnerabilities and Defenses Professor Trent Jaeger 29 Anatomy of Control-Flow Exploits Two steps in control-flow exploitation
Module: Return-oriented Programming. Professor Trent Jaeger. CSE543 - Introduction to Computer and Network Security
CSE543 - Introduction to Computer and Network Security Module: Return-oriented Programming Professor Trent Jaeger 1 1 Anatomy of Control-Flow Exploits Two steps in control-flow exploitation First -- attacker
Advanced Systems Security: Control-Flow Integrity
Systems and Internet Infrastructure Security Network and Security Research Center Department of Computer Science and Engineering Pennsylvania State University, University Park PA Advanced Systems Security:
CMPSC 497 Execution Integrity
Systems and Internet Infrastructure Security Network and Security Research Center Department of Computer Science and Engineering Pennsylvania State University, University Park PA CMPSC 497 Execution Integrity
Inject malicious code Call any library functions Modify the original code
Inject malicious code Call any library functions Modify the original code 2 Sadeghi, Davi TU Darmstadt 2012 Secure, Trusted, and Trustworthy Computing Chapter 6: Runtime Attacks 2 3 Sadeghi, Davi TU Darmstadt
Return-orientated Programming
Return-orientated Programming or The Geometry of Innocent Flesh on the Bone: Return-into-libc without Function Calls (on the x86) Hovav Shacham, CCS '07 Return-Oriented oriented Programming programming
Software Security: Buffer Overflow Defenses
CSE 484 / CSE M 584: Computer Security and Privacy Software Security: Buffer Overflow Defenses Fall 2017 Franziska (Franzi) Roesner franzi@cs.washington.edu Thanks to Dan Boneh, Dieter Gollmann, Dan Halperin,
CS 161 Computer Security
Paxson Spring 2017 CS 161 Computer Security Discussion 2 Question 1 Software Vulnerabilities (15 min) For the following code, assume an attacker can control the value of basket passed into eval basket.
Software Security: Buffer Overflow Attacks
CSE 484 / CSE M 584: Computer Security and Privacy Software Security: Buffer Overflow Attacks (continued) Autumn 2018 Tadayoshi (Yoshi) Kohno yoshi@cs.washington.edu Thanks to Dan Boneh, Dieter Gollmann,
Robust Shell Code Return Oriented Programming and HeapSpray. Zhiqiang Lin
CS 6V81-05: System Security and Malicious Code Analysis Robust Shell Code Return Oriented Programming and HeapSpray Zhiqiang Lin Department of Computer Science University of Texas at Dallas April 16 th,
Advanced Systems Security: Program Diversity
Systems and Internet Infrastructure Security Network and Security Research Center Department of Computer Science and Engineering Pennsylvania State University, University Park PA Advanced Systems Security:
Introduction to Operating Systems Prof. Chester Rebeiro Department of Computer Science and Engineering Indian Institute of Technology, Madras
Introduction to Operating Systems Prof. Chester Rebeiro Department of Computer Science and Engineering Indian Institute of Technology, Madras Week 08 Lecture 38 Preventing Buffer Overflow Attacks Hello.
Lecture 10 Return-oriented programming. Stephen Checkoway University of Illinois at Chicago Based on slides by Bailey, Brumley, and Miller
Lecture 10 Return-oriented programming Stephen Checkoway University of Illinois at Chicago Based on slides by Bailey, Brumley, and Miller ROP Overview Idea: We forge shellcode out of existing application
Software Security: Buffer Overflow Attacks (continued)
CSE 484 / CSE M 584: Computer Security and Privacy Software Security: Buffer Overflow Attacks (continued) Spring 2015 Franziska (Franzi) Roesner franzi@cs.washington.edu Thanks to Dan Boneh, Dieter Gollmann,
Software Security II: Memory Errors - Attacks & Defenses
1 Software Security II: Memory Errors - Attacks & Defenses Chengyu Song Slides modified from Dawn Song 2 Administrivia Lab1 Writeup 3 Buffer overflow Out-of-bound memory writes (mostly sequential) Allow
Stephen Checkoway, Lucas Davi, Alexandra Dmitrienko, Ahmad-Reza Sadeghi, Hovav Shacham, Marcel Winandy. ACM CCS 2010, Chicago, USA
Stephen Checkoway, Lucas Davi, Alexandra Dmitrienko, Ahmad-Reza Sadeghi, Hovav Shacham, Marcel Winandy ACM CCS 2010, Chicago, USA Ad hoc defense against code injection: W X DEP Code injection unnecessary
CSE 127: Computer Security. Memory Integrity. Kirill Levchenko
CSE 127: Computer Security Memory Integrity Kirill Levchenko November 18, 2014 Stack Buffer Overflow Stack buffer overflow: writing past end of a stackallocated buffer Also called stack smashing One of
Vulnerability Analysis I:
Vulnerability Analysis I: Exploit Hardening Made Easy Surgically Returning to Randomized Lib(c) Mitchell Adair September 9 th, 2011 Outline 1 Background 2 Surgically Returning to Randomized lib(c) 3 Exploit
Module: Program Vulnerabilities. Professor Trent Jaeger. CSE543 - Introduction to Computer and Network Security
CSE543 - Introduction to Computer and Network Security Module: Program Vulnerabilities Professor Trent Jaeger 1 Programming Why do we write programs? Function What functions do we enable via our programs?
CMPSC 497 Buffer Overflow Vulnerabilities
Systems and Internet Infrastructure Security Network and Security Research Center Department of Computer Science and Engineering Pennsylvania State University, University Park PA CMPSC 497 Buffer Overflow
CS 161 Computer Security
Paxson Spring 2011 CS 161 Computer Security Discussion 1 January 26, 2011 Question 1 Buffer Overflow Mitigations Buffer overflow mitigations generally fall into two categories: (i) eliminating the cause
Outline. Memory Exploit
Outline CS 6V81-05: System Security and Malicious Code Analysis Robust Shell Code Return Oriented Programming and HeapSpray Zhiqiang Lin Department of Computer Science University of Texas at Dallas April
This time. Defenses and other memory safety vulnerabilities. Everything you ve always wanted to know about gdb but were too afraid to ask
This time We will continue Buffer overflows By looking at Overflow Defenses and other memory safety vulnerabilities Everything you ve always wanted to know about gdb but were too afraid to ask Overflow
Software Security: Buffer Overflow Defenses and Miscellaneous
CSE 484 / CSE M 584: Computer Security and Privacy Software Security: Buffer Overflow Defenses and Miscellaneous Spring 2017 Franziska (Franzi) Roesner franzi@cs.washington.edu Thanks to Dan Boneh, Dieter
Module: Program Vulnerabilities. Professor Trent Jaeger. CSE543 - Introduction to Computer and Network Security
CSE543 - Introduction to Computer and Network Security Module: Program Vulnerabilities Professor Trent Jaeger 1 Programming Why do we write programs? Function What functions do we enable via our programs?
The Geometry of Innocent Flesh on the Bone
The Geometry of Innocent Flesh on the Bone Return-into-libc without Function Calls (on the x86) Hovav Shacham hovav@cs.ucsd.edu CCS 07 Technical Background Gadget: a short instructions sequence (e.x. pop
Countermeasures in Modern Operating Systems. Yves Younan, Vulnerability Research Team (VRT)
Countermeasures in Modern Operating Systems Yves Younan, Vulnerability Research Team (VRT) Introduction Programs in C/C++: memory error vulnerabilities Countermeasures (mitigations): make exploitation
Lecture Embedded System Security A. R. Darmstadt, Runtime Attacks
2 ARM stands for Advanced RISC Machine Application area: Embedded systems Mobile phones, smartphones (Apple iphone, Google Android), music players, tablets, and some netbooks Advantage: Low power consumption
Betriebssysteme und Sicherheit Sicherheit. Buffer Overflows
Betriebssysteme und Sicherheit Sicherheit Buffer Overflows Software Vulnerabilities Implementation error Input validation Attacker-supplied input can lead to Corruption Code execution... Even remote exploitation
CSE 127 Computer Security
CSE 127 Computer Security Alex Gantman, Spring 2018, Lecture 4 Low Level Software Security II: Format Strings, Shellcode, & Stack Protection Review Function arguments and local variables are stored on
Software Vulnerabilities August 31, 2011 / CS261 Computer Security
Software Vulnerabilities August 31, 2011 / CS261 Computer Security Software Vulnerabilities...1 Review paper discussion...2 Trampolining...2 Heap smashing...2 malloc/free...2 Double freeing...4 Defenses...5
String Oriented Programming Exploring Format String Attacks. Mathias Payer
String Oriented Programming Exploring Format String Attacks Mathias Payer Motivation Additional protection mechanisms prevent many existing attack vectors Format string exploits are often overlooked Drawback:
Sandboxing Untrusted Code: Software-Based Fault Isolation (SFI)
Sandboxing Untrusted Code: Software-Based Fault Isolation (SFI) Brad Karp UCL Computer Science CS GZ03 / M030 9 th December 2011 Motivation: Vulnerabilities in C Seen dangers of vulnerabilities: injection
On Compilers, Memory Errors and Control-Flow Integrity
On Compilers, Memory Errors and Control-Flow Integrity Advanced Compiler Design SS 2015 Antonio Hüseyin Barresi Zürich, 27.5.2015 CVE-2012-0158 is a buffer overflow Vulnerability in the ListView / TreeView
2 Sadeghi, Davi TU Darmstadt 2012 Secure, Trusted, and Trustworthy Computing Chapter 6: Runtime Attacks
Runtime attacks are major threats to today's applications Control-flow of an application is compromised at runtime Typically, runtime attacks include injection of malicious code Reasons for runtime attacks
Module: Program Vulnerabilities. Professor Trent Jaeger. CSE543 - Introduction to Computer and Network Security
CSE543 - Introduction to Computer and Network Security Module: Program Vulnerabilities Professor Trent Jaeger 1 1 Programming Why do we write programs? Function What functions do we enable via our programs?
CSE 127: Computer Security Control Flow Hijacking. Kirill Levchenko
CSE 127: Computer Security Control Flow Hijacking Kirill Levchenko October 17, 2017 Control Flow Hijacking Defenses Avoid unsafe functions Stack canary Separate control stack Address Space Layout Randomization
BUFFER OVERFLOW DEFENSES & COUNTERMEASURES
BUFFER OVERFLOW DEFENSES & COUNTERMEASURES CMSC 414 FEB 01 2018 RECALL OUR CHALLENGES How can we make these even more difficult? Putting code into the memory (no zeroes) Finding the return address (guess
Runtime attacks are major threats to today's applications Control-flow of an application is compromised at runtime Typically, runtime attacks include
2 Runtime attacks are major threats to today's applications Control-flow of an application is compromised at runtime Typically, runtime attacks include injection of malicious code Reasons for runtime attacks
Advanced Security for Systems Engineering VO 05: Advanced Attacks on Applications 2
Advanced Security for Systems Engineering VO 05: Advanced Attacks on Applications 2 Clemens Hlauschek, Christian Schanes INSO Industrial Software Institute of Information Systems Engineering Faculty of
Advanced Systems Security: Ordinary Operating Systems
Systems and Internet Infrastructure Security Network and Security Research Center Department of Computer Science and Engineering Pennsylvania State University, University Park PA Advanced Systems Security:
Remix: On-demand Live Randomization
Remix: On-demand Live Randomization Yue Chen, Zhi Wang, David Whalley, Long Lu* Florida State University, Stony Brook University* Background Buffer Overflow -> Code Injection Attack Background Buffer Overflow
Inline Reference Monitoring Techniques
Inline Reference Monitoring Techniques In the last lecture, we started talking about Inline Reference Monitors. The idea is that the policy enforcement code runs with the same address space as the code
Lecture 10 Code Reuse
Lecture 10 Code Reuse Computer and Network Security 4th of December 2017 Computer Science and Engineering Department CSE Dep, ACS, UPB Lecture 10, Code Reuse 1/23 Defense Mechanisms static & dynamic analysis
CSE 509: Computer Security
CSE 509: Computer Security Date: 2.16.2009 BUFFER OVERFLOWS: input data Server running a daemon Attacker Code The attacker sends data to the daemon process running at the server side and could thus trigger
CS 161 Computer Security. Week of January 22, 2018: GDB and x86 assembly
Raluca Popa Spring 2018 CS 161 Computer Security Discussion 1 Week of January 22, 2018: GDB and x86 assembly Objective: Studying memory vulnerabilities requires being able to read assembly and step through
Biography. Background
From Over ow to Shell An Introduction to low-level exploitation Carl Svensson @ KTH, January 2019 1 / 28 Biography MSc in Computer Science, KTH Head of Security, KRY/LIVI CTF: HackingForSoju E-mail: calle.svensson@zeta-two.com
CSE 127 Computer Security
CSE 127 Computer Security Stefan Savage, Spring 2018, Lecture 4 Low Level Software Security II: Format Strings, Shellcode, & Stack Protection Review Function arguments and local variables are stored on
CSE 127 Computer Security
CSE 127 Computer Security Stefan Savage, Fall 2018, Lecture 4 Low Level Software Security II: Format Strings, Shellcode, & Stack Protection Review Function arguments and local variables are stored on the
Midterm 1 Review. Memory Safety & Web Attacks
Midterm 1 Review Memory Safety & Web Attacks What s on the midterm? Lecture material through Feb 9 Lecture notes ("Notes on..." on the course site) Section material, per "Handout w/ solutions" Concepts
Abstraction Recovery for Scalable Static Binary Analysis
Abstraction Recovery for Scalable Static Binary Analysis Edward J. Schwartz Software Engineering Institute Carnegie Mellon University 1 The Gap Between Binary and Source Code push mov sub movl jmp mov
Return-Oriented Rootkits
Return-Oriented Rootkits Ralf Hund Troopers March 10, 2010 What is Return-Oriented Programming? New emerging attack technique, pretty hyped topic Gained awareness in 2007 in Hovav Shacham s paper The Geometry
Exploit Mitigation - PIE
Exploit Mitigation - PIE Compass Security Schweiz AG Werkstrasse 20 Postfach 2038 CH-8645 Jona Tel +41 55 214 41 60 Fax +41 55 214 41 61 team@csnc.ch www.csnc.ch ASCII Armor Arbitrary Write Overflow Local
Lecture 08 Control-flow Hijacking Defenses
Lecture 08 Control-flow Hijacking Defenses Stephen Checkoway University of Illinois at Chicago CS 487 Fall 2017 Slides adapted from Miller, Bailey, and Brumley Control Flow Hijack: Always control + computation
Control Flow Integrity & Software Fault Isolation. David Brumley Carnegie Mellon University
Control Flow Integrity & Software Fault Isolation David Brumley Carnegie Mellon University Our story so far Unauthorized Control Information Tampering http://propercourse.blogspot.com/2010/05/i-believe-in-duct-tape.html
From Over ow to Shell
From Over ow to Shell An Introduction to low-level exploitation Carl Svensson @ Google, December 2018 1 / 25 Biography MSc in Computer Science, KTH Head of Security, KRY/LIVI CTF: HackingForSoju E-mail:
CSE Computer Security
CSE 543 - Computer Security Lecture 17 - Language-based security October 25, 2007 URL: http://www.cse.psu.edu/~tjaeger/cse543-f07/ 1 Engineering Disaster? Millions of Bots Compromised applications Programming
CMPSC 497: Midterm Review
CMPSC 497: Midterm Review Trent Jaeger Systems and Internet Infrastructure Security (SIIS) Lab Computer Science and Engineering Department Pennsylvania State University Page 1 Midterm Format True/False
Selected background on ARM registers, stack layout, and calling convention
Selected background on ARM registers, stack layout, and calling convention ARM Overview ARM stands for Advanced RISC Machine Main application area: Mobile phones, smartphones (Apple iphone, Google Android),
CSC 591 Systems Attacks and Defenses Return-into-libc & ROP
CSC 591 Systems Attacks and Defenses Return-into-libc & ROP Alexandros Kapravelos akaprav@ncsu.edu NOEXEC (W^X) 0xFFFFFF Stack Heap BSS Data 0x000000 Code RW RX Deployment Linux (via PaX patches) OpenBSD
Defeating Return-Oriented Rootkits with Return-less Kernels
5 th ACM SIGOPS EuroSys Conference, Paris, France April 15 th, 2010 Defeating Return-Oriented Rootkits with Return-less Kernels Jinku Li, Zhi Wang, Xuxian Jiang, Mike Grace, Sina Bahram Department of Computer
Applications. Cloud. See voting example (DC Internet voting pilot) Select * from userinfo WHERE id = %%% (variable)
Software Security Requirements General Methodologies Hardware Firmware Software Protocols Procedure s Applications OS Cloud Attack Trees is one of the inside requirement 1. Attacks 2. Evaluation 3. Mitigation
SoK: Eternal War in Memory
SoK: Eternal War in Memory László Szekeres, Mathias Payer, Tao Wei, Dawn Song Presenter: Wajih 11/7/2017 Some slides are taken from original S&P presentation 1 What is SoK paper? Systematization of Knowledge
Advanced Buffer Overflow
Pattern Recognition and Applications Lab Advanced Buffer Overflow Ing. Davide Maiorca, Ph.D. davide.maiorca@diee.unica.it Computer Security A.Y. 2016/2017 Department of Electrical and Electronic Engineering
Exploiting Stack Buffer Overflows Learning how blackhats smash the stack for fun and profit so we can prevent it
Exploiting Stack Buffer Overflows Learning how blackhats smash the stack for fun and profit so we can prevent it 29.11.2012 Secure Software Engineering Andreas Follner 1 Andreas Follner Graduated earlier
Defending Computer Networks Lecture 4: Exploit Defenses. Stuart Staniford Adjunct Professor of Computer Science
Defending Computer Networks Lecture 4: Exploit Defenses Stuart Staniford Adjunct Professor of Computer Science Logis;cs Course is now official Expect an email from Stephanie Meik with your PIN Need to
CSE 127 Computer Security
CSE 127 Computer Security Stefan Savage, Spring 2018, Lecture 5 Low Level Software Security III: Integers, ROP, & CFI Integer Arithmetic in C Quiz time! What does this code produce? 100 200 300 100 200
CS 6V Control-Flow Integrity Principles, Implementations, and Applications. Sureshbabu Murugesan
CS 6V81-05 Control-Flow Integrity Principles, Implementations, and Applications Sureshbabu Murugesan Department of Computer Science University of Texas at Dallas February 29 th, 2012 Outline 1 Overview
Mitigating Code-Reuse Attacks with. Tyler Bletsch, Xuxian Jiang, Vince Freeh Dec. 9, 2011
Mitigating Code-Reuse Attacks with Control-Flow Locking Tyler Bletsch, Xuxian Jiang, Vince Freeh Dec. 9, 2011 Introduction Computer systems run complicated software, which is vulnerable We keep finding
CNIT 127: Exploit Development. Ch 14: Protection Mechanisms. Updated
CNIT 127: Exploit Development Ch 14: Protection Mechanisms Updated 3-25-17 Topics Non-Executable Stack W^X (Either Writable or Executable Memory) Stack Data Protection Canaries Ideal Stack Layout AAAS:
Outline. Heap meta-data. Non-control data overwrite
Outline CSci 5271 Introduction to Computer Security Day 5: Low-level defenses and counterattacks Stephen McCamant University of Minnesota, Computer Science & Engineering Non-control data overwrite Heap
Hacking Blind BROP. Presented by: Brooke Stinnett. Article written by: Andrea Bittau, Adam Belay, Ali Mashtizadeh, David Mazie`res, Dan Boneh
Hacking Blind BROP Presented by: Brooke Stinnett Article written by: Andrea Bittau, Adam Belay, Ali Mashtizadeh, David Mazie`res, Dan Boneh Overview Objectives Introduction to BROP ROP recap BROP key phases
18-600: Recitation #4 Exploits
18-600: Recitation #4 Exploits 20th September 2016 Agenda More x86-64 assembly Buffer Overflow Attack Return Oriented Programming Attack 3 Recap: x86-64: Register Conventions Arguments passed in registers:
20: Exploits and Containment
20: Exploits and Containment Mark Handley Andrea Bittau What is an exploit? Programs contain bugs. These bugs could have security implications (vulnerabilities) An exploit is a tool which exploits a vulnerability
Defeat Exploit Mitigation Heap Attacks. compass-security.com 1
Defeat Exploit Mitigation Heap Attacks compass-security.com 1 ASCII Armor Arbitrary Write Overflow Local Vars Exploit Mitigations Stack Canary ASLR PIE Heap Overflows Brute Force Partial RIP Overwrite
Outline. Format string attack layout. Null pointer dereference
CSci 5271 Introduction to Computer Security Day 5: Low-level defenses and counterattacks Stephen McCamant University of Minnesota, Computer Science & Engineering Null pointer dereference Format string
Memory Safety (cont d) Software Security
Memory Safety (cont d) Software Security CS 161: Computer Security Prof. Raluca Ada Popa January 17, 2016 Some slides credit to David Wagner and Nick Weaver Announcements Discussion sections and office
CODE reuse attacks (CRAs) emerged as a powerful attack, HCIC: Hardware-assisted Control-flow Integrity Checking
This article has been accepted for publication in a future issue of this journal, but has not been fully edited Content may change prior to final publication Citation information: DOI 101109/JIOT20182866164,
Beyond Stack Smashing: Recent Advances in Exploiting. Jonathan Pincus(MSR) and Brandon Baker (MS)
Beyond Stack Smashing: Recent Advances in Exploiting Buffer Overruns Jonathan Pincus(MSR) and Brandon Baker (MS) Buffer Overflows and How they Occur Buffer is a contiguous segment of memory of a fixed
Smashing the Buffer. Miroslav Štampar
Smashing the Buffer Miroslav Štampar (mstampar@zsis.hr) Summary BSidesVienna 2014, Vienna (Austria) November 22nd, 2014 2 Buffer overflow (a.k.a.) Buffer overrun An anomaly where a program, while writing
This exam contains 7 pages (including this cover page) and 4 questions. Once we tell you to start, please check that no pages are missing.
Computer Science 5271 Fall 2015 Midterm exam October 19th, 2015 Time Limit: 75 minutes, 4:00pm-5:15pm This exam contains 7 pages (including this cover page) and 4 questions. Once we tell you to start,
Advanced Buffer Overflow
Pattern Recognition and Applications Lab Advanced Buffer Overflow Ing. Davide Maiorca, Ph.D. davide.maiorca@diee.unica.it Computer Security A.Y. 2017/2018 Department of Electrical and Electronic Engineering
Lecture Notes for 04/04/06: UNTRUSTED CODE Fatima Zarinni.
Lecture Notes for 04/04/06 UNTRUSTED CODE Fatima Zarinni. Last class we started to talk about the different System Solutions for Stack Overflow. We are going to continue the subject. Stages of Stack Overflow
CSE Spring Assignment 3: Return-oriented Programming
CSE 543 - Spring 2015 - Assignment 3: Return-oriented Programming 1 Dates Out: March 26, 2015 Due: April 22, 2015 2 Introduction In this assignment, you will produce return-oriented programming (ROP) attacks.
PRACTICAL CONTROL FLOW INTEGRITY & RANDOMIZATION FOR BINARY EXECUTABLES
PRACTICAL CONTROL FLOW INTEGRITY & RANDOMIZATION FOR BINARY EXECUTABLES Christos Tselas, AM:875 Elisjana Ymeralli, AM:801 Ioanna Ramoutsaki, AM: 812 Vasilis Glabedakis, AM: 2921 cs-457 Department: Computer
Defeating Code Reuse Attacks with Minimal Tagged Architecture. Samuel Fingeret. B.S., Massachusetts Institute of Technology (2014)
Defeating Code Reuse Attacks with Minimal Tagged Architecture by Samuel Fingeret B.S., Massachusetts Institute of Technology (2014) Submitted to the Department of Electrical Engineering and Computer Science
0x1A Great Papers in Computer Security
CS 380S 0x1A Great Papers in Computer Security Vitaly Shmatikov http://www.cs.utexas.edu/~shmat/courses/cs380s/ slide 1 Reference Monitor Observes execution of the program/process At what level? Possibilities:
CNIT 127: Exploit Development. Ch 1: Before you begin. Updated
CNIT 127: Exploit Development Ch 1: Before you begin Updated 1-14-16 Basic Concepts Vulnerability A flaw in a system that allows an attacker to do something the designer did not intend, such as Denial
Security and Privacy in Computer Systems. Lecture 5: Application Program Security
CS 645 Security and Privacy in Computer Systems Lecture 5: Application Program Security Buffer overflow exploits More effective buffer overflow attacks Preventing buffer overflow attacks Announcement Project
Control Flow Integrity
Control Flow Integrity Outline CFI Control Flow Integrity at Source Code Level BinCFI CFI for Binary Executables BinCC Binary Code Continent vfguard CFI Policy for Virtual Function Calls 1 M. Abadi, M.
Secure Programming Lecture 3: Memory Corruption I (Stack Overflows)
Secure Programming Lecture 3: Memory Corruption I (Stack Overflows) David Aspinall, Informatics @ Edinburgh 24th January 2017 Outline Roadmap Memory corruption vulnerabilities Instant Languages and Runtimes
4. Jump to *RA 4. StackGuard 5. Execute code 5. Instruction Set Randomization 6. Make system call 6. System call Randomization
04/04/06 Lecture Notes Untrusted Beili Wang Stages of Static Overflow Solution 1. Find bug in 1. Static Analysis 2. Send overflowing input 2. CCured 3. Overwrite return address 3. Address Space Randomization
Security Workshop HTS. LSE Team. February 3rd, 2016 EPITA / 40
Security Workshop HTS LSE Team EPITA 2018 February 3rd, 2016 1 / 40 Introduction What is this talk about? Presentation of some basic memory corruption bugs Presentation of some simple protections Writing
Q: Exploit Hardening Made Easy
Q: Exploit Hardening Made Easy E.J. Schwartz, T. Avgerinos, and D. Brumley. In Proc. USENIX Security Symposium, 2011. CS 6301-002: Language-based Security Dr. Kevin Hamlen Attacker s Dilemma Problem Scenario
Is Exploitation Over? Bypassing Memory Protections in Windows 7
Is Exploitation Over? Bypassing Memory Protections in Windows 7 Alexander Sotirov alex@sotirov.net About me Exploit development since 1999 Published research into reliable exploitation techniques: Heap
Bypassing SEHOP. Stéfan Le Berre Damien Cauquil
Bypassing SEHOP Stéfan Le Berre s.leberre@sysdream.com Damien Cauquil d.cauquil@sysdream.com Table of contents 0. Introduction...3 1. SEHOP specifications (short version)...3 2. Dealing with SEHOP when
Return-Oriented Rootkits: Bypassing Kernel Code Integrity Protection Mechanisms
Return-Oriented Rootkits: Bypassing Kernel Code Integrity Protection Mechanisms Ralf Hund Thorsten Holz Felix C. Freiling University of Mannheim Page 1 Motivation (1) Operating systems separate system
CSE Computer Security (Fall 2006)
CSE 543 - Computer Security (Fall 2006) Lecture 22 - Language-based security November 16, 2006 URL: http://www.cse.psu.edu/~tjaeger/cse543-f06/ 1 The Morris Worm Robert Morris, a 23 doctoral student from
Secure Software Development: Theory and Practice
Secure Software Development: Theory and Practice Suman Jana MW 2:40-3:55pm 415 Schapiro [SCEP] *Some slides are borrowed from Dan Boneh and John Mitchell Software Security is a major problem! Why writing
Exploits and gdb. Tutorial 5
Exploits and gdb Tutorial 5 Exploits and gdb 1. Buffer Vulnerabilities 2. Code Injection 3. Integer Attacks 4. Advanced Exploitation 5. GNU Debugger (gdb) Buffer Vulnerabilities Basic Idea Overflow or