Lecture 1: Buffer Overflows

Transcription

1 CS5431 Computer Security Practicum Spring 2017 January 27, Conficker Lecture 1: Buffer Overflows Instructor: Eleanor Birrell In November 2008, a new piece of malware was observed in the wild. This exploit, soon known as Conficker, issued a remote procedure call (RPC) to a target system requesting the file path string \c\..\..\aaaaaaaaaaaaaaaaaaaaaaaaaaaaa This carefully crafted request exploited a bug in the Windows program NetPathCanonicalize on affected Windows machines, triggering a buffer overflow and turning the target machine into a bot under the control of the Conficker botnet. Infected machines checked for instructions from pseudo-randomly generated command-and-control servers; the resulting botnet could be deployed as a service for delivering spam or implementing distributed denial of service (DDOS) attacks. Within two months, an estimated 9-15 million machines were infected. 2 Traditional Stack Smashing A buffer overflow occurs when the data written to a buffer is longer than the space allocated to that buffer. Depending on the location of the allocated buffer and the length of the overflow, additional data written to a buffer might overwrite other data, code, or return addresses. In most cases, an accidental buffer overflow will result in incorrect execution (e.g., when it overwrites other data values), a program crash (e.g., when it overwrites values the target program doesn t have permission to access), or no effect (e.g., when it overwrites values that are not accessed after that point). Malicious buffer overflows, however, can exploit buffer vulnerabilities to force the system to run exploit code. The most common form of buffer overflow attack often called stack smashing the attacker overwriting the return address pointer with a pointer to the exploit code. 2.1 Program Stacks Before we can look at stack smashing in detail, we need to remember some of the details about how stacks are implemented. When programs are executed, the operating system stores relevant state in memory. Executable code is stored at one end of memory, static data is stored next to code, and the stack and the heap occupy the remaining memory. The heap is used for dynamically allocated memory (ie, any time malloc is used). The stack is used primarily for managing nested calls to procedures; it also stores local variables. When a procedure A calls a procedure B, A pushes a stack frame onto the stack; a stack frame is comprised of A s return address (the current value of the program counter), 1-1

2 Procedure A call B B Param 3 B Param 2 B Param 1 Ret Addr Ptr A Stack Ptr A B Local Var 1 B Local Var 2 C Param 2 C Param 1 Ret Addr Ptr B Stack Ptr B Procedure B call C Procedure C Figure 1: The stack configuration after nested procedure calls a pointer to the end of A s section of the stack (used to recover in case B has an error), as well as the parameters for B. Local variables created by B (possibly including buffers) are pushed onto the stack on top of the previous stack frame, and the process iterates when B calls its own subroutines. 2.2 Stack Smashing Attacks In most early examples, the malicious code was written earlier in the same buffer, and the pointer was overwritten to point back to the beginning of the buffer. Note that this requires careful programming to ensure that the exploit code fits in the available space; exploit code is often written directly in assembly code to conserve space. An example is show in Figure 4. Procedure A call B B Param 3 B Param 2 B Param 1 New Ret Addr Ptr New Stack Ptr Overflow Buffer B Local Var 2? Procedure B Buffer[20]; Figure 2: Stack configuration after a traditional stack smashing attack. 1-2

3 2.3 Countermeasure: Stack Canaries Buffer overflows have been a known problem for a long time. The Morris worm leveraged a buffer overflow vulnerability to spread across the ARPANET in Consequently, several differently countermeasures have been developed to defend against such exploits. In 1998, a researcher named Crispin Cowan observed that this attack pattern could be leveraged to defend against buffer overflow attacks. His system, called StackGuard, placed a special value called canary value 1 immediately below the return address pointer. When a procedure returned, the operating system would check the integrity of the canary value; if it had been modified, the system would signal an error. Problem solved? Not quite. The canary value needs to be something that the operating system can efficiently verify. However, if the system uses something simple say the constant value 0xf213ea08 then the defense will work (usually) until the attacker learns about the defense. 2 After learning about the defense, an attacker will modify the exploit to bypass the defense by, say, alternating the value of the malicious address with the canary value. Stackguard employed two alternative methods to prevent an attacker from successfully forging the stack canary. The first method was a stack canary comprised of the common termination symbols for C string libraries: \0, CR, LF, and EOF. An attacker couldn t use common C library functions to embed these characters in an overflow buffer because those functions would terminate when they reached their termination symbol. The second method was 32-bit random number chosen fresh each time the program was run. Since the canary value is chosen fresh each time the program is invoked and is never disclosed to anyone, an attacker is unlikely to guess the correct value to forge. Other types of canaries have also been proposed. So do stack canaries work? They have low overhead, and they do mitigate buffer overflow attacks by making such attacks harder to successfully execute. However, a sufficiently skilled and determined adversary will often be able to bypass a stack canary. 3 Traditional Heap Smashing In early days, defenders focused their efforts on security stack-based buffer overflows. Countermeasures like stack canaries focused exclusively on protecting the integrity of the stack. Overflows that occurred on the heap were assumed not to be exploitable. However, this assumption turned out to be inaccurate. 1 Canary values are named after the canaries traditionally carried by miners. Canaries need more oxygen than humans, so if the oxygen level in the mine dropped, the canary would die, notifying the miners in time for them to safely evacuate. 2 Relying on your defensive techniques remaining a secret a system is often called security through obscurity. It is generally regarded by the security community as ineffective; historically, attackers eventually find out how a system is secured, and defenses that rely on the attacker not knowing the defense strategy have repeatedly been compromised. 1-3

4 3.1 Heaps Heaps contain dynamically allocated memory (e.g., memory returned by malloc). Ever memory allocation a program makes is represented by a data structure called a chunk. A chunk consists of (1) metadata and (2) the memory returned to the program. Chunks are saved to the heap. The chunk metadata structure contains the following fields: INTERNAL_SIZE_T prev_size; /* size of prev chunk (if free) */ INTERNAL_SIZE_T size; /* size of chunk */ struct chunk * fd; /* double links -- used only if free */ struct chunk * bw; size stores the size of the current chunk, in bytes. Since chunks are always 8-byte aligned, the last three bits are redundant and are actually repurposed; the first (least significant) bit is used to indicate whether the previous chunk is currently allocated. prev_size stores the size of the previous chunk, if the previous chunk is currently free. Chunk C (in use) size C ( ) prev size C (null) Chunk B (in use) size B ( ) prev size B (01101) Chunk A (free) bk A fw A size A ( ) prev size A Figure 3: Example heap configuration showing one free chunk and two in-use chunks. Free chunks are stored by size in doubly linked lists using the pointer fields fw and bk. When a chunk is freed, it checks whether the chunk in front of it is already free (by checking the least significant bit of its size field). If so, it merges the two chunks and move the combined chunk to the doubly-linked list for free chunks of the new (combined) size. If not, it simply adds itself to the doubly-linked list for free chunks of its own size. Meta-data for in-use chunks does not contain the pointer fields fw and bk; the memory returned to the program starts where fw was stored prior to allocation. 1-4

5 Chunk C (in use) size C ( ) prev size C (00110) Exploit code fake bk B fake fw B size B ( ) prev size B (NULL) fptr Figure 4: Heap configuration after a buffer overflow attack (before Chunk B is freed). 3.2 Heap Smashing Attacks The key observation that enables heap smashing attacks is that removing an element from a doubly-linked list involves overwriting memory locations (supposedly the fw and bk pointers of the adjacent chunks) with new values (supposedly linking those two chunks together). A successful heap smashing attack proceeds by (1) writing a fake fw pointer (pointing to a targeted function pointer) to the beginning of buffer, (2) writing a fake bk pointer (pointing at the next memory addresss, soon to contain exploit code) to the second address of the buffer, (3) writing the exploit code starting from the third address of the buffer, (4) overwritting prev_size field of the next chunk to contain the size of the current chunk, and (5) overwriting the sizefield of the next chunk to indicate that the target chunk is free. When the next chunk is freed, the memory management code will (incorrectly) observe that the previous chunk is already free and will move the merged two chunks to the appropriate doubly-linked list of free chunks; the unlinking code will copy the value of bk (now the location of the exploit code) to the location indicated by fw (now the target function pointer). When the function pointer is subsequently dereferenced, the exploit code will be run. 3.3 Countermeasure: Memory Tagging In a tagged architecture, every machine word has one or more bits that encode the access permissions for that word. These access bits can be set only by priviledged (OS) instructions. The bits are tested every time the word is accessed. Attempts to access a word without appropriate permissions result in an error. Access bits can also distinguish types of access (read, write, execute) or classes of data (numeric, character, address, or pointer). A tagged architecture could effectively mitigate buffer overflow attacks by designating return address pointers as privileged words and/or as pointer words. However, tagged architectures are not generally compatible with legacy code. And most current operating 1-5

6 systems (including Windows, Mac OS and most Linux flavors) include legacy code dating back twenty years or more. Tagged architectures have been deployed in some systems (page-level tagging is also now available on most processors), and more are under development by major vendors like Intel, but the lack of code compatibility has precluded widespread use. A software analog of hardware tagging is Write or Execute only (W X) pages, sometimes called executable space protection. Under this approach memory is tagged in software at the granularity of a page as either writable or executable, but not both. Executable space protection is widely deployed; it has shipped with Windows since XP SP2, with OX X since Leopard (10.5), and is available on most Linux flavors. When this defense is enabled, an attacker will be unable to execute code written to writable pages (e.g., code written inside the overflowed buffer) thereby nullifying traditional buffer overflow attacks targeting either the heap or the stack. However, some applications (e.g., Javascript, Flash) rely on an executable stack. Also, sophisticated attackers can sometimes trigger a memory mapping routine that marks the attack code as executable, bypassing executable space protections. 4 Code-reuse Attacks Code-reuse attacks are a class of advanced stack smashing techniques that bypasses the protection offered by executable space protection. At a high level, instead of altering the return address pointer to point to code that has just been written on the stack, codereuse attacks overwrite the pointer to point to code that already resides on the target system, either functions in the target program or functions in loaded libraries. Code-reuse attacks work by overwriting the return address pointer to point to the location of the appropriate code in memory, overwriting the stack addresses beyond the new return address pointer with a fake stack frame for the new function, and overwriting the stack pointer to point to the beginning of the fake stack frame. Complex exploits can be constructed by chaining together available functions. An example code-reuse attack is depicted in Figure Return-into-libc A common class of code-reuse attacks known as return-into-libc attacks targets code in the standard c library. For example, in the example shown in Figure 5, the attacker executes the function exec("/bin/sh"). This approach is powerful because libc includes the system call API and because it is loaded into every Unix program. In fact, the functions in libc form a Turing complete programming language. 1-6

7 Procedure A call B exec? \sh\0" "\bin String Ptr Fake Ret Addr Ptr Fake Stack Ptr New Ret Addr Ptr New Stack Ptr OverFlow Buffer B Local Var 2 Procedure B Buffer[20]; Figure 5: Stack configuration after a return-into-libc attack. 4.2 Countermeasure: Address-Space Layout Randomization The key observation behind address-space layout randomization (ASLR) is that many buffer overflow attacks rely on knowing the location in memory of the exploit code the attacker wishes to use. ASLR renders this difficult by randomizing the memory layout: the base addresses of the stack, heap, code, and memory mapped segments are randomized at load and link time. This ensures that hardcoded addresses are unlikely to point to the desired code when the attack targets a particular system. This approach was initially highly-effective against many forms of buffer overflow attacks, although attacks that rely exclusively on relative addresses continued to be effective. ASLR was widely deployed in both Linux and OpenBSD. Derandomization techniques (Windows Vista, for example, only used 8 heap and 14 stack bits of randomness) have since eroded the effectiveness of ASLR on 32-bit machines. Derandomization attacks on 64 bit machines take several minutes and are thus often detectable, but can still be successfully executed in some contexts. 4.3 Countermeasure: Language Support High level languages are compiled into machine code before they are executed. During this phase, the compiler has the option to introduce additional checks. For example, when presented with an array access, the compiler could introduce bounds checks, logically replacing loop (a) with loop (b): Compilers can also execute type checks, ensuring that the data assigned to a location has the appropriate type for that location Language support effectively eliminates vulnerabilities like buffer overflows. However, much legacy code was written in lower level languages without such checks, so vulnerabilities remain. Introducing such checks also imposes a performance cost, so programmers continue to write code and produce vulnerabilities in non-safe languages. 1-7

8 int a[20]; for(int i=0; i<max; i++){ a[i]=0; } (a) Loop without bounds checks int a[20]; for(int i=0;i<max;i++){ if(i<0) signal error; if(i>=20) signal error; a[i]=0; } (b) Loop with bound checks 5 Back to Conficker So what was the story with Conficker? The buffer overflow overwrote a return address pointer to execute shell code that downloaded and installed a malicious.dll containing the actual worm. The malicious library ran an HTTP server that downloaded and ran code from pseudorandomly computed servers every 30 minutes, resulting in a large and powerful botnet under the control of Conficker s authors. 1-8