SoK: Eternal War in Memory
|
|
|
- Leon Albert Craig
- 5 years ago
- Views:
Transcription
1 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
2 What is SoK paper? Systematization of Knowledge (SoK), in IEEE S&P conference, since 2010 Papers provide a high value to our community but may not be accepted because of a lack of novel research contributions. survey papers that provide useful perspectives on major research areas; papers that support or challenge long-held beliefs with compelling evidence, or papers that provide an extensive and realistic evaluation of competing approaches to solving specific problems. 2
3 SoK paper The goal is to encourage work that evaluates, systematizes, and contextualizes existing knowledge. identify areas that have enjoyed much research attention, point out open areas with unsolved challenges, and present a prioritization that can guide researchers to make progress on solving important challenges. 3
4 Problem C/C++ is memory unsafe Everybody runs C/C++ code They surely have exploitable vulnerabilities 4
5 Background 5
6 Memory Safety Memory safety is a property that ensures that all memory accesses adhere to the semantics defined by the source programming language. Memory unsafe languages like C/C++ do not enforce memory safety and data accesses can occur through stale/illegal pointers. Memory safety violations rely on two conditions that must both be fulfilled: A pointer either goes out of bounds or becomes dangling. This pointer is used to either read or write. 6
7 Spatial memory safety Spatial memory safety is a property that ensures that all memory dereferences are within bounds of their pointer s valid objects. An object s bounds are defined when the object is allocated. Pointers that point outside of their associated object may not be dereferenced. Dereferencing such illegal pointers results in a spatial memory safety error and undefined behavior. 7
8 Spatial memory safety 8
9 Temporal memory safety Temporal memory safety is a property that ensures that all memory dereferences are valid at the time of the dereference, i.e., the pointed-to object is the same as when the pointer was created. When an object is freed, the underlying memory is no longer associated to the object and the pointer is no longer valid. Dereferencing such an invalid pointer results in a temporal memory safety error and undefined behavior. 9
10 Temporal memory safety 10
11 Eternal War on Memory 11
12 Overview What are the attacks? What are the deployed protections? What are the not deployed protections? Why aren t they deployed? 12
13 Attack Model 13
14 Attack Model First step: Memory Corruption Attack Second step: Code Corruption Attack Control Flow Hijacking Data-only Attack Information leak 14
15 Classic Stack Smashing Attack out-of-bounds dangling to write to read code pointer... to target code address by indir. call/jmp by ret instruction Exec. gadgets or functions Execute injected code Control-flow hijack 15
16 Use-after-free Exploits out-of-bounds dangling to write to read Heap overflow code pointer... to target code address by indir. call/jmp by ret instruction Exec. gadgets or functions Execute injected code Control-flow hijack 16
17 Corrupting newer and newer Pointers out-of-bounds dangling to write to read data pointer code pointer... to target code address by indir. call/jmp by ret instruction Exec. gadgets or functions Execute injected code Control-flow hijack 17
18 Attack Model First step: Memory Corruption Attack Second step: Code Corruption Attack Control Flow Hijacking Data-only Attack Information leak 18
19 Modifying the code itself out-of-bounds dangling to write to read data pointer Modify code... to attacker specified code code pointer... to target code address by indir. call/jmp by ret instruction Exec. gadgets or functions Execute injected code Code corruption Control-flow hijack 19
20 Code Integrity out-of-bounds dangling to write to read data pointer Modify code... Read-only code pages to attacker specified code code pointer... to target code address by indir. call/jmp by ret instruction Exec. gadgets or functions Execute injected code Code corruption Control-flow hijack 20
21 Code Integrity out-of-bounds dangling to write to read data pointer Modify code... Read-only code pages to attacker specified code code pointer... to target code address by indir. call/jmp by ret instruction Exec. gadgets or functions Execute injected code Code corruption Control-flow hijack Challenge: In just-in-time compilation, a small time window when the generated code is on a writable page. 21
22 Attack Model First step: Memory Corruption Attack Second step: Code Corruption Attack Control Flow Hijacking Data-only Attack Information leak 22
23 Control Flow Hijacking The attacker wants to control the execution of a program by redirecting control-flow to an attacker-controlled location. 23
24 Control-Flow Hijack out-of-bounds dangling to write to read data pointer Read-only Modify code code pages... to attacker specified code code pointer... to target code address by indir. call/jmp by ret instruction Exec. gadgets or functions Execute injected code e.g., Stack Code corruption Control-flow hijack 24
25 Non-executable data out-of-bounds dangling to write to read data pointer Read-only Modify code code pages... to attacker specified code code pointer... to target code address by indir. call/jmp by ret instruction Code corruption Exec. gadgets or functions Control-flow hijack Non-exec. Execute data injected pages code Inserted Shellcode cannot be executed. 25
26 Return-oriented programming out-of-bounds dangling to write to read data pointer Read-only Modify code code pages... to attacker specified code code pointer... to target code address by indir. call/jmp by ret instruction Exec. gadgets or functions Non-exec. Execute data injected pages code Code corruption Control-flow hijack 26
27 Return integrity out-of-bounds dangling to write to read data pointer Read-only Modify code code pages... to attacker specified code code pointer... to target code address by indir. call/jmp by ret instruction Exec. gadgets or functions Non-exec. Execute data injected pages code Code corruption Control-flow hijack 27
28 Return integrity out-of-bounds dangling to write to read data pointer Read-only Modify code code pages... to attacker specified code code pointer... to target code address by indir. call/jmp Exec. gadgets or functions Stack canaries by ret instruction Non-exec. Execute data injected pages code Code corruption Control-flow hijack 28
29 Hijacking Indirect Calls and Jumps out-of-bounds dangling to write to read data pointer Read-only Modify code code pages... to attacker specified code code pointer... to target code address by indir. call/jmp Exec. gadgets or functions Stack canaries by ret instruction Non-exec. Execute data injected pages code Code corruption Control-flow hijack 29 29
30 Address Space Randomization out-of-bounds dangling to write to read data pointer Read-only Modify code code pages... to attacker specified code code pointer... to target code address by indir. call/jmp Exec. gadgets or functions Stack canaries by ret instruction Non-exec. Execute data injected pages code Code corruption Control-flow hijack 30
31 Address Space Randomization out-of-bounds dangling to write to read data pointer Read-only Modify code code pages... to attacker specified code code pointer... to target ASLR code address by indir. call/jmp Exec. gadgets or functions Stack canaries by ret instruction Non-exec. Execute data injected pages code Code corruption Control-flow hijack 31
32 Attack Model First step: Memory Corruption Attack Second step: Code Corruption Attack Control Flow Hijacking Data-only Attack Information leak 32
33 Data-only Attack The target of the corruption can be any security critical data in memory, Security critical variables configuration data the representation of the user identity or keys. 33
34 Data-only attack out-of-bounds dangling to write to read data pointer Read-only Modify code code pages... to attacker specified code code pointer... to target ASLR code address Modify data... to attacker specified value by indir. call/jmp Exec. gadgets or functions Stack canaries by ret instruction Non-exec. Execute data injected pages code Use corrupted data variable Code corruption Control-flow hijack Data-only attack 34
35 Attack Model First step: Memory Corruption Attack Second step: Code Corruption Attack Control Flow Hijacking Data-only Attack Information leak 35
36 Information Leaks Steal program information/state in memory, process metadata, registers, and files, etc. 1. Valuable information by itself, e.g. credit card, password, encryption key. 2. Facilitating further attacks, e.g., memory addresses to bypass ASLR Side channel attacks 36
37 Information leakage out-of-bounds dangling to write to read data pointer Read-only Modify code code pages... to attacker specified code code pointer... to target ASLR code address Modify data... to attacker specified value Output data Interpret the leaked value by indir. call/jmp Exec. gadgets or functions Stack canaries by ret instruction Non-exec. Execute data injected pages code Use corrupted data variable Code corruption Control-flow hijack Data-only attack Information 37 leak
38 Overview What are the attacks? What are the deployed protections? What are the not deployed protections? Why aren t they deployed? 38
39 Protection Techniques Deterministic Protection A low level reference monitor (RM) enforce a deterministic safety policy. By hardware, like W X By software, adding RM into code Probabilistic Protection Built on randomization or encryption Instruction Set Randomization Address Space Randomization Data Space Randomization 39
40 Protection Techniques Deterministic Protection A low level reference monitor (RM) enforce a deterministic safety policy. By hardware, like W X By software, adding RM into code Probabilistic Protection Built on randomization or encryption Instruction Set Randomization Address Space Randomization Data Space Randomization 40
41 Hijack protection Deployed Protections Policy Technique Weakness Perf. Comp. W X Page flags JIT 1x Good Return integrity Stack cookies Direct overwrite 1x Good Address space rand. ASLR Info-leak. 1.1x Good 41
42 Overview What are the attacks? What are the deployed protections? What are the not deployed protections? Why aren t they deployed? 42
43 Control-flow Integrity out-of-bounds dangling to write to read data pointer Modify code... code pointer... Modify data... Output data to attacker specified code to target code address to attacker specified value Interpret the leaked value by indir. call/jmp by ret instruction Use corrupted data variable Exec. gadgets or functions Execute injected code Code corruption Control-flow hijack Data-only attack Information 43 leak
44 Control-flow integrity out-of-bounds dangling to write to read data pointer Modify code... code pointer... Modify data... Output data to attacker specified code to target code address to attacker specified value Interpret the leaked value by indir. call/jmp CFI by ret instruction Use corrupted data variable Exec. gadgets or functions Execute injected code Code corruption Control-flow hijack Data-only attack Information 44 leak
45 CFI p = &f jmp p f() { } q = &g jmp q g() { } 45
46 CFI ID p = &f jmp p f() { } q = &g jmp q ID g() { } 46
47 CFI check ID p = &f jmp p ID f() { } check ID q = &g jmp q ID g() { } 47
48 CFI check? p = &f jmp p ID f() { } check? if ( ) q = &f else q = &g jmp q ID g() { } 48
49 Over-approximation problem check ID p = &f jmp p ID f() { } if ( ) q = &f else q = &g check ID jmp q ID g() { } 49
50 Over-approximation problem check ID p = &f jmp p ID printf() { } if ( ) q = &f else q = &g check ID jmp q ID system() { } 50
51 Hijack protection CFI Policy Technique Weakness Perf. Comp. W R Page flags JIT 1x Good Return integrity Stack cookies Direct overwrite 1x Good Address space rand. ASLR Info-leak. 1.1x Good Control-flow integ. CFI Over-approx. 1.4x Libraries 51
52 Memory Safety out-of-bounds dangling to write to read data pointer Modify code... code pointer... Modify data... Output data to attacker specified code to target code address to attacker specified value Interpret the leaked value by indir. call/jmp by ret instruction Use corrupted data variable Exec. gadgets or functions Execute injected code Code corruption Control-flow hijack Data-only attack Information 52 leak
53 Memory safety out-of-bounds to write Pointer metadata tracking & checking dangling to read data pointer Modify code... code pointer... Modify data... Output data to attacker specified code to target code address to attacker specified value Interpret the leaked value by indir. call/jmp by ret instruction Use corrupted data variable Exec. gadgets or functions Execute injected code Code corruption Control-flow hijack Data-only attack Information 53 leak
54 SoftBounds+CETS 54
55 Data integrity out-of-bounds dangling to write to read data pointer Modify code... code pointer... Modify data... Output data to attacker specified code to target code address to attacker specified value Interpret the leaked value by indir. call/jmp by ret instruction Use corrupted data variable Exec. gadgets or functions Execute injected code Code corruption Control-flow hijack Data-only attack Information 55 leak
56 Data integrity out-of-bounds dangling to write to read data pointer Modify code... code pointer... Object metadata tracking & checking Modify data... Output data to attacker specified code to target code address to attacker specified value Interpret the leaked value by indir. call/jmp by ret instruction Use corrupted data variable Exec. gadgets or functions Execute injected code Code corruption Control-flow hijack Data-only attack Information 56 leak
57 WIT (Write Integrity Testing) 57
58 WIT (Write Integrity Testing) 58
59 Data Space Randomization 59
60 Data Space Randomization 60
61 DSR 61
62 DSR 62
63 Data-flow integrity out-of-bounds dangling to write to read data pointer Modify code... code pointer... Modify data... Output data to attacker specified code to target code address to attacker specified value Interpret the leaked value by indir. call/jmp by ret instruction Use corrupted data variable Exec. gadgets or functions Execute injected code Code corruption Control-flow hijack Data-only attack Information 63 leak
64 Data-flow integrity out-of-bounds dangling to write to read data pointer Modify code... code pointer... Modify data... Output data to attacker specified code to target code address to attacker specified value Interpret the leaked value by indir. call/jmp by DFI ret instruction Use corrupted data variable Exec. gadgets or functions Execute injected code Code corruption Control-flow hijack Data-only attack Information 64 leak
65 Generic protection Hijack protection DFI Policy Technique Weakness Perf. Comp. W R Page flags JIT 1x Good Return integrity Stack cookies Direct overwrite 1x Good Address space rand. ASLR Info-leak. 1.1x Good Control-flow integ. CFI Over-approx. 1.4x Libraries Memory safety SB+CETS None 2-4x Good Data integrity WIT Over-approx., 1.2x Libraries Data space rand. DSR Over-approx., 1.3x Libraries Data-flow integrity DFI Over-approx. 2-3x Libraries 65
66 Challenges in Practical Usage Why most of defense mechanisms are not used in practice? 1. the performance overhead of the approach outweighs the potential protection, 2. the approach is not compatible with all currently used features (e.g., in legacy programs), 3. the approach is not robust and the offered protection is not complete, 4. or the approach depends on changes in the compiler toolchain or in the source-code while the toolchain is not publicly available. 66
67 Challenges in Practical Usage Why most of defense mechanisms are not used in practice? 1. the performance overhead of the approach outweighs the potential protection, 2. the approach is not compatible with all currently used features (e.g., in legacy programs), 3. the approach is not robust and the offered protection is not complete, 4. or the approach depends on changes in the compiler toolchain or in the source-code while the toolchain is not publicly available. 67
68 Challenges in Practical Usage Why most of defense mechanisms are not used in practice? 1. the performance overhead of the approach outweighs the potential protection, 2. the approach is not compatible with all currently used features (e.g., in legacy programs), 3. the approach is not robust and the offered protection is not complete, 4. or the approach depends on changes in the compiler toolchain or in the source-code while the toolchain is not publicly available. 68
69 Challenges in Practical Usage Why most of defense mechanisms are not used in practice? 1. the performance overhead of the approach outweighs the potential protection, 2. the approach is not compatible with all currently used features (e.g., in legacy programs), 3. the approach is not robust and the offered protection is not complete, 4. or the approach depends on changes in the compiler toolchain or in the source-code while the toolchain is not publicly available. 69
70 Questions? 70
71 Backup slides 71
72 Attack Model First step: Memory Corruption Attack Second step: Code Corruption Attack Control Flow Hijacking Data-only Attack Information leak 72
73 Memory Corruption Attack Memory errors (bugs) allow the attacker to read and modify the program s internal state in unintended ways. C and C++ are inherently memory unsafe. writing an array beyond its bounds, dereferencing a null-pointer, or reading an uninitialized variable result in undefined behavior Finding and fixing all the programming bugs is infeasible 73
74 Memory Corruption More aggressive behavior: attacker changes internal program state Most often: memory contents Values of variables on stack/heap Code pointers Attack vectors Buffer overflows Use-after-free/double-free Uninitialized variables Format strings 74
75 Bypassing ASLR with user scripting out-of-bounds dangling to write to read data pointer Read-only Modify code code pages... to attacker specified code code pointer... to target code address Modify data... to attacker specified value Output data Interpret the leaked value by indir. call/jmp Exec. gadgets or functions Stack canaries by ret instruction Non-exec. Execute data injected pages code Use corrupted data variable Code corruption Control-flow hijack Data-only attack Information 75 leak
SoK: Eternal War in Memory Laszlo Szekeres, Mathias Payer, Tao Wei, and Dawn Song In: Oakland 14
SoK: Eternal War in Memory Laszlo Szekeres, Mathias Payer, Tao Wei, and Dawn Song In: Oakland 14 Presenter: Mathias Payer, EPFL http://hexhive.github.io 1 Memory attacks: an ongoing war Vulnerability classes
CS-527 Software Security
CS-527 Software Security Memory Safety Asst. Prof. Mathias Payer Department of Computer Science Purdue University TA: Kyriakos Ispoglou https://nebelwelt.net/teaching/17-527-softsec/ Spring 2017 Eternal
in memory: an evolution of attacks Mathias Payer Purdue University
in memory: an evolution of attacks Mathias Payer Purdue University Images (c) MGM, WarGames, 1983 Memory attacks: an ongoing war Vulnerability classes according to CVE Memory
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
SoK: Eternal War in Memory
SoK: Eternal War in Memory László Szekeres, Mathias Payer, Tao Wei, Dawn Song Stony Brook University University of California, Berkeley Peking University Abstract Memory corruption bugs in software written
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
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
Control-Flow Hijacking: Are We Making Progress? Mathias Payer, Purdue University
Control-Flow Hijacking: Are We Making Progress? Mathias Payer, Purdue University http://hexhive.github.io 1 Bugs are everywhere? https://en.wikipedia.org/wiki/pwn2own 2 Trends in Memory Errors* * Victor
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
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
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:
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.
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
Memory Corruption: Why Protection is Hard. Mathias Payer, Purdue University
Memory Corruption: Why Protection is Hard Mathias Payer, Purdue University http://hexhive.github.io 1 Software is unsafe and insecure Low-level languages (C/C++) trade type safety and memory safety for
Buffer overflow prevention, and other attacks
Buffer prevention, and other attacks Comp Sci 3600 Security Outline 1 2 Two approaches to buffer defense Aim to harden programs to resist attacks in new programs Run time Aim to detect and abort attacks
CS527 Software Security
Security Policies Purdue University, Spring 2018 Security Policies A policy is a deliberate system of principles to guide decisions and achieve rational outcomes. A policy is a statement of intent, and
CS161 Midterm 1 Review
CS161 Midterm 1 Review Midterm 1: March 4, 18:3020:00 Same room as lecture Security Analysis and Threat Model Basic security properties CIA Threat model A. We want perfect security B. Security is about
Buffer overflow background
and heap buffer background Comp Sci 3600 Security Heap Outline and heap buffer Heap 1 and heap 2 3 buffer 4 5 Heap Outline and heap buffer Heap 1 and heap 2 3 buffer 4 5 Heap Address Space and heap buffer
A program execution is memory safe so long as memory access errors never occur:
A program execution is memory safe so long as memory access errors never occur: Buffer overflows, null pointer dereference, use after free, use of uninitialized memory, illegal free Memory safety categories
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
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
Honours/Master/PhD Thesis Projects Supervised by Dr. Yulei Sui
Honours/Master/PhD Thesis Projects Supervised by Dr. Yulei Sui Projects 1 Information flow analysis for mobile applications 2 2 Machine-learning-guide typestate analysis for UAF vulnerabilities 3 3 Preventing
Lecture 4 September Required reading materials for this class
EECS 261: Computer Security Fall 2007 Lecture 4 September 6 Lecturer: David Wagner Scribe: DK Moon 4.1 Required reading materials for this class Beyond Stack Smashing: Recent Advances in Exploiting Buffer
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:
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
Cling: A Memory Allocator to Mitigate Dangling Pointers. Periklis Akritidis
Cling: A Memory Allocator to Mitigate Dangling Pointers Periklis Akritidis --2010 Use-after-free Vulnerabilities Accessing Memory Through Dangling Pointers Techniques : Heap Spraying, Feng Shui Manual
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 Anatomy of Control-Flow Exploits 2 Anatomy of Control-Flow Exploits Two steps in control-flow
Computer Security Course. Midterm Review
Computer Security Course. Dawn Song Midterm Review In class: Logistics On time: 4:10-5:30pm Wed 1 8x11 page cheat sheet allowed Special requirements: see TA Part I, II, III Scope Software Security Secure
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,
Lecture 9 Assertions and Error Handling CS240
Lecture 9 Assertions and Error Handling CS240 The C preprocessor The C compiler performs Macro expansion and directive handling Preprocessing directive lines, including file inclusion and conditional compilation,
CSE 565 Computer Security Fall 2018
CSE 565 Computer Security Fall 2018 Lecture 14: Software Security Department of Computer Science and Engineering University at Buffalo 1 Software Security Exploiting software vulnerabilities is paramount
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
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
Software security, secure programming
Software security, secure programming Lecture 4: Protecting your code against software vulnerabilities? (overview) Master on Cybersecurity Master MoSiG Academic Year 2017-2018 Preamble Bad news several
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
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
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
Code with red border means vulnerable code. Code with green border means corrected code. This program asks the user for a password with the function
1 Code with red border means vulnerable code. Code with green border means corrected code. This program asks the user for a password with the function IsPasswordOK(), and compares it with the correct password.
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
Prac%cal Control Flow Integrity & Randomiza%on for Binary Executables
Prac%cal Control Flow Integrity & Randomiza%on for Binary Executables Chao Zhang Tao Wei Zhaofeng Chen Lei Duan Peking University Peking University UC Berkeley Peking University Peking University László
CSCE 548 Building Secure Software Buffer Overflow. Professor Lisa Luo Spring 2018
CSCE 548 Building Secure Software Buffer Overflow Professor Lisa Luo Spring 2018 Previous Class Virus vs. Worm vs. Trojan & Drive-by download Botnet & Rootkit Malware detection Scanner Polymorphic malware
C and C++: vulnerabilities, exploits and countermeasures
C and C++: vulnerabilities, exploits and countermeasures Yves Younan DistriNet, Department of Computer Science Katholieke Universiteit Leuven Belgium Yves.Younan@cs.kuleuven.ac.be Introduction C/C++ programs:
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
Runtime Defenses against Memory Corruption
CS 380S Runtime Defenses against Memory Corruption Vitaly Shmatikov slide 1 Reading Assignment Cowan et al. Buffer overflows: Attacks and defenses for the vulnerability of the decade (DISCEX 2000). Avijit,
Native Language Exploitation
Native Language Exploitation András Gazdag CrySyS Lab, BME www.crysys.hu 2017 CrySyS Lab Memory errors and corruption Memory error vulnerabilities are created by programmers and exploited by attackers
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
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
A survey of Hardware-based Control Flow Integrity (CFI)
A survey of Hardware-based Control Flow Integrity (CFI) RUAN DE CLERCQ and INGRID VERBAUWHEDE, KU Leuven Control Flow Integrity (CFI) is a computer security technique that detects runtime attacks by monitoring
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
Buffer Overflow Attacks
Buffer Overflow Attacks 1. Smashing the Stack 2. Other Buffer Overflow Attacks 3. Work on Preventing Buffer Overflow Attacks Smashing the Stack An Evil Function void func(char* inp){ } char buffer[16];
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
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?
Overview AEG Conclusion CS 6V Automatic Exploit Generation (AEG) Matthew Stephen. Department of Computer Science University of Texas at Dallas
CS 6V81.005 Automatic Exploit Generation (AEG) Matthew Stephen Department of Computer Science University of Texas at Dallas February 20 th, 2012 Outline 1 Overview Introduction Considerations 2 AEG Challenges
Stack Vulnerabilities. CS4379/5375 System Security Assurance Dr. Jaime C. Acosta
1 Stack Vulnerabilities CS4379/5375 System Security Assurance Dr. Jaime C. Acosta Part 1 2 3 An Old, yet Still Valid Vulnerability Buffer/Stack Overflow ESP Unknown Data (unused) Unknown Data (unused)
Memory Corruption 101 From Primitives to Exploit
Memory Corruption 101 From Primitives to Exploit Created by Nick Walker @ MWR Infosecurity / @tel0seh What is it? A result of Undefined Behaviour Undefined Behaviour A result of executing computer code
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
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?
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,
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
Memory Error Exploits and Defenses
Memory Error Exploits and Defenses 1 Process Memory Layout argv, env stack heap bss data text high mem Argv/Env: CLI args and environment Stack: generally grows downwards Heap: generally grows upwards
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
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
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
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?
Code: analysis, bugs, and security
Code: analysis, bugs, and security supported by Bitdefender Marius Minea marius@cs.upt.ro 4 October 2017 Course goals improve skills: write robust, secure code understand program internals learn about
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,
Secure Systems Engineering
Secure Systems Engineering Chester Rebeiro Indian Institute of Technology Madras Flaws that would allow an attacker access the OS flaw Bugs in the OS The Human factor Chester Rebeiro, IITM 2 Program Bugs
Lecture 1: Buffer Overflows
CS5431 Computer Security Practicum Spring 2017 January 27, 2017 1 Conficker Lecture 1: Buffer Overflows Instructor: Eleanor Birrell In November 2008, a new piece of malware was observed in the wild. This
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
I run a Linux server, so we re secure
Silent Signal vsza@silentsignal.hu 18 September 2010 Linux from a security viewpoint we re talking about the kernel, not GNU/Linux distributions Linux from a security viewpoint we re talking about the
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
INTRODUCTION TO EXPLOIT DEVELOPMENT
INTRODUCTION TO EXPLOIT DEVELOPMENT Nathan Ritchey and Michael Tucker Who Am I (Nathan Ritchey) Have Bachelors in Computer Science Member of CSG Working on Masters with focus on Information Assurance Some
CMSC 414 Computer and Network Security
CMSC 414 Computer and Network Security Buffer Overflows Dr. Michael Marsh August 30, 2017 Trust and Trustworthiness You read: Reflections on Trusting Trust (Ken Thompson), 1984 Smashing the Stack for Fun
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
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
Secure C Coding...yeah right. Andrew Zonenberg Alex Radocea
Secure C Coding...yeah right Andrew Zonenberg Alex Radocea Agenda Some Quick Review Data Representation Pointer Arithmetic Memory Management Basic C Vulnerabilities Memory Corruption Ignoring Return values
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
Data-Oriented Programming
Data-Oriented Programming On the Expressiveness of Non-Control Data Attacks Hong Hu, Shweta Shinde, Sendroiu Adrian, Zheng Leong Chua, Prateek Saxena, Zhenkai Liang Department of Computer Science National
Data Space Randomization
Data Space Randomization Sandeep Bhatkar 1 and R. Sekar 2 1 Symantec Research Laboratories, Culver City, CA 90230, USA 2 Stony Brook University, Stony Brook, NY 11794, USA Abstract. Over the past several
(Early) Memory Corruption Attacks
(Early) Memory Corruption Attacks CS-576 Systems Security Instructor: Georgios Portokalidis Fall 2018 Fall 2018 Stevens Institute of Technology 1 Memory Corruption Memory corruption occurs in a computer
Jonathan Afek, 1/8/07, BlackHat USA
Dangling Pointer Jonathan Afek, 1/8/07, BlackHat USA 1 Table of Contents What is a Dangling Pointer? Code Injection Object Overwriting Demonstration Remediation Summary Q&A 2 What is a Dangling Pointer?
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
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
Other array problems. Integer overflow. Outline. Integer overflow example. Signed and unsigned
Other array problems CSci 5271 Introduction to Computer Security Day 4: Low-level attacks Stephen McCamant University of Minnesota, Computer Science & Engineering Missing/wrong bounds check One unsigned
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
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,
Preventing Use-after-free with Dangling Pointers Nullification
Preventing Use-after-free with Dangling Pointers Nullification Byoungyoung Lee, Chengyu Song, Yeongjin Jang Tielei Wang, Taesoo Kim, Long Lu, Wenke Lee Georgia Institute of Technology Stony Brook University
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
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
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
Black Hat Webcast Series. C/C++ AppSec in 2014
Black Hat Webcast Series C/C++ AppSec in 2014 Who Am I Chris Rohlf Leaf SR (Security Research) - Founder / Consultant BlackHat Speaker { 2009, 2011, 2012 } BlackHat Review Board Member http://leafsr.com
HDFI: Hardware-Assisted Data-flow Isolation
HDFI: Hardware-Assisted Data-flow Isolation Presented by Ben Schreiber Chengyu Song 1, Hyungon Moon 2, Monjur Alam 1, Insu Yun 1, Byoungyoung Lee 1, Taesoo Kim 1, Wenke Lee 1, Yunheung Paek 2 1 Georgia
C and C++ Secure Coding 4-day course. Syllabus
C and C++ Secure Coding 4-day course Syllabus C and C++ Secure Coding 4-Day Course Course description Secure Programming is the last line of defense against attacks targeted toward our systems. This course
ECE 471 Embedded Systems Lecture 22
ECE 471 Embedded Systems Lecture 22 Vince Weaver http://www.eece.maine.edu/~vweaver vincent.weaver@maine.edu 31 October 2018 Don t forget HW#7 Announcements 1 Computer Security and why it matters for embedded
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:
Secure Coding Techniques
Secure Coding Techniques "... the world outside your function should be treated as hostile and bent upon your destruction" [Writing Secure Code, Howard and LeBlanc] "Distrust and caution are the parents
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:
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
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
Buffer Overflow Defenses
Buffer Overflow Defenses Some examples, pros, and cons of various defenses against buffer overflows. Caveats: 1. Not intended to be a complete list of products that defend against buffer overflows. 2.