1 / 22
Download Presentation

Enhancing System Security Through Diversity Strategies

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Papers • S. Forrest, A. Somayaji, and D. Ackley. "Building Diverse Computer Systems", HotOS (1997). paper • PaX Team, "Documentation for the PaX project", link • A. van de Ven, "New Security Enhancements in Red Hat Enterprise Linux v. 3, update 3", paper

  2. Diversity • Adds robustness in biological systems • Ecosystem vulnerabilities if only a few species are dominant (fires, disease, infestations) • Health problems when there is low genetic diversity in species • Disease propagation in population if immunological defenses are not diverse • Computer system homogeneity • Leads to worms and viruses • Tension with compatibility and portability • Apply randomization to add diversity transparently

  3. Papers • S. Forrest, A. Somayaji, and D. Ackley. "Building Diverse Computer Systems", HotOS (1997). paper • PaX Team, "Documentation for the PaX project", http://pax.grsecurity.net/docs/index.html • A. van de Ven, "New Security Enhancements in Red Hat Enterprise Linux v. 3, update 3", http://www.redhat.com/f/pdf/rhel/WHP0006US_Execshield.pdf

  4. Overall strategy • Avoid unnecessary consistency • Compiler strategy • All but the lowest-level tasks are implemented in a high-level programming language • Each program can have many correct translations into machine code • Each aspect of a programming language that is “arbitrary” or “implementation-dependent” can be targets for randomized compilation techniques • Compilation includes machine code generation as well as load-time and execution-time transformations

  5. Issues • Correctness • Preserve high-level functionality • Effectiveness • Add to places most often attacked • Efficiency • Minimize run-time performance cost

  6. Approaches • Add or delete nonfunctional code • NOOPs or other sequences • Must make sure compiler does not optimize them out • Reordering code • Rearrange basic blocks of compiled code in random order (different locations, same execution order) • Use parallel processing techniques to identify code blocks that can be run simultaneously (and can thus be reordered) • Do the same within code blocks (instruction reordering)

  7. Approaches • Memory layout • Pad each stack frame by random amount • Randomize locations of global variables • Assign new stack frames a random location (instead of next contiguous location) • Treats stack as a heap and increases memory management overhead

  8. Approaches • Others • Process initialization crt0.o, command-line arguments, environment variables (kernel changes) • Dynamic libraries • System calls • System files • Bad for system administrators • Magic numbers in certain files (executables) • Marks external executables versus native ones • Randomized run-time checks • Random array bounds checking

  9. Implementation • gcc and random padding in stack frame • Disrupts simple attack against lpr

  10. NOEXEC • Prevent injection and execution of code • Prevent new writable/executable mappings • Separation writable and executable properties on memory pages • Applies to executable file mappings as well (breaks some applications) • Prevent writable/non-exec from going to executable • Least privilege enforcement • If data in address space does not need to be executable, it should not be (via marking such pages) • If applications do not need to generate code at run-time, it should not be able to • Support on most MMUs on CPUs except IA-32 • All stack, heap, and anonymous mappings are non-execute • Only ELF segments holding code will be executable

  11. ASLR • Address Space Layout Randomization • Applied to entire memory space • Main executable code/data/bss segments • brk() managed memory (heap) • mmap() managed memory (libraries, heap, thread stacks, shared memory) • User stack • Kernel stack

  12. PAGEEXEC • Non-executable page feature using paging logic of IA-32 CPUs • Need hack since IA-32 MMU doesn't support execution protection in hardware yet • Use split TLB for code/data in Pentium CPUs • Software control of ITLB/DTLB loading • Mark all non-executable pages as either not present (causing a page fault) or requiring supervisor level access (overload no-exec with supervisor mode) • Modify page fault handler accordingly to terminate task

  13. SEGMEXEC • Implement non-executable pages via segmentation logic of IA-32 • Split 3GB userland address space into half • Define data segment descriptor to cover one half • Define code segment descriptor to cover other half • Need mirroring since executable mappings can be used for data accesses • Place copies of executable segments within data range • Instruction fetching from data space will end up in code segment address space and raise a page fault • Page fault handler can terminate task

  14. MPROTECT • Prevent introduction of new executable code into address space via restrictions on mmap() and mprotect() • Prevent the following • Creation of anonymous mappings • Creation of executable/writable file mappings • Making an executable/read-only file mapping writable except for performing relocations on an ET_DYN ELF file • Making a non-executable mapping executable

  15. RANDUSTACK • Randomize user stack on task creation • exec.c: do_execve() • Randomize bits 2-11 (4kB shift) • setup_arg_pages() • Randomize bits 12-27 (256MB shift) for copying previously populated physical stack pages into new task's address space • create_elf_tables() • Aligns stack pointer on 16-byte boundary (throws away randomization in bits 2-3 • Result is bits 4-27 randomized

  16. RANDKSTACK • Randomizes every task's kernel stack pointer before returning from a system call to userland • Two pages of kernel stack allocated to each task • Used whenever task enters kernel • Kernel land stack pointer will always end up at the point of the initial entry to the kernel • Attack against kernel bug from userland could rely on this • Entropy from rdtsc() applied to bits 2-6 (128 byte shift)

  17. RANDMMAP/RANDEXEC • Randomness into memory regions of do_mmap() kernel interfact • All file and anonymous mappings • Main executable of ET_DYN type, libraries, brk() and mmap() heaps • Need big memory hole • Randomize bits 12-27 • Randomness into main executable • Main executable of ET_EXEC type • Use of absolute addresses • Must provide a file mapping of ET_EXEC file at original base address • Mirror executable regions

  18. ExecShield • Rolled into Linux 2.4.20

  19. No-execute regions • Use segment size limits to emulate page table execute permission bits • Generalized form of SolarDesigner’s no-exec stack patch • Cover other areas as well as stack • Kernel keeps track of maximum executable address “exec-limit” • Process-dependent • Remap all execute regions to “ASCII armor” • Contiguous addresses at beginning of memory that have 0x00 (no string buffer overruns) • 0x0 to 0x01003fff (around 16MB) • Stack and heap are non-executable as result

  20. Example • Compare this with the memory layout without exec-shield: • 08048000-0804b000 r-xp 00000000 16:01 3367 /bin/cat0804b000-0804c000 rw-p 00003000 16:01 3367 /bin/cat0804c000-0804e000 rwxp 00000000 00:00 040000000-40012000 r-xp 00000000 16:01 3759 /lib/ld-2.2.5.so40012000-40013000 rw-p 00011000 16:01 3759 /lib/ld-2.2.5.so40013000-40014000 rw-p 00000000 00:00 040018000-40129000 r-xp 00000000 16:01 4058 /lib/libc-2.2.5.so40129000-4012f000 rw-p 00111000 16:01 4058 /lib/libc-2.2.5.so4012f000-40133000 rw-p 00000000 00:00 0bffff000-c0000000 rwxp 00000000 00:00 0 • In this layout none of the executable areas are in the ASCII-armor, plusthe exec-limit is 0xbfffffff (3GB) - ie. including all userspace mappings. • Note that the kernel will relocate every shared-library to the • ASCII-armor, but the binary address is determined at link-time. To easethe relinking of applications to the ASCII-armor, Arjan Van de Ven haswritten a binutils patch (binutils-2.13.90.0.18-elf-small.patch), whichadds a new 'ld' flag "ld -melf_i386_small" (or "gcc -Wl,-melf_i386_small")to relink applications into the ASCII-armor.

  21. Example • With exec-shield • $ ./cat-lowaddr /proc/self/maps00101000-00116000 r-xp 00000000 03:01 319365 /lib/ld-2.3.2.so00116000-00117000 rw-p 00014000 03:01 319365 /lib/ld-2.3.2.so00117000-0024a000 r-xp 00000000 03:01 319439 /lib/libc-2.3.2.so0024a000-0024e000 rw-p 00132000 03:01 319439 /lib/libc-2.3.2.so0024e000-00250000 rw-p 00000000 00:00 001000000-01004000 r-xp 00000000 16:01 2036120 /home/mingo/cat-lowaddr01004000-01005000 rw-p 00003000 16:01 2036120 /home/mingo/cat-lowaddr01005000-01006000 rw-p 00000000 00:00 040000000-40001000 rw-p 00000000 00:00 040001000-40201000 r--p 00000000 03:01 464809 locale-archive40201000-40207000 r--p 00915000 03:01 464809 locale-archive40207000-40234000 r--p 0091f000 03:01 464809 locale-archive40234000-40235000 r--p 00955000 03:01 464809 locale-archivebfffe000-c0000000 rw-p fffff000 00:00 0 • In the above layout, the highest executable address is 0x01003fff, ie.every executable address is in the ASCII-armor.

  22. RHEP add-ons • Use of NX bit in subsequent CPUs • Randomization • Stack itself • Locations of shared libraries • Start of program’s heap • Want to randomize location of application code • But, many are compiled w/ absolute address information • PIE = position-independent executable

More Related