A Comparison of Buffer Overflow Prevention Implementations and

A Comparison of Buffer Overflow Prevention Implementations and Their Weaknesses Richard Johnson | Peter Silberman

Agenda – Compiler-Enforced Protection • • Stack. Guard Stack. Shield Pro. Police Microsoft /GS Compiler Flag – Kernel-Enforced Protection • Pa. X • Stack. Defender 1 & 2 • Overflow. Guard – Attack Vector Test Platform

Compiler-Enforced Protection

Compiler-Enforced Approach • Advantages – No system-wide performance impact – Intimate knowledge of binary structure • Disadvantages – Requires modification of each protected binary (including shared libraries) and source code must be available – Protections must account for each attack vector since execution environment is not protected

Compiler-Enforced Concepts • Buffer Overflow Prevention is accomplished by protecting control data stored on the stack. • Re-ordering Stack Variable Storage • Stack Canaries – – Random Canary Random XOR Canary Null Canary Terminator Canary

Stack. Guard • Pioneered the use of stack canaries. • Modifications to the function_prologue and function_epilogue generate and validate canaries. • Canary originally adjacent to return address. • Latest version protects both return address and frame pointer. • Canary location is now architecture specific.

Stack. Shield • Global Ret Stack – Return address is placed in the Global Ret Stack whenever a function is called and copied out whenever the function returns. • Ret Range Check – Copies return address to non-writable memory in function_prologue – function_epilogue checks against stored return address to detect an overflow. • Function pointers are also checked to ensure they point to the. text section.

Pro. Police SSP • Implements a safe stack model which rearranges argument locations, return addresses, previous frame pointers and local variables. • Provides most complete buffer overflow prevention solution of all evaluated compiler-enforced protection software.

Pro. Police SSP • Arrays and local variables are all below the return address.

Pro. Police SSP • Vulnerable code segment (provided by Pro. Police docs): • In our example, an overflow in buf could overwrite the function pointers. However, SSP will change this code to….

Pro. Police SSP Using the Pro. Police safe stack, the passed function pointer is put in a register or local variable by the compiler.

Microsoft Compiler Extension • Initial release of Microsoft’s. NET compiler included buffer overflow protection • . NET compiler protection is a re-incarnation of Crispin Cowan’s Stack. Guard • Differences – Cookies vs. Canaries – Storing in Writable Memory

How the /GS Switch Works • The GS switch adds a security cookie • When the cookie check occurs: – Original cookie stored in. data section – Compared to the cookie on the stack – No match security handler called • Modifications to Exception Handler – Can’t point to stack – Registered Handler Buffer Cookie Saved EBP Saved Return Address Param *

. NET Protection Bypass • Exception Handler Bypass – Exception handler points to heap – Exception handler points to registered handler • If the attacker has an arbitrary DWORD overwrite – Overwrite the saved cookie – Overwrite the security handler function pointer

Kernel-Enforced Protection

Kernel-Enforced Approach • Advantages – Does not require source code or modifications to binaries – Kernel has control over the MMU • Disadvantages – Architecture/platform dependant – Noticeable performance impact on architectures that don’t natively support non-executable features

Kernel-Enforced Concepts • Buffer Overflow Prevention is accomplished by applying access controls to the MMU and randomizing process memory layout. • The goal of kernel-enforced buffer overflow protection is to prevent and contain the following: – Introduction/execution of arbitrary code – Execution of existing code out of original program order – Execution of existing code in original program order with arbitrary data

Memory Management Unit Access Control Lists • Non-executable (NOEXEC) protection is the most commonly used access control for memory. • A non-executable stack resides on a system where the kernel is enforcing proper “memory semantics. ” – Separation of readable and writable pages – All executable memory including the stack, heap and all anonymous mappings must be non-executable. – Deny the conversion of executable memory to non-executable memory and vice versa.

Address Space Layout Randomization • Defeats rudimentary exploit techniques by introducing randomness into the virtual memory layout of a process. • Binary mapping, dynamic library linking and stack memory regions are all randomized before the process begins executing.

Pa. X • Pa. X Project’s kernel patches provide an example of one of the more robust kernelbased protection software currently available. • Pa. X offers prevention against unwarranted code execution via memory management access controls and address space randomization.

Pa. X NOEXEC • NOEXEC aims to prevent execution of arbitrary code in an existing process’s memory space. • Three features which ultimately apply access controls on mapped pages of memory: – executable semantics are applied to memory pages – stack, heap, anonymous memory mappings and any section not marked as executable in an ELF file is nonexecutable by default. – ACLs on mmap() and mprotect() prevent the conversion of the default memory states to an insecure state during execution (MPROTECT).

Pa. X PAGEEXEC • Implementation of non-executable memory pages that is derived from the paging logic of IA-32 processors. • Pages may be marked as “non-present” or “supervisor level access”. • Page fault handler determines if the page fault occurred on a data access or instruction fetch. – Instruction fetch – log and terminate process – Data access – unprotect temporarily and continue

Pa. X SEGMEXEC • Derived from the IA-32 processor segmentation logic • Linux runs in protected mode with paging enabled on IA-32 processors, which means that each address translation requires a two step process. – LOGICAL <-> LINEAR <-> PHYSICAL • The 3 gb of userland memory space is divided in half: – Data Segment: 0 x 0000 - 0 x 5 fffffff – Code Segment: 0 x 60000000 – 0 xbfffffff • Page fault is generated if instruction fetches are initiated in the non-executable pages.

Pa. X MPROTECT • Prevents the introduction of new executable code to a given task’s address space. • Objective of the access controls is to prevent: – – Creation of executable anonymous mappings Creation of executable/writable file mappings Making executable/read-only file mapping writable except for performing relocations on an ET_DYN ELF Conversion of non-executable mapping to executable

Pa. X MPROTECT • Every memory mapping has permission attributes which are stored in the vm_flags field of the vma structure within the Linux kernel. • The four attributes which define the permissions of a particular area of mapped memory are: – – VM_WRITE VM_EXEC VM_MAYWRITE VM_MAYEXEC

Pa. X MPROTECT • The Linux kernel requires VM_WRITE enabled if the VM_MAYWRITE attribute is true. Also applies to VM_EXEC. • Pa. X must deny WRITE and EXEC permissions on the same page leaving the safe states to be: VM_MAYWRITE VM_MAYEXEC VM_WRITE | VM_MAYWRITE VM_EXEC | VM_MAYEXEC

Pa. X ASLR • Address Space Layout Randomization (ASLR) renders exploits which depend on predetermined memory addresses useless by randomizing the layout of the virtual memory address space. • Pa. X implementation of ASLR consists of: – – RANDUSTACK RANDKSTACK RANDMMAP RANDEXEC

Pa. X RANDUSTACK • Responsible for randomizing userspace stack. • Kernel creates program stack upon each execve() system call. – Allocate appropriate number of pages – Map pages to process’s virtual address space • Userland stack usually is mapped at 0 xbfffffff • Randomization is added both in the address range of kernel memory to allocate and the address at which the stack is mapped.

Pa. X RANDKSTACK • Responsible for randomizing a task’s kernel stack • Each task is assigned two pages of kernel memory to be used during the execution of system calls, interrupts, and exceptions. • Each system call is protected because the kernel stack pointer will be at the point of initial entry when the kernel returns to userspace

Pa. X RANDMMAP • Handles the randomization of all file and anonymous memory mappings. • Linux usually allocates heap space by beginning at the base of a task's unmapped memory and locating the nearest chunk of unallocated space which is large enough. • RANDMMAP modifies this functionality in do_mmap() by adding a random delta_mmap value to the base address before searching for free memory.

Pa. X RANDEXEC • Responsible for randomizing the location of ET_EXEC ELF binaries. – Image must be mapped at normal address with pages set non-executable – Image is copied to random location using RANDMMAP logic. • Page fault handler will handle accesses to both binary images and allow access when proper conditions are met.

NGSEC Stack. Defender 1. 10 • Stack. Defender implements a unique protection – Protection based on ACLs surrounding API calls • Stack. Defender files: – – – kernel. NG. fer msvc. NG. fer ntd. NG. fer Proxydll. dll Stack. Defender. sys

Stack. Defender. sys • Hooks Zw. Create. File, Zw. Open. File to detect: – kernel 32. dll – msvcrt. dll – ntdll. dll • Redirect files to: – *NG. fer

Understanding System Calls __asm { mov eax, 0 x 64 lea edx, [esp+0 x 04] int 0 x 2 e } • Gateway between User-mode and Kernel-mode – Ki. System. Service – call Ke. Service. Descriptor. Table->Service. Table. Base[function_id]

Hooking System Calls __asm { cli mov mov sti } ; stop interrupts edx, ds: Zw. Create. File ; save function pointer ecx, ds: Ke. Service. Descriptor. Table ; save Ke. SDT pointer ecx, [ecx] ; Get base edx, [edx+1] ; Get function number edx, [ecx+edx*4] ; Service. Table. Base old_func, edx ; store old function edx, [edx+1] dword ptr [ecx+edx*4], offset function_overwrite

NG. fer Files • Used by Stack. Defender to add randomness to the systems DLL’s image base. • Makes a copy of system DLLs – Kernel 32. dll – Ntdll. dll – Msvcrt. dll

What is the Export Address Table (EAT)? • Used to export a function for other processes typedef struct _IMAGE_EXPORT_DIRECTORY { DWORD Characteristics; DWORD Time. Date. Stamp; WORD Major. Version; WORD Minor. Version; DWORD Name; DWORD Base; DWORD Number. Of. Functions; DWORD Number. Of. Names; DWORD Address. Of. Functions; // RVA from base of image DWORD Address. Of. Name. Ordinals; // RVA from base of image } IMAGE_EXPORT_DIRECTORY, *PIMAGE_EXPORT_DIRECTORY; • To resolve a function export: – Obtain the Virtual address of the EAT – Walk Address. Of. Names, and Address. Of. Name. Ordinals – Index Address. Of. Functions

kernel. NG. fer • Setup Kernel. NG. fer – Modify characteristics of the. reloc section • 42000040 (Readable + Discardable + Initialized Data) • E 2000060 (Executable + Writable + Readable) – Copy function stubs – Implement Export Address Table Relocation • Overwrites function entry point

kernel. NG. fer (cont. ) Stack. Defender overwrites the following function’s EAT entries: Win. Exec Create. Process. A Create. Process. W Create. Thread Create. Remote. Thread Get. Proc. Address Load. Module Load. Library. Ex. A Load. Library. Ex. W Open. File Create. File. A Create. File. W _lopen _lcreat Copy. File. A Copy. File. W Copy. File. Ex. A Copy. File. Ex. W Move. File. A Move. File. Ex. W Move. File. With. Progress. A Move. File. With. Progress. W Delete. File. A Lock. File Get. Module. Handle. A Virtual. Protect Open. Process Get. Module. Handle. W

Stack. Defender Overflow Detection • . reloc from kernelng. fer loads proxydll. dll • Proxydll. dll exports Stack. Defender() – – arg 1 = esp+0 x 0 C arg 2 = where the function was called from arg 3 = integer arg 4 = stack address of a parameter • Proxydll overflow detection – Alert API Routine • Checks API for strings e. g. cmd. exe – Calls Virtual. Query() on arg 1 and arg 2 • MEMORY_BASIC_INFORMATION->Allocation. Base – Is. Bad. Write. Ptr() called on arg 2

Defeating Stack. Defender • Shellcode that puts itself on the heap and marks the heap read-only • Shellcode that calls ntdll functions e. g. Zw. Protect. Virtual. Memory – Bypasses API hooks

Stack. Defender 2. 00 • Heavily influenced by Pa. X • Moved away from API ACL • Initial Analysis shows: – Hooks Zw. Allocate. Virtual. Memory and Zw. Protect. Virtual. Memory – Hooks int 0 x 0 e and int 0 x 2 e

Vulnerabilities in Stack. Defender • Stack. Defender 1. 10 – Blue Screen of Death when calling Zw. Create. File / Zw. Open. File with an invalid Object. Attribute parameter. • Stack. Defender 2. 00 – Blue Screen of Death when Zw. Protect. Virtual. Memory is given an invalid Base. Address

Data. Security. Software Overflow. Guard 1. 4 • Overflow. Guard implements Pa. X page protection • Overflow. Guard hooks Interrupt Descriptor Table entries 0 x 0 e and 0 x 01. – 0 x 01 -> Debug Exception – 0 x 0 e -> Page Fault • Overflow. Guard Files: – Overflow. Guard. sys

What is the Interrupt Descriptor Table (IDT)? • Provides array of function pointers as handlers for userland exceptions or events • Kernel receives interrupt request and dispatches the correct handler • Interrupt or Exception occurs – int 0 x 03 - breakpoint – int 0 x 0 e - invalid memory access

Overwriting IDT • Use sidt instruction to obtain IDT base • Load address of interrupt handler – IDT base addr + interrupt id * 8 • The Interrupt Gate which Overflow. Guard needs to overwrite looks like: 31 -16 1 5 14 -13 12 -8 7 -5 4 -0 Offset P D P L 0 -D-1 -1 -0 0 -0 -0 Reserved Segment Selector 15 -0 Offset

Overflow. Guard Buffer Overflow Protection • Overflow. Guard sets memory mappings to read-only • Writing stack or heap when its in read-only mode – Causes page fault • Updates Permissions • Page Fault Handler – Overflow. Guard converts old EIP to physical address • Compares old EIP to fault address – Then it was an execution attempt – Otherwise it was a data access » » Find memory address Mark it writable/user/dirty Perform dummy read Reset memory permissions to supervisor

Defeating Overflow. Guard • Return-into-libc previously demonstrated by ins 1 der • Does not protect third party software

Attack Vector Test Platform

Attack Vector Test Platform • Provides objective test results to determine gaps in buffer overflow prevention software • Simulates exploitation of various attack vectors • Original work by John Wilander

Attack Vector Test Platform Results

Conclusion • Test results show that there are varying coverage capabilities in the available protection software • Windows protection has not advanced yet – Few compiler options – Successful protection of third party applications • Combination of kernel and compiler-based protection software is currently the best defense.

Thanks Special thanks go out to: Matt Miller for technical insight and research verification Lord Yu. P for conceptual contributions We’d also like to thank: i. DEFENSE Labs, Dr Dobbs Journal for lending us articles to read, Dr. John Wilander for initial Testbed, and Stack. Defender Development team for being affable and helpful throughout the research process.

Questions?