Intrusion Detection and Malware Analysis

Transcription

1 Intrusion Detection and Malware Analysis Host Based Attacks Pavel Laskov Wilhelm Schickard Institute for Computer Science

2 Software security threats Modification of program code viruses and self-replicating code OS and API hooking Control flow hijacking integer overflow stack overflow heap overflow format string vulnerabilities heap spraying Code and data injection script injection (e.g. XSS) SQL injection

3 Stack overflow: a motivating example #include <stdio.h> #define SIZE 10 main() { int matrix[size*size]; int total_size = SIZE*SIZE; int* row_ind[size]; for (int i = 0; i <= total_size; i++) matrix[i] = i; for (int i = 0; i <= SIZE; i++) row_ind[i] = &matrix[i*size]; for (int i = 0; i <= SIZE; i++) printf("a[%d] = %d\n", i, *row_ind[i]); }

4 Process memory organization Process memory is partitioned into segments:.text - program code.data - initialized static data.bss - uninitialized static data heap - dynamically allocated memory stack - program call stack Each memory segment has appropriate permissions. Access operations violating these permissions cause the segmentation fault error. Higher memory addresses stack unused memory heap bss data text Lower memory addresses

5 Contiguous memory (buffer) allocation C/C++ static: int x[20] declaration outside any function; allocated in the.data segment automatic: int x[20] declaraiton inside some function; allocated on the stack dynamic: int *x = new int[20]; must be followed by delete to avoid memory leaks; allocated on the heap Java dynamic: int x = new int[20]; gets allocated in on the heap; automatic deallocation by garbage collector

6 Stack organization Stack is composed of frames Each frame comprises functions arguments return address frame pointer: the address of the start of the previous frame local variables Frames are pushed on the stack during function invocation and popped back after the return Previous frame Function arguments Return address Frame pointer Local variables Unused stack space Stack frame

7 Overwriting the return address A local buffer is allocated bottom-up, i.e. it starts at lower and ends at higher stack locations. Without proper bound checking a buffer content can overspill into adjacent upper stack area. By controlling buffer content, an attacker can overwrite the return address with an arbitrary value and hijack the execution flow. Previous frame Function arguments Return address Frame pointer Local variables Unused stack space Stack frame

8 Buffer overflow resume A well established exploitation technique. Requires knowledge of stack location. Can be prevented by stack protection mechanisms or address space layout randomization.

9 Heap overflow: a motivating example /* Log a message to syslog splitting the message into parts */ static void do_syslog( int pri, char * msg ) {... for ( p=msg, count=0; count < strlen(msg)/maxsysloglen + 1; count++ ) { if ( strlen(p) > MAXSYSLOGLEN ) { /* Break up the line into what will fit on one syslog(3) line * Try to break on a word boundary if possible. */ 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; [2] *tmp = '\0'; SYSLOG( pri, "%8.8s : %s", user_name, p ); /* restore saved character */ [3] *tmp = save; /* Eliminate leading whitespace */ [1] for ( p = tmp; *p!= ' '; p++ ) ; }... }}

10 Security issues and challenges The loop [1] does not check for the termination symbol \0. The pointer tmp can run beyond the buffer boundary.

11 Security issues and challenges The loop [1] does not check for the termination symbol \0. The pointer tmp can run beyond the buffer boundary. The pointer tmp is used for writing in [2]. Can corrupt memory beyond the buffer boundary...

12 Security issues and challenges The loop [1] does not check for the termination symbol \0. The pointer tmp can run beyond the buffer boundary. The pointer tmp is used for writing in [2]. Can corrupt memory beyond the buffer boundary......but is only allowed to write the value \0

13 Security issues and challenges The loop [1] does not check for the termination symbol \0. The pointer tmp can run beyond the buffer boundary. The pointer tmp is used for writing in [2]. Can corrupt memory beyond the buffer boundary......but is only allowed to write the value \0 The value of *tmp is restored in [3]. Only the call to syslog can do any damage.

14 Security issues and challenges The loop [1] does not check for the termination symbol \0. The pointer tmp can run beyond the buffer boundary. The pointer tmp is used for writing in [2]. Can corrupt memory beyond the buffer boundary......but is only allowed to write the value \0 The value of *tmp is restored in [3]. Only the call to syslog can do any damage. Does this suffice for an exploit?

15 dlmalloc dlmalloc internals Memory layout Memory layout: heap is divided into contiguous chunks of memory Heap is divided into contiguous chunks of memory. No no two two free free chunks chunks can may be be adjacent. physically adjacent Heap low addresses high addresses U U F U F U U Wilderness U... used chunk F... free chunk Wilderness... topmost free chunk Control Wilderness structures: chunk A special boundary tag preceeds each chunk. only chunk that may be increased (with system call sbrk) Getting treated extra as memory: bigger than all other chunks The largest unused chunk ( wilderness ) can be extended by a system call to sbrk() (if physical space is available). Internet Security 2

16 Maintenance of free chunks The total of 128 doubly-linked linked lists of free chunks (bins) are maintained. The first 62 lists store chunks of fixed length (16 to 512 bytes, aligned by 8 byte). The remaining 66 lists contain chunks of variable length within a certain ranges, computed according to a pre-defined schema. Entries are sorted by size in decreasing order in each list. Ties are resolved by age (FIFO). Pointers to the front and the back of each list are available.

17 The boundary tag definition #define INTERNAL_SIZE_T size_t struct malloc_chunk { INTERNAL_SIZE_T prev_size; /* size of the prev. chunk */ INTERNAL_SIZE_T size; /* size of this chunk */ struct malloc_chunk * fd; /* forward pointer */ struct malloc_chunk * bk; /* backward pointer */ }; Each field is 4 bytes long. The 3 least significant bit of the size (unused due to 8 byte alignment) are used to store two special flags: PREV_INUSE: previous chunk is used. IS_MMAPED: chunk is allocated using mmap.

18 Chunk layout Used chunk Unused chunk chunk prev_size chunk prev_size mem size fd size fd bk user_data bk unused nextchunk prev_size nextchunk prev_size

19 Allocation algorithm 1. Identify the appropriate chunk list. exact match for small chunks (less than 512 bytes) range match for large chunks 2. Traverse the chunk list from back to front until a large enough chunk is found. 3. If no appropriate chunks are found, continue with the list of next largest chunks. 4. If all else fails, carve-out a chunk from the Wilderness. Notes: Whenever a larger than requested chunk is found, it is trimmed to the requested size, and the remainder is put back into an appropriate chunk list. When an element is removed from a list, the fd and bk pointers are updated.

20 The unlink macro and its aftermath #define unlink( P, BK, FD ) { \ BK = P->bk; \ FD = P->fd; \ FD->bk = BK; \ BK->fd = FD; \ }

21 The unlink macro and its aftermath #define unlink( P, BK, FD ) { \ BK = P->bk; \ FD = P->fd; \ FD->bk = BK; \ BK->fd = FD; \ } Let s look at the special case...

22 The unlink macro and its aftermath #define unlink( P, BK, FD ) { \ BK = P->bk; \ FD = P->fd; \ FD->bk = BK; \ BK->fd = FD; \ } Let s look at the special case... P->fd = &free - 12 P->bk = &shellcode

23 The unlink macro and its aftermath #define unlink( P, BK, FD ) { \ BK = P->bk; \ FD = P->fd; \ FD->bk = BK; \ BK->fd = FD; \ } Let s look at the special case... P->fd = &free - 12 P->bk = &shellcode And the result is...

24 The unlink macro and its aftermath #define unlink( P, BK, FD ) { \ BK = P->bk; \ FD = P->fd; \ FD->bk = BK; \ BK->fd = FD; \ } Let s look at the special case... P->fd = &free - 12 P->bk = &shellcode And the result is... FD->bk = (P->fd)->bk = *((&free - 12) + 12) = &free := := BK = P->bk = &shellcode (!)

25 The heart of the hack How can we use this if we are only allowed to write \0?

26 The heart of the hack How can we use this if we are only allowed to write \0? By carefully chosing the input parameters to sudo, force such a constellation of memory chunks that the bk field of the chunk immediately following msg chunk contains the address ending with 2020.

27 The heart of the hack How can we use this if we are only allowed to write \0? By carefully chosing the input parameters to sudo, force such a constellation of memory chunks that the bk field of the chunk immediately following msg chunk contains the address ending with Line [2] of do_syslog() overruns the buffer (since [1] does not check for \0 ), overwrites the 20 byte with 00 and hence corrupts the border tag.

28 The heart of the hack How can we use this if we are only allowed to write \0? By carefully chosing the input parameters to sudo, force such a constellation of memory chunks that the bk field of the chunk immediately following msg chunk contains the address ending with Line [2] of do_syslog() overruns the buffer (since [1] does not check for \0 ), overwrites the 20 byte with 00 and hence corrupts the border tag. The new address points in the middle of another buffer controlled by the attacker.

29 The heart of the hack How can we use this if we are only allowed to write \0? By carefully chosing the input parameters to sudo, force such a constellation of memory chunks that the bk field of the chunk immediately following msg chunk contains the address ending with Line [2] of do_syslog() overruns the buffer (since [1] does not check for \0 ), overwrites the 20 byte with 00 and hence corrupts the border tag. The new address points in the middle of another buffer controlled by the attacker. That buffer contains addresses on the stack, where an attacker placed a fake boundary tag with malicious fd and bk fields.

30 What happens next? The chunk following msg gets allocated in a call to syslog() (crucial: another buffer arrangement magic!). The corrupted bk pointer gets copied by the unlink macro and remains in the control structures. During the next invocation of syslog(), the same allocation is requested, but with a fully fake boundary tag stored on the stack. The unlink macro overwrites a pointer to the free() function. The chunk gets deallocated by calling free().

31 Heap overflow resume Extremely subtle: a precise knowledge of and control over memory allocation in a program is required. difficult for remote exploitation Memory allocation mechanisms vary across platforms and operating systems. poor portability Applications supporting script languages allow an attacker to easily influence heap layout e.g., by writing scripts that perform (seemingly stupid ) memory allocations and deallocations. a dramatic increase in exploit reliability

32 Take-home message Software insecurity stems from attacker s ability to modify system resources criticial for program execution. One of the key sources for software insecurity is failed validation of user input. The latter is easier said than done.