2/9/18. Secure Coding. CYSE 411/AIT681 Secure Software Engineering. Agenda. Dynamic Memory Interface. Dynamic Memory Interface

Transcription

1 Secure Coding CYSE 411/AIT681 Secure Software Engineering Topic #9. Secure Coding: Dynamic Memory Instructor: Dr. Kun Sun String management Pointer Subterfuge Dynamic memory management Integer security Formatted output Race conditions Web security 2 Agenda Dynamic Memory Interface Programmer View of Dynamic Memory Dynamic memory functions Dynamic memory manager Common Errors Common Implementations and Exploits Doug Lea s Memory Allocator RtlHeap Mitigation Strategies Memory allocation in C: calloc() malloc() realloc() Memory deallocation in C: free() Memory allocation in C++ new operator. Memory deallocation in C++ delete operator. 3 4 Dynamic Memory Interface malloc(size_t size); Allocates size bytes and returns a pointer to the allocated memory. The memory is not cleared. free(void * p); Frees the memory space pointed to by p, which must have been returned by a previous call to malloc(), calloc(), or realloc(). If free(p) has already been called before, undefined behavior occurs. If p is NULL, no operation is performed. Dynamic Memory Interface realloc(void *p, size_t size); Changes the size of the memory block pointed to by p to size bytes. The contents will be unchanged to the minimum of the old and new sizes. Newly allocated memory will be uninitialized. If p is NULL, the call is equivalent to malloc(size). if size is equal to zero, the call is equivalent to free(p). Unless p is NULL, it must have been returned by an earlier call to malloc(), calloc(), or realloc()

2 Dynamic Memory Interface calloc(size_t nmemb, size_t size); Allocates memory for an array of nmemb elements of size bytes each and returns a pointer to the allocated memory. The memory is set to zero. How to make calloc() faster? One solution: 1. When OS gets any idle CPU time, it runs a simple process that goes around and zeroes out deallocated blocks of memory, and marks those blocks with a flag. 2. When calloc() is called, the OS first tries to find one of such prezeroed blocks and returns it. Memory Managers Manage both allocated and deallocated memory. Run as part of the client process. Use a variant of the dynamic storage allocation algorithm described by Knuth. Memory allocated for the client process and memory allocated for internal use, is all within the addressable memory space of the client process. 7 8 Memory Managers Buddy System Methods Buddy systems only allocate blocks of size 2 i. If request is for block of size m, allocate instead block of size 2 [log2 m]+1 or if necessary larger. When blocks are returned, try to coalesce them with their buddy, an adjacent block of the same size. Buddy System Example Memory Managers coalesce 9 10 Common Dynamic Memory Errors Initialization errors Failing to check return values Writing to already freed memory Freeing the same memory multiple times Improperly paired memory management functions Improper use of allocation functions Initialization Initialization Programmer assumes that malloc() zeroes block. Initializing large blocks of memory can impact performance and is not always necessary. Programmers have to initialize memory using memset() or by calling calloc(), which zeros the memory

3 Initialization Errors Sun Tarball Vulnerability /* return y = Ax */ int *matvec(int **A, int *x, int n) { int *y = malloc(n * sizeof(int)); int i, j; for (i = 0; i < n; i++) for (j = 0; j < n; j++) return y; y[i] += A[i][j] * x[j]; y[i] is initially zero, right? Vulnerability before tar The tar utility failed to initialize the dynamically allocated memory for reading a block of data from the disk. The last block may contain extra bytes from /etc/passwdfile To fix this problem if (sizeleft < bufsize) { /* Last read -- zero out area beyond.*/ bufsize = (int) sizeleft; count = bufsize % RECORDSIZE; if (count) memset (start->charptr + sizeleft, 0, (size_t) (RECORDSIZE -count)); Failing to Check Return Values Memory is a limited resource and can be exhausted. Memory allocation functions report status back to the caller. The application programmer should: determine when an error has occurred. handle the error in an appropriate manner. Check for Return Value of Malloc Standard malloc() function returns a NULL pointer if the requested space cannot be allocated. when memory cannot be allocated a consistent recovery plan is required: Even if the program just terminates with an error message int *i_ptr; i_ptr = (int *)malloc(sizeof(int)*nelements_wanted); if (i_ptr!= NULL) { i_ptr[i] = i; else { /* Couldn't get the memory - recover */ Referencing Freed Memory (Example) Referring to Freed Memory for (p = head; p!= NULL; p = p->next) free(p); for (p = head; p!= NULL; p = q) { q = p->next; free(p); wrong: accessing freed memory correct: using a temp variable Unlikely to result in a runtime error because memory is owned by the memory manager of the program. Freed memory can be allocated before a read. Read reads incorrect values. Writes destroy some other variable. Freed memory can be used by the memory manager. Writes can destroy memory manager metadata. Difficult to diagnose run-time errors. Basis for an exploit

4 Freeing Memory Multiple Times (1) Double-free: freeing the same chunk of memory twice, without it being reallocated in between Typical due to copy and past error Freeing Memory Multiple Times (2) Two linked list data structures can contain links to the shared common elements What happens if both lists are freed? several memory chunks will be freed twice In general, memory leaks are safer than double frees. x = malloc(n * sizeof(int)); /* manipulate x */ free(x); y = malloc(n * sizeof(int)); /* manipulate y */ free(x); Freeing Memory Multiple Times (3) Error processing Same memory chunk might be freed by the error handler phy has been allocated with 'devm_kzalloc', so we should not free it using an explicit 'kfree. A double free if the allocation of 'in_buf' fails. in_buf = kzalloc(in_buf_len, GFP_KERNEL); if (!in_buf) { rc = -ENOMEM; goto out_free_phy; phy->udev = usb_get_dev(interface_to_usbdev(interface)) ; phy->interface = interface; kfree(in_buf); out_free_phy: kfree(phy); return rc; in_buf = kzalloc(in_buf_len, GFP_KERNEL); if (!in_buf) return -ENOMEM; phy->udev = usb_get_dev(interface_to_usbde v(interface)); phy->interface = interface; kfree(in_buf); return rc; 21 Free chunks are kept in bins. Addressed by head. Chunks in bins are of approximately same size. Additional bin for recently freed memory. Free Chunks in dlmalloc Forward pointer to first chunk in list head element or last 4 bytes of prev. Forward pointer to next Back pointer to prev. Unused space : or last 4 bytes of prev. Forward pointer to next Back pointer to prev. Unused space : or last 4 bytes of prev. Forward pointer to next Back pointer to prev. : What behind malloc()? The unlink() macro removes a chunk from the double-linked list. 1. #define unlink(p, BK, FD) { \ 2. FD = P->fd; \ 3. BK = P->bk; \ 4. FD->bk = BK; \ BK->fd = FD; \ 6. What behind free()? When a chunk of memory is freed, it must be linked into the appropriate double-linked list in descending size order. See frontlink() code. 1. BK = bin; 2. FD = BK->fd; 3. if (FD!= BK) { 4. while (FD!= BK && S < chunksize(fd)) { FD = FD->fd; BK = FD->bk; P->bk = BK; 10. P->fd = FD; 11. FD->bk = BK->fd = P;

5 Double Free Success Conditions For a double-free exploit to be successful, two conditions must be met: The chunk to be freed must be isolated in memory (the adjacent chunks must be allocated). The bin into which the chunk is to be placed must be empty. Initial Conditions Empty Bin and Allocated Chunk The empty bin consists only of a header. The bin has no connection with the allocated chunk. bin-> Forward pointer to first chunk in list P-> of previous chunk, if unallocated of chunk, in bytes P User data : When P is Freed After the chunk is freed, it is put into the bin. The bin s forward and backward pointer point to the freed chunk. When P is freed the Second Time The second call to free on this chunk corrupts the bin structure. The bin's forward and back pointers still reference the chunk, but the chunk's forward and back pointers become selfreferential. bin-> Forward pointer to first chunk in list bin-> Forward pointer to first chunk in list P-> of previous chunk, if unallocated of chunk, in bytes P Forward pointer to next chunk in list Back pointer to previous chunk in list Unused space (may be 0 bytes long) of chunk BK = bin; 2. FD = BK->fd; 3. if (FD!= BK) { 4. while (FD!= BK && S < chunksize(fd)) { FD = FD->fd; BK = FD->bk; P->bk = BK; 10. P->fd = FD; 11. FD->bk = BK->fd = P; P-> of previous chunk, if unallocated of chunk, in bytes P Forward pointer to next chunk in list Back pointer to previous chunk in list Unused space (may be 0 bytes long) of chunk 28 When Request Memory Chunk of Same Invoking the unlink() macro to remove the chunk from the bin leaves the pointers unchanged, instead of the chunk being removed from the bin. As a result, if additional requests are made to allocate a chunk of the same size, the same chunk is returned over and over again. bin-> Forward pointer to first chunk in list Exploits This structure is exploitable. Real-world examples exist (see later). The technique is difficult. Freed chunks are not immediately put into a bin, but are cached. The double-freed chunk could be consolidated with other chunks. 1. #define unlink(p, BK, FD) { \ 2. FD = P->fd; \ 3. BK = P->bk; \ 4. FD->bk = BK; \ BK->fd = FD; \ 6. P-> of previous chunk, if unallocated of chunk, in bytes P Forward pointer to next chunk in list Back pointer to previous chunk in list Unused space (may be 0 bytes long) of chunk

6 Double-free Exploit Code 22. *((void **)(sixth+0))=(void *)(GOT_LOCATION- 12); 23. *((void **)(sixth+4))=(void *)shellcode_location; The target of this exploit is the first chunk allocated (line 13) When first is initially freed, it is put into a cache bin rather than a regular one 31 Allocating the second and fourth chunks prevents the third chunk from being consolidated Freeing the third chunk moves the first chunk to a regular bin. 32 Allocating the fifth chunk causes memory to be split off from the third chunk and, as a side effect, this results in the first chunk being moved to a regular bin Memory is now configured so that freeing the first chunk a second time sets up the double-free vulnerability When the sixth chunk is allocated, malloc() returns a pointer to the same chunk referenced by first The GOT address of the strcpy() function (minus 12) and the shellcode location are copied into this memory (lines 22-23)

7 The same memory chunk is allocated yet again as the seventh chunk on line when the chunk is allocated, the unlink() macro has the effect of copying the address of the shellcode into the address of the strcpy() function in the global offset table 38 When strcpy() is called control is transferred to the shell code. Writing to Freed Memory Writing to freed memory can also lead to vulnerabilities Almost identical example //free(first); 22. *((void **)(first+0))=(void *)(GOT_LOCATION-12); 23. *((void **)(first+4))=(void *)shellcode_location; 24. sixth = (void *)malloc(256); No double free. But a write to first. Call to malloc() replaces the address of stringcpy() with the address of the shellcode. Call to strcpy invokes the shellcode. Improperly Faired Memory Management Functions Always use new delete malloc free Improper pairing can work on some platforms sometimes, but code is not portable

8 Improper Use of Allocation Functions malloc(0) Can lead to memory management errors. A C runtime library can return a NULL pointer or return a pseudo-address The safest and most portable solution is to ensure zero-length allocation requests are not made. Mitigation Strategies NULL pointer Simplest strategy that prevents most dynamic memory errors. After a call to free, set the memory pointer to NULL. Prevents writing to freed memory. double-freeing memory. Does not prevent problems when pointer aliasing. Two pointers to the same structure. Consistency Use the same patterns for allocating and freeing memory. Allocate and deallocate in the same module, at the same level of abstraction. Match allocations and deallocations Summary Dynamic memory management in C and C++ programs is prone to software defects and security flaws. While heap-based vulnerabilities can be more difficult to exploit than their stack-based counterparts, programs with memory-related security flaws can still be vulnerable to attack. A combination of good programming practices and dynamic analysis can help to identify and eliminate these security flaws during development. 45 8