Exercise 6: Buffer Overflow and return-into-libc Attacks
|
|
- Martin Robertson
- 6 years ago
- Views:
Transcription
1 Technische Universität Darmstadt Fachbereich Informatik System Security Lab Prof. Dr.-Ing. Ahmad-Reza Sadeghi M.Sc. David Gens Exercise 6: Buffer Overflow and return-into-libc Attacks Course Secure, Trusted and Trustworthy Computing WS 2017/2018 Organization!!! BRING USB THUMB DRIVES; NO INTERNET ON LAB PCs!!!.txt or.pdf file for your solution (there will be no points for.doc/.docx).c files that were used to solve the exercise all zipped, file name should include last names of all group members seperated by a hyhpen with subject: [stc-ws17-ex06-sol] <last names of group members> latest , 23:59, to david.gens@cs.tu-darmstadt.de 1 Introduction In this exercise we will introduce the main principles of buffer overflow and return-into-libc attacks. In the practical assignment, you have to examine vulnerable sample programs and exploit these programs by means of a buffer overflow and return-into-libc attack. Despite the large amount of research that was made in the past decades, many applications still suffer from buffer overflow vulnerabilities. This is due to insufficient security-related assurance while developing applications and due to unsafe languages like C/C++. Such applications use dangerous functions that enforce no bounds-checking while retrieving input data from an untrusted user or from an untrusted device and therefore allows the adversary to launch buffer overflow attacks. The main target of a buffer overflow attack is usually to launch a (root) shell to the adversary in order to get full control over the system. A great deal of attention was paid to the W X security model [4] that marks a memory page either writable or executable. AMD and Intel even provide their new processors with a non-executable bit that can be enabled for each memory page. With W X, the adversary is no longer able to execute injected malicious code (that launches a shell to the adversary) because the injected code has to be placed into some writable (but not executable) memory area. However, a return-into-libc attack bypasses the W X security model as we will describe in Section 1.3. Before introducing the main principles of buffer overflow attacks in Section 1.2, we will briefly recall the x86 architecture in Section
2 Function Arguments Stack grows downwards Return address Saved Base Ptr Local Variables Stack frame Stack pointer Figure 1: The stack frame 1.1 Intel x86 Architecture The Intel x86 or IA-32 architecture [2] is a well-established instruction set architecture deployed in personal computers. The size of one native machine word is 32 bit whereas each word is stored in little Endian format. 1 Instructions are of variable-length, and unaligned memory access is allowed. To enable program execution, x86 provides eight general-purpose registers (%eax, %ebx, %ecx, %edx, %esi, %edi, %ebp, and %esp), six segment registers, one status register (%eflags), and the instruction pointer (%eip). Each general-purpose register is 32 bit, whereas some of them can be also accessed as a 16 bit (e.g., %ax) or as 8 bit registers (e.g., %ah and %al). The instruction pointer (%eip) holds the address of the next instruction to be executed. Usually, the instruction pointer is simply incremented for each instruction unless a branch instruction occurs. In this case the offset specified by the branch instruction is added to the current value of the instruction pointer. The traditional buffer overflow attack described by Aleph One [1] changes the flow of execution by overflowing a buffer allocated on the stack. Generally, the stack is a last in, first out (LIFO) memory area that provides two basic operations: pushing elements onto the stack (push instruction) and removing elements from the stack (pop instruction). Moreover, the stack is divided into individual stack frames (one stack frame per function) and each function call sets up a new stack frame on top of the stack. As depicted in Figure 1, a stack frame usually holds function arguments, the return address, the saved (old) base pointer (%ebp) and local variables. A special purpose register, the stack pointer (%esp), points to the top of the stack. On the x86 architecture the stack grows downwards (from high memory addresses to low memory addresses) and therefore the stack pointer has to point to the lowest address of the stack. Local variables and function arguments are accessed via an offset to the base pointer (therefore sometimes referred to as local frame pointer). Upon function return, control transfers to the code pointed to by the return address, i.e. control transfers back to the caller of the function. For this exercise, you don t need to have full knowledge over assembler programming. But for buffer overflow attacks it is very important that you understand the calling convention implemented on the x86 architecture. You need to know how the stack is arranged and for what purpose the %ebp and %esp registers are used. 1.2 Conventional Buffer Overflow Attack The main goal of a conventional buffer overflow attack [1] is to subvert the usual execution flow of a program by redirecting it to a malicious code that was not originally placed by the programmer. Basically, the attack consists of two tasks: (i) injecting new malicious code in some writable memory area and (ii) changing a code pointer in such a way that it points to the injected malicious code. The injected malicious code usually launches a shell to the adversary and is therefore often referred to as shellcode. The preferred code pointer to run the attack is the return address on the stack. However, also the saved base pointer can be used as an attack target, in the case the return address cannot be overwritten. This attack is referred to as frame pointer overwriting [3]. Figure 2 depicts a conventional buffer overflow on the stack described in the following. 1 Little Endian format means that the least significant byte (LSB) is stored at first. For instance, the string WORD, will be stored in memory as D, R, O, W 2
3 Program starts 1. vuln. func. called 4. waiting for input 2. Execution continues 5. vuln. func. returns 7. Shellcode New Ret Address Arbitrary data 6. Saved Base Ptr Arbitrary data local buffer Adversary 3. Stack frame of vulnerable function Figure 2: Conventional Buffer Overflow Attack 1. The vulnerable program is started by an authorized user. 2. After the program is initialized, user input is expected by the program that will afterwards be stored in a local buffer on the stack. 3. The adversary who has access to the program inserts input longer than expected by the program. The input of the adversary consists of arbitrary data (to fill the buffer and overwrite the saved base pointer), a new return address, and new code. The new return address points to the beginning of the injected code. 4. After retrieving user input, the current function continues execution until a return instruction is issued. 5. The return instruction of the function is reached. 6. The processor issues the return instruction and redirects control to the injected code because the adversary was able to change the return address in step The injected code is executed and it will perform its malicious behavior, e.g., typically launch a shell that the adversary can access and execute other commands on the machine. 1.3 Return-into-libc If the W X model [4] is enabled by the operating system (and supported by the hardware), the adversary will be no longer able to execute injected code, since a memory page is either marked writable or executable. Therefore, a more sophisticated attack was proposed to bypass defense mechanisms like W X by using a piece of code that resides in the process s image. The target for useful code pieces can particularly be found in the Unix C library libc which is linked to nearly every Unix program and provides a number of useful functions (to the adversary). Hence, the return address points to a valid function in libc like system or execve. The attack is referred to as return-into-libc [6]. Figure 3 depicts a return-into-libc attack described in the following. The adversary overfills a local buffer as in Section 1.2 and changes the return address to point to the libc function system in step 3. The system function allows the execution of one command with arguments. If, for instance, the target of the attack is to launch a shell, the adversary could execute the command /bin/sh. Above the address for the system function, the adversary pushes the return address of the exit function, which is another libc function, that closes the program. Further, another pointer is needed to reference the argument for the system function which is effectively the string /bin/sh that can be linked into the process image by setting up an environment variable. Finally, if the current vulnerable function returns in step 6, the system function is invoked with the argument /bin/sh to launch a new shell. After completion of the system function in step 7 (i.e., the shell is closed by the adversary), the exit function from libc is called (step 8) to close the program. 3
4 Program starts 7. libc system() {... return } exit() { } halt 1. vuln. func. called waiting for input 4. Environment variables 2. $SHELL= Pointer /bin/sh Address exit() Address system() "/bin/sh" Return Address of system( ) 6. Old Return Address of vuln. func. Execution continues 5. vuln. func. returns Arbitrary data Saved Base Ptr Arbitrary data local buffer Adversary 3. Stack frame of vulnerable function Figure 3: Return-into-libc attack that launches a shell to the adversary However, return-into-libc attacks are subject to some constraints. First, only those functions that reside in libc can be called by the adversary. If the designers of libc would remove functions that are of particular interest to the adversary (e.g., system, execve, etc.), crafting a return-into-libc attack will become more difficult. Second, the adversary can only execute straight-line code, i.e., he/she can only invoke functions one after the other. 1.4 GNU Debugger gdb In the practical exercise, we will often use the GNU debugger gdb. You will find a quick gdb reference card on the website You can start gdb as following: gdb program : Start program under control of gdb gdb -c core : Examine a core dump file with gdb The following gdb commands are neccessary for this exercise: quit: Exit gdb list: Show lines of the source code disassemble function : Disassemble a function disassemble main: Disassemble the main function break: Set a breakpoint break 5: Set a breakpoint at line number 5 break main: Set a breakpoint at the main function run [arglist] : Run the program with arguments arglist step: Execute until another line has been reached info registers: Print the processor register values. print [expression] : Show value of expression print $esp: Show the value of the %esp register x/[nuf] expression : Examine memory at address expression, whereas N indicates the Number of units to display, u the unit size, and f the printing format. x/4wx $esp: Show the top four (4) 32 bit words (w) on the stack ($esp) in hexadecimal (x) notation 4
5 2 Practical Assignments In the following you will launch buffer overflow and return-into-libc attacks. Note that Exercise 2.1 and 2.2 are largely inspired by an existing Buffer Overflow Primer ( groups?operation=view&groupid=4). Please take the following steps before starting with the exercise: 1. To enforce the generation of core files set the maximum size for core files to unlimited as follows: $ ulimit -c unlimited Usually a core file will be created if, for instance, a segmentation fault occurs during program execution. In such a case the core file holds the return address that caused the problem. You can analyze core files with the GNU debugger gdb. 2. Address Space Layout Randomization (ASLR) randomizes the base address of the stack. Since we need to know the precise addresses of libc functions and injected shellcode, launching a buffer overflow or a return-into-libc attack becomes more difficult if ALSR is enabled. Hence, before you start with the practical exercises, disable ASLR as following: $ sudo nano /proc/sys/kernel/randomize_va_space and replace the 2 with a Simple Buffer Overflow In your Buffer-Overflow folder you will find a program (vulnerable.c) suffering from a buffer overflow vulnerability. Compile the program as following: $ gcc vulnerable.c -o vulnerable -ggdb -mpreferred-stack-boundary=2 \ -fno-stack-protector We use the -ggdb option to include debugging information. The -fno-stack-protector option disables return address protection mechanisms like StackGuard or ProPolice. Finally, the -mpreferred-stack-boundary=2 option sets up the stack into dword-size increments. 1. Explain why the program suffers from a buffer overflow vulnerability? 2. How is the stack arranged directly before the buffer overflow occurs?... Bytes... Bytes... Bytes 3. Now, overflow the local buffer with A (0x41) characters and change the return address to a value of 0x ! How many A characters are at least necessary to change the return address to 0x ? (Hint: If you don t want to type all A characters manually, you can use perl to print as many A characters as you desire: $./vulnerable `perl -e 'print A x 27'`) 4. After you overflow the local buffer, the program crashes. Explain why a segmentation fault occurs? 5. The I_Never_Execute function within the vulnerable program is never called and will therefore never execute. Your task now is to change the return address of the main function by means of a buffer overflow in order to transfer execution to the I_Never_Execute function. Describe your steps taken (with gdb) and write down the start address of the I_Never_Execute function! Hint: Probably you want to insert the address of the I_Never_Execute function on the command line. This can be accomplished with perl as following: $./vulnerable `perl -e 'print A x 27. \xd3\xc2\xb1\xa0 ' ` 5
6 2.2 Exploit a Vulnerable Program As you may have recognized in the previous subsection, we are able to launch a buffer overflow attack on the vulnerable.c program. We are able to crash the program and are able to issue the I_Never_Execute function. But usually the main target of buffer overflow attacks is to spawn a new shell to the adversary. Therefore we need so-called shellcode. AlephOne [1] describes in detail how shellcode can be written/created for the x86 architecture. However, the most difficult part of a buffer overflow attack is to transfer execution to the injected shellcode. For the following task, we use the 24 byte shellcode from Our 24 byte shellcode should be stored into an environment variable (called $ENV). Afterwards the environment variable is used as an input to the vulnerable program. Instead of launching the attack to the vulnerable.c program, we will use the target.c program by Shacham [5] that we also need for the return-oriented programming exercise. This program establishes the stack frame for our target buffer into some fixed allocated memory area. Thus, we are able to bypass randomization techniques in use. Nevertheless, this program suffers from the same buffer overflow vulnerability as the vulnerability.c program. Compile the target.c program as following: $ gcc target.c -o target -ggdb -mpreferred-stack-boundary=2 \ -fno-stack-protector After you exploit the program you want to have full control (root privileges) over the system. Hence, change the permissions of the target program as following: $ sudo chown root target $ sudo chmod +s target The first command changes the owner of the target program to root. Further, the second command will set the setuid bit, which allows ordinary users to run the target program with the privileges of the owner of the file (here: root). In practice, many programs are compiled in such a way. For instance, the setuid bit in the passwd command assigns an ordinary user root privileges to change his password. 1. Fill the exploit.c program with an appropriate function that inserts the 24 byte shellcode into the allocated memory area at position buffer+4! 2. Compile and run the exploit.c program and check if the environment variable was established. Write down the appropriate command that you used in order to check the value of $ENV! 3. As you may have recognized, the return address stored in the environment variable is 0x You have to change the return address so that it holds the start address of the 24 byte shellcode (i.e., the address of buffer+4 in the exploit.c program) as following! (a) Start the target program under control of gdb! (b) Set a breakpoint directly before the vulnerable function (i.e., the function where the buffer overflow occurs) is called! (c) Run the vulnerable program with the environment variable ($ENV) as input! (d) Once the breakpoint has been reached, examine the stack and find the return address of the overflow() function! Write down the return address of the overflow() function and describe how you determined the return address! (e) Make one step in the program! (The buffer is now overflown) (f) Once again, examine the stack and check if the return address has been changed to 0x Further, find out and write down the start address of the injected shellcode! (g) Now close gdb and change the return address in the exploit.c program to the address you determined in the step before! 4. Recompile and run the exploit.c program! Afterwards start the target program with input $ENV that should now launch a root shell to you. To check if you really become root issue the command $ whoami before and after the buffer overflow attack! Now save a copy of your exploit.c program! 6
7 2.3 Return-into-libc As we mentioned in Section 1.3, conventional buffer overflows cannot be launched if the W X security model is in use, because the adversary is no longer able to execute injected shellcode. Therefore, in the following we will use only code that resides in the process s image and launch a shell by means of a return-into-libc attack. Ideally, we want to issue the command system( /bin/sh ) that should launch a shell to us without injecting any own code. After the shell is closed by the adversary, the program should terminate without a segmentation fault. Thus, we make use of the exit function as we described in Section Since we want to invoke the system function from libc, start the target program with gdb and find out the address of the system function. Write down the precise address of the system function! 2. To close the program, we need the address of the exit function. Determine and write down the appropriate address! 3. You also need the address of the string /bin/sh. The easiest way for finding such string in the address space is by storing the string into an environment variable. Afterwards you just need the address of the environment variable. Therefore complete the following steps: (a) Create an environment variable named $MYSHELL with the /bin/sh string as content! (Hint: Use the export command on the command line) (b) In your code folder you will find a program getenv.c that expects as input an environment variable and will give you as result the appropriate address. Run the getenv.c program and write down the address of $MYSHELL! 4. Now you have all addresses you need to launch the return-into-libc attack. Run the attack and write down the payload you used! As before, check if you are root with the command$ whoami! 7
8 References [1] Aleph One. Smashing the stack for fun and profit. Phrack Magazine, 49(14), [2] Intel Corporation. Intel 64 and ia-32 architectures software developer s manuals. com/products/processor/manuals/. [3] klog. The frame pointer overwrite. Phrack Magazine, 55(9), [4] PaX Team. [5] H. Shacham. The geometry of innocent flesh on the bone: Return-into-libc without function calls (on the x86). In CCS 07: Proceedings of the 14th ACM Conference on Computer and Communications Security, pages ACM, [6] Solar Designer. "return-to-libc" attack. Bugtraq,
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
More informationbuffer overflow exploitation
buffer overflow exploitation Samuele Andreoli, Nicolò Fornari, Giuseppe Vitto May 11, 2016 University of Trento Introduction 1 introduction A Buffer Overflow is an anomaly where a program, while writing
More informationBuffer Overflow Vulnerability
Buffer Overflow Vulnerability 1 Buffer Overflow Vulnerability Copyright c 2006 2014 Wenliang Du, Syracuse University. The development of this document is/was funded by three grants from the US National
More informationLab 2: Buffer Overflows
Department of Computer Science: Cyber Security Practice Lab 2: Buffer Overflows Introduction In this lab, you will learn how buffer overflows and other memory vulnerabilities are used to takeover vulnerable
More informationThe 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
More informationCNIT 127: Exploit Development. Ch 2: Stack Overflows in Linux
CNIT 127: Exploit Development Ch 2: Stack Overflows in Linux Stack-based Buffer Overflows Most popular and best understood exploitation method Aleph One's "Smashing the Stack for Fun and Profit" (1996)
More informationLecture 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
More informationCS 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
More informationBasic Buffer Overflows
Operating Systems Security Basic Buffer Overflows (Stack Smashing) Computer Security & OS lab. Cho, Seong-je ( 조성제 ) Fall, 2018 sjcho at dankook.ac.kr Chapter 10 Buffer Overflow 2 Contents Virtual Memory
More informationBuffer Overflow Vulnerability Lab Due: September 06, 2018, Thursday (Noon) Submit your lab report through to
CPSC 8810 Fall 2018 Lab 1 1 Buffer Overflow Vulnerability Lab Due: September 06, 2018, Thursday (Noon) Submit your lab report through email to lcheng2@clemson.edu Copyright c 2006-2014 Wenliang Du, Syracuse
More informationCMPSC 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
More informationReturn-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
More informationCNIT 127: Exploit Development. Ch 3: Shellcode. Updated
CNIT 127: Exploit Development Ch 3: Shellcode Updated 1-30-17 Topics Protection rings Syscalls Shellcode nasm Assembler ld GNU Linker objdump to see contents of object files strace System Call Tracer Removing
More informationAdvanced 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
More informationRobust 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,
More informationBuffer Overflows Defending against arbitrary code insertion and execution
www.harmonysecurity.com info@harmonysecurity.com Buffer Overflows Defending against arbitrary code insertion and execution By Stephen Fewer Contents 1 Introduction 2 1.1 Where does the problem lie? 2 1.1.1
More informationISA 564, Laboratory I: Buffer Overflows
ISA 564, Laboratory I: Buffer Overflows Lab Submission Instructions To complete the lab, you need to submit the compressed files (either tar or zip) using the GMU Blackboard system. Please make sure that
More informationRuntime 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
More informationExploits 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
More informationBeyond 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
More informationSecure 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
More informationSelected 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),
More informationRoadmap: Security in the software lifecycle. Memory corruption vulnerabilities
Secure Programming Lecture 3: Memory Corruption I (introduction) David Aspinall, Informatics @ Edinburgh 24th January 2019 Roadmap: Security in the software lifecycle Security is considered at different
More informationOutline. 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
More informationUniversità Ca Foscari Venezia
Stack Overflow Security 1 2018-19 Università Ca Foscari Venezia www.dais.unive.it/~focardi secgroup.dais.unive.it Introduction Buffer overflow is due to careless programming in unsafe languages like C
More informationHomework 1 CS 642: Information Security
Homework 1 CS 642: Information Security September 22, 2012 This homework assignment tasks you with understanding vulnerabilities in five target programs. You may (optionally) work with a partner. It is
More informationBuffer Overflow Vulnerability Lab
SEED Labs Buffer Overflow Vulnerability Lab 1 Buffer Overflow Vulnerability Lab Copyright c 2006-2013 Wenliang Du, Syracuse University. The development of this document is/was funded by three grants from
More informationIs stack overflow still a problem?
Morris Worm (1998) Code Red (2001) Secure Programming Lecture 4: Memory Corruption II (Stack Overflows) David Aspinall, Informatics @ Edinburgh 31st January 2017 Memory corruption Buffer overflow remains
More informationCNIT 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
More informationArchitecture-level Security Vulnerabilities
Architecture-level Security Vulnerabilities Björn Döbel Outline How stacks work Smashing the stack for fun and profit Preventing stack smashing attacks Circumventing stack smashing prevention The Battlefield:
More information20: 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
More informationCSE 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
More informationThis 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
More informationCSC 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
More informationIntroduction 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.
More information1 Recommended Readings
CSC 482/582 Assignment #5 Buffer Overflow Due: November 14, 2013 The learning objective of this assignment is for students to gain first-hand experience with a buffer overflow vulnerability, applying what
More informationSecurity 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
More informationCS 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.
More informationString 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:
More informationLecture 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
More informationProgram Exploitation Intro
Program Exploitation Intro x86 Assembly 04//2018 Security 1 Univeristà Ca Foscari, Venezia What is Program Exploitation "Making a program do something unexpected and not planned" The right bugs can be
More informationCS4264 Programming Assignment 1 Buffer Overflow Vulnerability Due 02/21/2018 at 5:00 PM EST Submit through CANVAS
Laboratory for Computer Security Education 1 CS4264 Programming Assignment 1 Buffer Overflow Vulnerability Due 02/21/2018 at 5:00 PM EST Submit through CANVAS Copyright c Wenliang Du, Syracuse University.
More informationCMSC 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
More informationIntroduction. Overview and Getting Started. CS 161 Computer Security Lab 1 Buffer Overflows v.01 Due Date: September 17, 2012 by 11:59pm
Dawn Song Fall 2012 CS 161 Computer Security Lab 1 Buffer Overflows v.01 Due Date: September 17, 2012 by 11:59pm Introduction In this lab, you will get a hands-on approach to circumventing user permissions
More informationAdvanced 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
More informationArchitecture-level Security Vulnerabilities. Julian Stecklina
Architecture-level Security Vulnerabilities Julian Stecklina Outline How stacks work Smashing the stack for fun and profit Preventing stack smashing attacks Circumventing stack smashing prevention The
More informationProject 1 Notes and Demo
Project 1 Notes and Demo Overview You ll be given the source code for 7 short buggy programs (target[1-7].c). These programs will be installed with setuid root Your job is to write exploits (sploit[1-7].c)
More information1 Lab Overview. 2 Resources Required. CSC 666 Lab #11 Buffer Overflow November 29, 2012
CSC 666 Lab #11 Buffer Overflow November 29, 2012 Copyright c 2012 James Walden, Northern Kentucky University. Original document version c 2006-2012 Wenliang Du, Syracuse University. The development of
More informationBuffer overflow is still one of the most common vulnerabilities being discovered and exploited in commodity software.
Outline Morris Worm (1998) Infamous attacks Secure Programming Lecture 4: Memory Corruption II (Stack Overflows) David Aspinall, Informatics @ Edinburgh 23rd January 2014 Recap Simple overflow exploit
More informationStack 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)
More informationAdvanced 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
More informationInject 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
More informationBuffer 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
More informationExploiting 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
More informationBuffer Overflows. A brief Introduction to the detection and prevention of buffer overflows for intermediate programmers.
Buffer Overflows A brief Introduction to the detection and prevention of buffer overflows for intermediate programmers. By: Brian Roberts What is a buffer overflow? In languages that deal with data structures
More informationX86 Review Process Layout, ISA, etc. CS642: Computer Security. Drew Davidson
X86 Review Process Layout, ISA, etc. CS642: Computer Security Drew Davidson davidson@cs.wisc.edu From Last Time ACL-based permissions (UNIX style) Read, Write, execute can be restricted on users and groups
More informationCS Programming Languages Fall Homework #2
CS 345 - Programming Languages Fall 2010 Homework #2 Due: 2pm CDT (in class), September 30, 2010 Collaboration policy This assignment can be done in teams at most two students. Any cheating (e.g., submitting
More informationBuffer 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];
More informationBetriebssysteme 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
More informationProject 4: Application Security
CS461/ECE422 October 23, 2015 Computer Security I Project 4: Application Security Project 4: Application Security This project is split into two parts, with the first checkpoint due on Friday, October
More informationIntro to x86 Binaries. From ASM to exploit
Intro to x86 Binaries From ASM to exploit Intro to x86 Binaries I lied lets do a quick ctf team thing Organization Ideas? Do we need to a real structure right now? Mailing list is OTW How do we get more
More informationCSE 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
More informationCS 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
More informationBuffer Overflow Attack
Chapter 4 This is a sample chapter in the book titled "Computer Security: A Hands-on Approach" authored by Wenliang Du. Buffer Overflow Attack From Morris worm in 1988, Code Red worm in 2001, SQL Slammer
More informationCSE 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
More informationBuffer Overflow and Protection Technology. Department of Computer Science,
Buffer Overflow and Protection Technology Department of Computer Science, Lorenzo Cavallaro Andrea Lanzi Table of Contents Introduction
More informationCS 392/681 Lab 6 Experiencing Buffer Overflows and Format String Vulnerabilities
CS 392/681 Lab 6 Experiencing Buffer Overflows and Format String Vulnerabilities Given: November 13, 2003 Due: November 20, 2003 1 Motivation Buffer overflows and format string vulnerabilities are widespread
More informationx86 assembly CS449 Fall 2017
x86 assembly CS449 Fall 2017 x86 is a CISC CISC (Complex Instruction Set Computer) e.g. x86 Hundreds of (complex) instructions Only a handful of registers RISC (Reduced Instruction Set Computer) e.g. MIPS
More informationBuffer Overflow. An Introduction
Buffer Overflow An Introduction Workshop Flow-1 Revision (4-10) How a program runs Registers Memory Layout of a Process Layout of a StackFrame Layout of stack frame using GDB and looking at Assembly code
More informationBUFFER 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
More informationThe first Secure Programming Laboratory will be today! 3pm-6pm in Forrest Hill labs 1.B31, 1.B32.
Lab session this afternoon Memory corruption attacks Secure Programming Lecture 6: Memory Corruption IV (Countermeasures) David Aspinall, Informatics @ Edinburgh 2nd February 2016 The first Secure Programming
More informationSmashing 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
More informationFrom 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:
More informationENEE 757 Buffer Overflow Homework
Buffer Overflow Homework Copyright 2006-2014 Wenliang Du, Syracuse University. The development of this document is/was funded by three grants from the US National Science Foundation: Awards No. 0231122
More informationSecure Programming Lecture 6: Memory Corruption IV (Countermeasures)
Secure Programming Lecture 6: Memory Corruption IV (Countermeasures) David Aspinall, Informatics @ Edinburgh 2nd February 2016 Outline Announcement Recap Containment and curtailment Tamper detection Memory
More informationThe geometry of innocent flesh on the bone: Return-into-libc without function calls (on the x86) Hovav Shacham presented by: Fabian Fäßler
The geometry of innocent flesh on the bone: Return-into-libc without function calls (on the x86) Hovav Shacham presented by: Fabian Fäßler return-oriented programming Hovav Shacham presented by: Fabian
More informationBuffer-Overflow Attacks on the Stack
Computer Systems Buffer-Overflow Attacks on the Stack Introduction A buffer overflow occurs when a program, while writing data to a buffer, overruns the buffer's boundary and overwrites memory in adjacent
More informationBiography. 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
More informationStack-Based Buffer Overflow Explained. Marc Koser. East Carolina University. ICTN 4040: Enterprise Information Security
Running Head: BUFFER OVERFLOW 1 Stack-Based Buffer Overflow Explained Marc Koser East Carolina University ICTN 4040: Enterprise Information Security Instructor: Dr. Philip Lunsford 03-17-2015 Prepared
More informationIntroduction to Reverse Engineering. Alan Padilla, Ricardo Alanis, Stephen Ballenger, Luke Castro, Jake Rawlins
Introduction to Reverse Engineering Alan Padilla, Ricardo Alanis, Stephen Ballenger, Luke Castro, Jake Rawlins Reverse Engineering (of Software) What is it? What is it for? Binary exploitation (the cool
More informationCS 645: Lecture 3 Software Vulnerabilities. Rachel Greenstadt July 3, 2013
CS 645: Lecture 3 Software Vulnerabilities Rachel Greenstadt July 3, 2013 Project 1: Software exploits Individual project - done in virtual machine environment This assignment is hard. Don t leave it until
More informationPractical Malware Analysis
Practical Malware Analysis Ch 4: A Crash Course in x86 Disassembly Revised 1-16-7 Basic Techniques Basic static analysis Looks at malware from the outside Basic dynamic analysis Only shows you how the
More informationBuffer Overflow Attack (AskCypert CLaaS)
Buffer Overflow Attack (AskCypert CLaaS) ---------------------- BufferOverflow.c code 1. int main(int arg c, char** argv) 2. { 3. char name[64]; 4. printf( Addr;%p\n, name); 5. strcpy(name, argv[1]); 6.
More informationCSC 2400: Computer Systems. Using the Stack for Function Calls
CSC 24: Computer Systems Using the Stack for Function Calls Lecture Goals Challenges of supporting functions! Providing information for the called function Function arguments and local variables! Allowing
More information2 Resources Required. 3 Assignment Tasks. 3.1 Initial setup
CSC 482/582 Assignment #3 Buffer Overflow Due: October 15, 2015 The learning objective of this assignment is for students to gain first-hand experience with a buffer overflow vulnerability, applying what
More informationBuffer-Overflow Attacks on the Stack
Computer Systems Buffer-Overflow Attacks on the Stack Introduction A buffer overflow occurs when a program, while writing data to a buffer, overruns the buffer's boundary and overwrites memory in adjacent
More informationFunction Calls COS 217. Reading: Chapter 4 of Programming From the Ground Up (available online from the course Web site)
Function Calls COS 217 Reading: Chapter 4 of Programming From the Ground Up (available online from the course Web site) 1 Goals of Today s Lecture Finishing introduction to assembly language o EFLAGS register
More informationCS155: Computer Security Spring Project #1. Due: Part 1: Thursday, April pm, Part 2: Monday, April pm.
CS155: Computer Security Spring 2008 Project #1 Due: Part 1: Thursday, April 17-1159 pm, Part 2: Monday, April 21-1159 pm. Goal 1. The goal of this assignment is to gain hands-on experience with the effect
More informationShellbased Wargaming
Shellbased Wargaming Abstract Wargaming is a hands-on way to learn about computer security and common programming mistakes. This document is intended for readers new to the subject and who are interested
More informationLecture 15 Intel Manual, Vol. 1, Chapter 3. Fri, Mar 6, Hampden-Sydney College. The x86 Architecture. Robb T. Koether. Overview of the x86
Lecture 15 Intel Manual, Vol. 1, Chapter 3 Hampden-Sydney College Fri, Mar 6, 2009 Outline 1 2 Overview See the reference IA-32 Intel Software Developer s Manual Volume 1: Basic, Chapter 3. Instructions
More informationCS642: Computer Security
X86 Review Process Layout, ISA, etc. CS642: Computer Security Drew Davidson davidson@cs.wisc.edu From Last Week ACL- based permissions (UNIX style) Read, Write, execute can be restricted on users and groups
More informationSYSTEM CALL IMPLEMENTATION. CS124 Operating Systems Fall , Lecture 14
SYSTEM CALL IMPLEMENTATION CS124 Operating Systems Fall 2017-2018, Lecture 14 2 User Processes and System Calls Previously stated that user applications interact with the kernel via system calls Typically
More informationSyscall Proxying. Simulating Remote Execution. Maximiliano Cáceres.
Syscall Proxying Maximiliano Cáceres maximiliano.caceres@corest.com Caesars Palace, Las Vegas, NV, USA July 31st, 2002 Agenda General Concepts Syscall Proxying A first implementation Optimizing for size
More informationLab 10: Introduction to x86 Assembly
CS342 Computer Security Handout # 8 Prof. Lyn Turbak Wednesday, Nov. 07, 2012 Wellesley College Revised Nov. 09, 2012 Lab 10: Introduction to x86 Assembly Revisions: Nov. 9 The sos O3.s file on p. 10 was
More informationSoftware 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,
More informationEthical Hacking: Preventing & Writing Buffer Overflow Exploits
Ethical Hacking: Preventing & Writing Buffer Overflow Exploits Rochester Security Summit 2014 Rochester OWASP Chapter Lead Ralph Durkee - Durkee Consulting, Inc. info@rd1.net Ralph Durkee Background Founder
More informationCSE 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.
More informationCS 642 Homework #4. Due Date: 11:59 p.m. on Tuesday, May 1, Warning!
CS 642 Homework #4 Due Date: 11:59 p.m. on Tuesday, May 1, 2007 Warning! In this assignment, you will construct and launch attacks against a vulnerable computer on the CS network. The network administrators
More informationECS 153 Discussion Section. April 6, 2015
ECS 153 Discussion Section April 6, 2015 1 What We ll Cover Goal: To discuss buffer overflows in detail Stack- based buffer overflows Smashing the stack : execution from the stack ARC (or return- to- libc)
More informationSecure 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
More information