Bypassing Browser Memory Protections

Bypassing Browser Memory Protections Network Security Instructor: Dr. Shishir Nagaraja September 10, 2011. 1 Introduction to the topic A number of memory protection mechanisms like GS, SafeSEH, DEP and ASLR have been employed in the Operating System by vendors, such mechanisms though at first site may appear to be secure, but there are loopholes in these techniques. These loopholes have been discussed in this paper. In particular the protection mechanisms in browsers and the way by which they can be circumvented, has been discussed in this paper at length. 2 Questions that the paper asks and how are those questions interesting This paper explores the memory protection mechanism in Windows and the way by which they can be circumvented. 3 How does it answer the questions In order to answer the questions that the paper asked by the paper, the author divides it into 3 sections SECTION 1: Available protection mechanisms. SECTION 2: Loopholes in these mechanisms. SECTION 3: Practically exploiting these loopholes. SECTION 1: AVAILABLE PROTECTION MECHANISMS 1. GS /GS option when enabled, prevents the return address of the functions from being overwritten due to buffer overflows. Also the compiler stores an arbitrary value on the stack at an address, just before the return address of a function. One disadvantage of GS protection is that the corrupt cookie value will only be detected when the function returns. If the function uses any other variable before this detection, then the attacker might take control of the execution. In order to prevent the above mentioned flaw, string buffer are placed after the other variables. Whereas, if the arguments contain pointers or string, they are copied before the variables. 2. SafeSEH: Safe Structured Exception Handler protection mechanism was designed to forbid attackers from overwriting exception handlers. Overwritten exception handlers may be exploited by first throwing 1

an exception, thus in effect redirecting the program flow to the exception handler and then executing the malicious code in the overwritten exception handlers. In order to forbid attackers from such an attack, /SafeSEH linker option contains a list of valid exception handlers stored in a table. When an exception occurs the exception thrown can be verified against a table of exception handlers. Windows server 2008 introduced a new Structured Exception Handling mechanism. It uses a linked list of exception handlers, with the last exception handler in the list being the FinalExceptionHandler function. This mechanism is useful as it prevents the attackers from overwriting exception handler records. In order to verify that a given exception handler is a valid one, the exception dispatcher traverses this linked list and checks that the last linked list node is still FinalException- Handler. Although this protection mechanism also has loopholes. One amongst them being: an attacker changes the NEXT pointer to point to a bogus Structured Exception Handler record, this bogus SEH in turn points to the FinalExceptionHandler function. HEAP PROTECTION: In order to abuse the heap protection, the attacker may overwrite the header of the heap block and create his own flink and blink pointers. When this memory block is coalesced with other free chunks, then the value at the flink pointer is written into the value at the blink pointer. Thus in effect we are performing a write operation, which in turn helps the attacker to execute the malicious code. The above problem may be done away by safe unlinking. In safe unlinking it is checked before performing each write that flink points to blink and blink points to flink. In addition to safe unlinking a cookie is added to the header of each heap block, in order to protect the header from being changed. This is the same technique as the one used in protecting the return address of a function in a stack with a cookie. 3. DATA EXECUTION PREVENTION: Data Execution Prevention or DEP is a method which when enabled provides protection by prohibiting an attacker from executing his code in the non-executable region of memory. In case a trusted process needs to execute its code, then it needs to call VirtualAlloc or VirtualProtect, to grant it executable memory In order to mark memory regions as executable or non-executable, NX bit or No Execute bit has been added to the page table of x86 family of CPU. Due to the non compatibility of some applications with DEP Protection, the following Data Execution Prevention policies are available: (a) OptIn: DEP protection is available for processes that specifically ask for it. (b) OptOut: DEP protection is by default given to all processes, except to those processes that explicitly opt out of it. (c) AlwaysOn: All processes are given a DEP protection. (d) AlwaysOff: DEP protection is not given to any process. 4. ASLR (ADDRESS SPACE LAYOUT RANDOMIZATION): ASLR randomizes the allocation of addresses to objects, in the virtual address space of each process. Because of the randomization it becomes difficult for an attacker to ascertain the position of a particular address. The five types of randomizations are discussed below: (a) Image Randomization: In Windows Vista ASLR is performed, by randomly placing both program executables and DLLs. Also randomization is optional and can be set in the registry key. 2

(b) Executable Randomization: In this we add or subtract a random delta value to the image base mentioned in the PE header. (c) DLL Randomization: DLL Randomization is different from Executable randomization. Since windows relies on relocations instead of position independent code, a DLL must be loaded at the same address in each process that uses it to allow the physical memory used by the DLL to be shared. (d) Heap Randomization: In this the starting position of the heap is randomized by calling RtlHeapCreate function. RtlHeapCreate function multiplies a 6-bit random value with 64K. This value is then used as an offset to the base address returned by the NtAllocateVirtualMemory. The memory region which is before this offset is freed. (e) Stack Randomization: Stack randomization in Windows Vista is done in 2 steps: i. First the stack base is randomly chosen by looking for consecutive regions in memory that are not mapped. Based on the 5-bit value X obtained from the timestamp counter, the Xth hole is searched for in memory, this procedure brings about the desired randomness, in generating the stack s base address. ii. Then an offset into this stack is chosen randomly SECTION 2: BYPASSING MEMORY PROTECTIONS In this section the loopholes in the above mentioned memory protection mechanisms are being discussed: 1. GS: In order to understand loopholes in GS protection, consider the following example (Reference: Bypassing Browser Protection by Alexander Sotirov and Mark Dowd): void gs1(char *src, int len) { struct { int a; int b; } buf; memcpy( & buf, src, len); } In this an unspecified number of bytes, which are stored in src are copied into buf structure. Since buf is not GS protected, this code is highly vulnerable. Such fixed size objects are highly vulnerable, as they are not protected by GS. There is also a possibility that stack data is overwritten before cookie verification. Stack data may be of 4 types: (a) string buffers. (b) exception handlers (c) function arguments (d) data of other functions 2. SafeSEH: (a) SafeSEH exception handlers can be put on the heap, this can be done when DEP is disabled. Now the attacker can exploit this by prutting his shellcode on the heap and by using an overwritten exception handler to point to this shellcode. (b) Heap protection can be bypassed by the following means: 3

i. One of the reason for the security holes in heaps is because of the lookaside lists. Lookaside list is a linked list of free blocks on the heap. In the case of heap allocation, one block is removed from lookaside list, and this blocks flink pointer is written to the header of the lookaside list. This can be exploited by overwriting the header or the flink pointer of the link list, and then the attacker may write at the memory location of this forward pointer. ii. The attacker may exploit the inconsistent state of the heap, which occurs after the safe unlinking check fails. As this inconsistent state of the heap gives the attacker the ability to write his shellcode in the heap. iii. The attacker may take advantage of heap overflows by overwriting the application data. And in case the overwritten part consists of overwritten pointers, the attacker may thus successfully execute his shellcode. 3. Data Execution Prevention: (a) Contemporary applications such as Internet Explorer 7 do not have DEP protection as they are not linked with /NXcompat (b) DEP is effective if we can prohibit the attacker from writing data to executable memory locations. But in certain cases e.g., in JVM s allocation of objects, these objects are mapped into memory locations marked as readable, writable and executable. Thus such objects can be effectively used by the attacker in heap spraying attacks. (c) Another attack that is possible on DEP is the attacker using the system s APIs to mark the non-executable pages as executable. 4. ASLR (Address Space Layout Randomization) (a) There are well-known softwares available whose binaries have not been built with Visual Studio 2005 SP1 and don t have their /DynamicBase option passed to the linker. Thus their IMAGE DLL CHARACTERISTICS DYNAMIC BASE flag is not set, this rules out randomization. The above technique takes the attacker aware of the location of such executables and DLLs, thus making the memory vulnerable to such attacks. (b) The attacker may use heap spraying technique, in this technique the attacker fills the entire heap area by consecutively writing the NOP slide and his own shellcode. (c) Partial overloading involves modifying only the least significant bytes. Performing such overwrites may be helpful to the attacker, as the attacker just needs to set the pointer to his code to a relocatable memory address. SECTION 3: EXPLOITING THE BROWSER The below mentioned techniques may be employed to circumvent the browser protection: 1. Heap Spraying: The attacker may use heap spraying to fill the heap of the browser by consecutively repeating NOP slide and shellcode instructions. Since the virtual memory is limited, hence the attacker successfully guess the location of his data. 2. SEH overwrite with Flash Code reuse: If we wish to use the previous exploitation technique with GS protection, then we need to take an intersection of previous solution with overwriting an exception handler. This exception handler, now in turn points to the shell code in a vulnerable DLL. Now the above constraints can be easily fulfilled with Flash9f.ocx module, as this module does not apply ASLR protection technique by loading at a fixed address. Also this module doesn t have SafeSEH protection. Now since the jump from current stack pointer to the overwritten stack pointer is relative, hence the attacker adds the two to obtain the shellcode. 3. Exploiting Java s vulnerabilities: While Java Runtime Environment ensures the execution of Java applets, JVM ensures that these applets are sandboxed. Since JVM uses VirtualAlloc to allocate 4

memory and also for granting read, write and executable privileges to the memory block. Now due to this very vulnerability the attacker may use heap spraying to place his shellcode and in turn execute it. In order for the attack to be effective, the attacker needs to know the possible base addresses of heap. This can be easily determined, when we consider the fact that internal representations of most frequently used classes is kept in the disk cache called shared archive. The shared archive and the heap is allocated memory, after allocating memory to code cache and to the variables which are created before JVM is loaded. Thus the expected values of base addresses as mentioned in the paper is between 0x20000000-0x25000000. And when the shared archives are not loaded, then the expected value of base address is around 0x05000000. Hence the attacker has a high probability of succeeding when he takes the base addresses around this value. 4. Exploiting.NET vulnerabilities:.net User interface controls used by Internet Explorer version 6 and above are claimed to be secure just like their Java counterparts, they are sandboxed inside the Internet Explorer program and are verified to be valid..net binaries are just like PE files, hence they are treated as images..net binaries set the page permissions according to the value in the PE header. This lets the attacker place their code inside the binary and acquire executable rights. Just like heap spraying, the.net binaries can also finish off the virtual memory locations. This technique is called Address space spraying. This is a more powerful attack than heap spraying as it successfully avoids ASLR and DEP protection. Also the attacker is able to guess where to locate the vulnerable binary by employing the following 2 steps: (a) By providing a binary which is sufficiently large so that it can be accommodated between 0x50000000-0x78000000. (b) By providing a binary which does not fit between 0x50000000-0x78000000. One major drawback of the above mentioned approaches is, since we want large binaries than downloading it will consume a large portion of the system bandwidth and of course, it will be time consuming. The following ways are used to deal with the above mentioned difficulty: (a) To put zeros at a large virtual memory area and then to put the data. (b) To compress the data which largely consists of NOP instructions, by employing gzip encoding. As it is mentioned in the paper that DLLs are 64K- consecutively aligned. Hence an attacker can design an attack such that he can send several 8k or smaller binaries. Also every binary will contain some malicious code, which the attacker wishes to execute. Hence with the added advantage of applying the page protection which the attacker wishes, address spraying attack is more powerful than heap spraying attacks. Disable Address Space Layout Randomization: ASLR does not take place if all of the following three conditions are met: 1. The binary is not participating in ASLR. 2. The binary is not IL-Only. 3. The MmMoveImages global variable is not set to -1 For the attack to take place, the following modifications to a standard.net control need to be carried out: 1. Set the ImageBase value in the PE Optional Header to the desired address. 2. Remove the DLL IMAGE CHARACTERISTICS DYNAMIC BASE flag from the DllCharacteristics value in the PE file header. 3. Change the version of COR header to make it below 2.5. Setting it to 2.4 is sufficient to break ASLR without impacting the.net control. (Reference: Bypassing Browser Memory Protections by Alexander Sotirov and Mark Dowd) 5. Java and.net stack spraying: Stack sizes are characterized into 2 types, namely: 5

(a) Reserve size, is the largest size up to which the stack will grow to.this size is allocate from the virtual address space. (b) Commit size, represents the amount of physical memory that has been allocated. The size of the committed memory will be less than or equal to the size of the reserve memory. In both Java and.net have thread constructors, which can construct the stack of an arbitrary size. The attacker can take advantage of this feature by allocating a large stack size. He can also control the stack by controlling the type of data elements passed to the stack. (a) We create a function which doesn t contain arguments, nor does the function have any local variables. When we keep calling this function a substantially large number of times, an area in memory which contains a series of return addresses is created. Any of these addresses may be overwritten by the attacker to transfer the control flow to the attackers shellcode. This mechanism has been described in the paper as stack spraying with return addresses. (b) We can use the stack as pointers to the shellcode of the attacker. This is called stack spraying with pointers. 4 Methodology used to investigate the paper In order to explore the memory protection mechanism in Windows, the author first explains the available protection mechanisms. Then he describes the loopholes in these mechanisms. At last he describes, how these loopholes can be exploited by attackers, giving particular emphasis on browser security. 5 Weaknesses of the paper This paper talks only about Windows, it doesn t pay much attention to the loopholes in operating systems such as Solaris, Unix, etc. Particularly the stress is only on Windows Vista. 6 Results In spite of the memory protection techniques defined by microsoft, memory leaks still exist. 6