DOCSLIB.ORG

Loader) Write Left Behind

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text

Load more

Dartmouth College Dartmouth Digital Commons Dartmouth College Ph.D Dissertations Theses and Dissertations 4-1-2018 Types for the Chain of Trust: No (Loader) Write Left Behind Rebecca Shapiro Dartmouth College Follow this and additional works at: https://digitalcommons.dartmouth.edu/dissertations Part of the Computer Sciences Commons Recommended Citation Shapiro, Rebecca, "Types for the Chain of Trust: No (Loader) Write Left Behind" (2018). Dartmouth College Ph.D Dissertations. 56. https://digitalcommons.dartmouth.edu/dissertations/56 This Thesis (Ph.D.) is brought to you for free and open access by the Theses and Dissertations at Dartmouth Digital Commons. It has been accepted for inclusion in Dartmouth College Ph.D Dissertations by an authorized administrator of Dartmouth Digital Commons. For more information, please contact [email protected]. TYPES FOR THE CHAIN OF TRUST: NO (LOADER) WRITE LEFT BEHIND Dartmouth Computer Science Technical Report TR2018-863 A Thesis Submitted to the Faculty in partial fulfillment of the requirements for the degree of Doctor of Philosophy in Computer Science by Rebecca “.bx” Shapiro DARTMOUTH COLLEGE Hanover, New Hampshire April, 2018 Examining Committee: (chair) Sergey Bratus, Ph.D. (co-chair) Sean W. Smith, Ph.D. Devin Balkcom, Ph.D. Greg Morrisett, Ph.D. F. Jon Kull, Ph.D. Dean of Graduate Studies Abstract The software chain of trust starts with a chain of loaders. Software is just as reliant on the sequence of loaders that ultimately setup its runtime environment as it is on the libraries with which it shares its address space and offloads tasks onto. Loaders, and especially bootloaders, act as the keystone of trust, and yet their formal security properties – which should be a part of any solid bootloader design – are both underap- preciated and not well understood. This is especially problematic given the increasing adoption of loader-based code signing and execution enforcement mechanisms. My thesis digs deeply into how loaders have failed to earn our trustworthiness and how they may continue to harbor vulnerabilities even after memory corruption-based vul- nerabilities lose their prevalence. In order to address these issues, I propose a memory region-based type system that allows us to better model a loader’s intentions and thus mediate its behavior. More specifically, I show how a loader’s execution canbe broken down into a sequence of typed phases, each semantically classified as either a bookkeeping, loading, or a patching substage, while sections of memory are grouped into semantically related regions and assigned a type, based on their intended use, by which policy access decisions are made. I demonstrate the feasibility of this technique by applying it to Das U-Boot, a well-known and widely-used bootloader, with minimal changes to the bootloader’s implementation. In order to do so, I designed and devel- oped an extensive bootloader instrumentation suite to help analyze a bootloader’s behaviors, construct a policy, and completely mediate operations, thereby enforcing behaviors governed by the type system’s policy. ii There is no moment in life that can’t be improved with pizza. –Daria Morgendorffer, from MTV’s Daria Acknowledgments I owe a great deal of gratitude to my advisor, Sergey Bratus, for his guidance and patience. Anya Shubina, who played a much grater role in my PhD research than she may even realize. My committee for their insightful advice and direction. Travis Goodspeed and the Scooby Crew along with the generations of trust labbies all who have played a non-trivial role in the generation of this thesis. The Wellesley computer science department faculty and its few (but mighty) computer science students who charmed me into taking my first computer science classes so I could be captivated by its shiny puzzles and enchanting mysteries. My family and friends for their support and patience. Also, all those yaks I shaved in the creation of this thesis (none which were harmed). And you, the reader, even if you are not explicitly listed here, for endeavoring to drink from the fire hose that is this dissertation. iii Contents Abstract ii Acknowledgments iii Contents iv List of Figures ix List of Tables xi 1 Introduction 1 1.1 Our trust in bootloaders ......................... 3 1.2 A different perspective on bootloader design .............. 5 1.2.1 Loader safety properties ..................... 5 1.2.2 Designing a safe bootloader ................... 7 1.3 Contributions ............................... 8 2 Loaders and their vulnerabilities 10 2.1 A loader’s onus .............................. 12 2.1.1 The evolution of loaders ..................... 13 2.1.2 Loader safety properties ..................... 16 2.1.3 Properties of an address space: a loader’s opus . 16 2.2 Loader vulnerabilities ........................... 18 2.2.1 Code signing ........................... 18 iv 2.2.2 Out-of-bounds memory accesses . 19 2.3 i$DEVICES/iOS bootloader vulnerabilities . 21 2.3.1 iOS boot sequence overview ................... 21 2.3.2 Bootloader image format and storage . 22 2.3.3 The baseband (modem) boot process . 23 2.3.4 Type overlap loading weaknesses . 24 2.3.5 Loader enforcement/verification failures . 28 2.4 Loader vulnerabilities beyond iOS .................... 29 2.4.1 Android phone loader vulnerabilities . 30 2.4.2 UEFI ............................... 30 2.4.3 Game Consoles .......................... 31 2.4.4 BIOS ............................... 31 2.4.5 Everything else .......................... 32 2.5 The language of loading ......................... 32 3 Obstacles to loader analysis 35 3.1 Loader metadata and questionable behaviors . 35 3.1.1 ELF metadata: accidentally Turing-complete . 36 3.1.2 An ELF metadata-based root shell . 38 3.1.3 A Mach-O metadata root shell . 40 3.1.4 A PE metadata-driven packer . 43 3.1.5 Loader metadata-based parser differentials . 43 3.2 Reining in a loader ............................ 44 3.2.1 Implementation considerations . 44 3.2.2 Runtime environment ...................... 52 3.3 Final remarks ............................... 52 4 Bootloader instrumentation and analysis 54 v 4.1 Bootloader instrumentation techniques . 56 4.1.1 Bare metal debugging ...................... 56 4.1.2 Emulation-based debugging ................... 58 4.2 Dynamic bootloader analysis ....................... 59 4.3 Dynamically tracking memory writes . 59 4.3.1 Watchpoints ........................... 59 4.3.2 Breakpoints ............................ 60 4.3.3 Memory-mapped registers .................... 62 4.3.4 Relocation ............................. 63 4.4 Data collection and analysis ....................... 64 4.4.1 Dynamic call graph generation . 65 4.5 Related firmware instrumentation work . 68 4.6 Bootloader static analysis ........................ 68 5 Access properties & region typing 71 5.1 Mew-Boot on a ManulBoard: a toy system . 73 5.1.1 ManulBoard hardware description . 73 5.1.2 Initial ManulBoard memory layout . 74 5.1.3 Mew-Boot bootloader description . 74 5.1.4 ManulBoard/Mew-Boot vs. BeagleBoard-xM/U-Boot . 77 5.2 Address region-based write access control . 77 5.2.1 RBWAC definition ........................ 78 5.2.2 Substages ............................. 81 5.2.3 Bootloader design patterns ................... 83 5.2.4 Substage transitions ....................... 87 5.2.5 Region typing ........................... 89 5.2.6 Policy violations ......................... 92 5.2.7 Policy rules and logic ....................... 95 vi 5.3 RBWACµ sample policy instances .................... 95 5.3.1 Basic ManulBoard policy .................... 97 5.3.2 A more complex ManulBoard policy . 98 5.4 Retrofitting an RBWACµ instance .................... 99 5.4.1 Bootloader reconnaissance and substage extraction . 102 5.5 BBxM U-Boot SPL RBWACµ policy . 114 5.5.1 BBxM substage and region definitions . 117 5.5.2 BBxM SPL’s policy architecture . 119 5.6 RBWACµ policy language . 126 5.6.1 Region definitions . 126 5.6.2 Substage definitions and region type transitions . 129 5.7 RBWACµ instance and enforcement challenges . 131 5.7.1 Addressing challenges via static analysis . 136 5.7.2 Addressing changes via rearchitecting the system . 139 5.8 Other applications of RBWAC . 139 6 Future directions 141 6.1 Theory ................................... 141 6.2 Performance ................................ 142 6.3 “It’s not a bus, it’s a network!” . 143 6.4 Other tangentially-related research questions . 144 7 Conclusion 145 7.1 Concluding thoughts . 145 7.2 Final thoughts .............................. 147 A RBWAC-inspired U-Boot discoveries 149 A.1 BBxM hardware and documentation . 149 A.1.1 Documentation’s register tables . 149 vii A.1.2 ARM TrustZone security extensions . 150 A.2 QEMU ................................... 151 A.3 U-Boot ................................... 154 A.3.1 Code bloat ............................ 154 A.3.2 Undefined registers . 156 A.3.3 Typing issues . 156 A.3.4 Linkmap scripts and tricks . 157 B Loader-related vulnerabilities 158 C U-Boot Frama-C value analysis 165 C.1 Running a Frama-C analysis on U-Boot . 165 C.1.1 Frama-C value analysis statistics . 165 C.1.2 Frama-C ARM architecture support . 166 C.1.3 U-Boot source code post-preprocessing tool . 166 C.1.4 U-Boot assembly code . 167 C.1.5 Alignment issues . 171 C.1.6 Static linker-generated structures . 171 C.1.7 Recursion ............................. 171 C.1.8 Frama-C execution options . 172 C.2 Frama-C destination analysis plugin source . 173 C.3 ARM architecture definition for Frama-C . 177 C.4 C representation of U-Boot assembly code . 178 C.5 Frama-C source code patch . 184 D BBxM U-Boot SPL RBWAC policy definition 185 D.1 Region definitions ............................. 185 D.2 Substage definitions and region retyping rules . 189 D.3 U-Boot source code ............................ 191 viii Bibliography 209 List of Figures 1.1 Instances of secure boot adoption since 2010 .............. 4 2.1 Front panel of PDP-11/70 computer . 15 2.2 iOS boot stages and image storage locations . 23 2.3 Mach-O loading commands ....................... 33 3.1 Root shell-backdoor in ELF ping .................... 40 3.2 Root shell-backdoor in Mach-O ping .
Recommended publications
  • Defeating Memory Corruption Attacks Via Pointer Taintedness Detection

    Defeating Memory Corruption Attacks Via Pointer Taintedness Detection

    Defeating Memory Corruption Attacks via Pointer Taintedness Detection Shuo Chen †, Jun Xu ‡, Nithin Nakka †, Zbigniew Kalbarczyk †, Ravishankar K. Iyer † † Center for Reliable and High-Performance Computing, ‡ Department of Computer Science University of Illinois at Urbana-Champaign, North Carolina State University 1308 W. Main Street, Urbana, IL 61801 Raleigh, NC 27695 {shuochen, nakka, kalbar, iyer}@crhc.uiuc.edu [email protected] Abstract formal methods have been adopted to prevent Most malicious attacks compromise system security programmers from writing insecure software. But despite through memory corruption exploits. Recently proposed substantial research and investment, the state of the art is techniques attempt to defeat these attacks by protecting far from perfect, and as a result, security vulnerabilities are program control data. We have constructed a new class of constantly being discovered in the field. The most direct attacks that can compromise network applications without counter-measure against vulnerabilities in the field is tampering with any control data. These non-control data security patching. Patching, however, is reactive in nature attacks represent a new challenge to system security. In and can only be applied to known vulnerabilities. The long this paper, we propose an architectural technique to latency between bug discovery and patching allows defeat both control data and non-control data attacks attackers to compromise many unpatched systems. An based on the notion of pointer taintedness . A pointer is alternative to patching is runtime vulnerability masking said to be tainted if user input can be used as the pointer that can stop ongoing attacks. Compiler and library value. A security attack is detected whenever a tainted interception techniques have been proposed to mask value is dereferenced during program execution.
  • Representing and Reasoning About Dynamic Code

    Representing and Reasoning About Dynamic Code

    Representing and reasoning about dynamic code Item Type Proceedings Authors Bartels, Jesse; Stephens, Jon; Debray, Saumya Citation Bartels, J., Stephens, J., & Debray, S. (2020, September). Representing and Reasoning about Dynamic Code. In 2020 35th IEEE/ACM International Conference on Automated Software Engineering (ASE) (pp. 312-323). IEEE. DOI 10.1145/3324884.3416542 Publisher ACM Journal Proceedings - 2020 35th IEEE/ACM International Conference on Automated Software Engineering, ASE 2020 Rights © 2020 Association for Computing Machinery. Download date 23/09/2021 23:26:56 Item License http://rightsstatements.org/vocab/InC/1.0/ Version Final accepted manuscript Link to Item http://hdl.handle.net/10150/652285 Representing and Reasoning about Dynamic Code Jesse Bartels Jon Stephens Saumya Debray Department of Computer Science Department of Computer Science Department of Computer Science The University Of Arizona University Of Texas The University Of Arizona Tucson, AZ 85721, USA Austin, TX 78712, USA Tucson, AZ 85721, USA [email protected] [email protected] [email protected] ABSTRACT and trace dependencies back, into and through the JIT compiler’s Dynamic code, i.e., code that is created or modified at runtime, is code, to understand the data and control flows that influenced the ubiquitous in today’s world. The behavior of dynamic code can JIT compiler’s actions and caused the generation of the problem- depend on the logic of the dynamic code generator in subtle and non- atic code. E.g., for the CVE-2017-5121 bug mentioned above, we obvious ways, e.g., JIT compiler bugs can lead to exploitable vul- might want to perform automated analyses to identify which anal- nerabilities in the resulting JIT-compiled code.
  • Using the GNU Compiler Collection (GCC)

    Using the GNU Compiler Collection (GCC)

    Using the GNU Compiler Collection (GCC) Using the GNU Compiler Collection by Richard M. Stallman and the GCC Developer Community Last updated 23 May 2004 for GCC 3.4.6 For GCC Version 3.4.6 Published by: GNU Press Website: www.gnupress.org a division of the General: [email protected] Free Software Foundation Orders: [email protected] 59 Temple Place Suite 330 Tel 617-542-5942 Boston, MA 02111-1307 USA Fax 617-542-2652 Last printed October 2003 for GCC 3.3.1. Printed copies are available for $45 each. Copyright c 1988, 1989, 1992, 1993, 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004 Free Software Foundation, Inc. Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with the Invariant Sections being \GNU General Public License" and \Funding Free Software", the Front-Cover texts being (a) (see below), and with the Back-Cover Texts being (b) (see below). A copy of the license is included in the section entitled \GNU Free Documentation License". (a) The FSF's Front-Cover Text is: A GNU Manual (b) The FSF's Back-Cover Text is: You have freedom to copy and modify this GNU Manual, like GNU software. Copies published by the Free Software Foundation raise funds for GNU development. i Short Contents Introduction ...................................... 1 1 Programming Languages Supported by GCC ............ 3 2 Language Standards Supported by GCC ............... 5 3 GCC Command Options .........................
  • The GNU Configure and Build System

    The GNU Configure and Build System

    The GNU configure and build system Ian Lance Taylor Copyright c 1998 Cygnus Solutions Permission is granted to make and distribute verbatim copies of this manual provided the copyright notice and this permission notice are preserved on all copies. Permission is granted to copy and distribute modified versions of this manual under the con- ditions for verbatim copying, provided that the entire resulting derived work is distributed under the terms of a permission notice identical to this one. Permission is granted to copy and distribute translations of this manual into another lan- guage, under the above conditions for modified versions, except that this permission notice may be stated in a translation approved by the Free Software Foundation. i Table of Contents 1 Introduction ............................... 1 1.1 Goals................................................... 1 1.2 Tools ................................................... 1 1.3 History ................................................. 1 1.4 Building ................................................ 2 2 Getting Started............................ 3 2.1 Write configure.in ....................................... 4 2.2 Write Makefile.am ....................................... 6 2.3 Write acconfig.h......................................... 7 2.4 Generate files ........................................... 8 2.5 Example................................................ 8 2.5.1 First Try....................................... 9 2.5.2 Second Try.................................... 10 2.5.3 Third
  • Sok: Make JIT-Spray Great Again

    Sok: Make JIT-Spray Great Again

    SoK: Make JIT-Spray Great Again Robert Gawlik and Thorsten Holz Ruhr-Universitat¨ Bochum Abstract Attacks against client-side programs such as browsers were at first tackled with a non-executable stack to pre- Since the end of the 20th century, it has become clear that vent execution of data on the stack and also with a non- web browsers will play a crucial role in accessing Internet executable heap to stop heap sprays of data being later resources such as the World Wide Web. They evolved executed as code. This defense became widely known into complex software suites that are able to process a as W ⊕ X (Writable xor eXecutable) or Data Execution multitude of data formats. Just-In-Time (JIT) compilation Prevention (DEP) to make any data region non-executable was incorporated to speed up the execution of script code, in 2003 [45, 54]. To counter DEP, attackers started to per- but is also used besides web browsers for performance form code reuse such as Return-Oriented Programming reasons. Attackers happily welcomed JIT in their own (ROP) and many variants [10, 11, 32, 68]. In general, if an way, and until today, JIT compilers are an important target adversary knows the location of static code in the address of various attacks. This includes for example JIT-Spray, space of the vulnerable target, she can prepare a fake stack JIT-based code-reuse attacks and JIT-specific flaws to cir- with addresses of these gadgets. As soon as control of cumvent mitigation techniques in order to simplify the the instruction pointer is gained, these gadgets execute exploitation of memory-corruption vulnerabilities.
  • Rockjit: Securing Just-In-Time Compilation Using Modular Control-Flow Integrity

    Rockjit: Securing Just-In-Time Compilation Using Modular Control-Flow Integrity

    RockJIT: Securing Just-In-Time Compilation Using Modular Control-Flow Integrity Ben Niu Gang Tan Lehigh University Lehigh University 19 Memorial Dr West 19 Memorial Dr West Bethlehem, PA, 18015 Bethlehem, PA, 18015 [email protected] [email protected] ABSTRACT For performance, modern managed language implementations Managed languages such as JavaScript are popular. For perfor- adopt Just-In-Time (JIT) compilation. Instead of performing pure mance, modern implementations of managed languages adopt Just- interpretation, a JIT compiler dynamically compiles programs into In-Time (JIT) compilation. The danger to a JIT compiler is that an native code and performs optimization on the fly based on informa- attacker can often control the input program and use it to trigger a tion collected through runtime profiling. JIT compilation in man- vulnerability in the JIT compiler to launch code injection or JIT aged languages is the key to high performance, which is often the spraying attacks. In this paper, we propose a general approach only metric when comparing JIT engines, as seen in the case of called RockJIT to securing JIT compilers through Control-Flow JavaScript. Hereafter, we use the term JITted code for native code Integrity (CFI). RockJIT builds a fine-grained control-flow graph that is dynamically generated by a JIT compiler, and code heap for from the source code of the JIT compiler and dynamically up- memory pages that hold JITted code. dates the control-flow policy when new code is generated on the fly. In terms of security, JIT brings its own set of challenges. First, a Through evaluation on Google’s V8 JavaScript engine, we demon- JIT compiler is large and usually written in C/C++, which lacks strate that RockJIT can enforce strong security on a JIT compiler, memory safety.
  • Rust: Systems Programmers Can Have Nice Things

    Rust: Systems Programmers Can Have Nice Things

    Rust: Systems Programmers Can Have Nice Things Arun Thomas [email protected] @arunthomas EuroBSDCon 2019 On Systems Programming [A] systems programmer has seen the terrors of the world and understood the intrinsic horror of existence -James Mickens, The Night Watch 2 What Makes Systems Software Hard? • Stakes are High: Systems software is critical to enforcing security and safety • Kernels, hypervisors, firmware, bootloaders, embedded software, language runtimes, browsers, … • Usually written in C or C++ for performance • BUT C and C++ are not memory-safe • Memory corruption vulnerabilities abound (and are exploited) • See recent Microsoft study (next slide) 3 Memory Unsafety is a Problem https://msrc-blog.microsoft.com/2019/07/16/a-proactive-approach-to-more-secure-code/ Microsoft found ~70% of CVEs in their products each year continue to be memory safety issues (Matt Miller, MSRC @ Blue Hat IL 2019) 4 Microsoft and Rust 5 Intel and Rust 6 Talk Overview “Systems Programmers Can Have Nice Things” -Robert O’Callahan Random Thoughts On Rust • Why Rust? • Rust for Systems Software • Getting Started with Rust on BSD 7 Why ust? 8 I like C. 9 But it turns out programming languages have evolved in the last 50 years. 10 Rust is a safe, fast, productive systems programming language. 11 Mozilla and Rust • Rust was originally created by Mozilla Research • Initial use case: Servo browser engine • Mozilla began shipping Rust components in Firefox 48 in 2016 • Oxidation is Mozilla’s term for “Rusting out” components • Rust code has improved Firefox’s
  • Memory Corruption Vulnerabilities, Part II Gang Tan Penn State University Spring 2019

    Memory Corruption Vulnerabilities, Part II Gang Tan Penn State University Spring 2019

    Memory Corruption Vulnerabilities, Part II Gang Tan Penn State University Spring 2019 CMPSC 447, Software Security Integer Overflow Vulnerabilities * slides adapted from those by Seacord 3 Integer Overflows An integer overflow occurs when an integer is increased beyond its maximum value or decreased beyond its minimum value Standard integer types (signed) signed char, short int, int, long int, long long int Signed overflow vs unsigned overflow An unsigned overflow occurs when the underlying representation can no longer represent an integer value. A signed overflow occurs when a value is carried over to the sign bit 4 Overflow Examples unsigned int ui; signed int si; ui = UINT_MAX; // 4,294,967,295; ui++; ui = 0 printf(“ui = %u\n", ui); si = INT_MAX; // 2,147,483,647 si++; si = -2,147,483,648 printf(“si = %d\n", si); 5 Overflow Examples, cont’d ui = 0; ui‐‐; ui = 4,294,967,295 printf(“ui = %u\n", ui); si = INT_MIN; // ‐2,147,483,648; si‐‐; si = 2,147,483,647 printf(“si = %d\n", si); 6 Integer Overflow Example int main(int argc, char *const *argv) { unsigned short int total; total = strlen(argv[1]) + strlen(argv[2]) + 1; char *buff = (char *) malloc(total); strcpy(buff, argv[1]); strcat(buff, argv[2]); } What if the total variable is overflowed because of the addition operation? 7 Vulnerability: JPEG Example Based on a real‐world vulnerability in the handling of the comment field in JPEG files void getComment(unsigned int len, char *src) { unsigned int size; size is interpreted as a large size = len ‐ 2; positive value of 0xffffffff
  • Release 0.11 Todd Gamblin

    Release 0.11 Todd Gamblin

    Spack Documentation Release 0.11 Todd Gamblin Feb 07, 2018 Basics 1 Feature Overview 3 1.1 Simple package installation.......................................3 1.2 Custom versions & configurations....................................3 1.3 Customize dependencies.........................................4 1.4 Non-destructive installs.........................................4 1.5 Packages can peacefully coexist.....................................4 1.6 Creating packages is easy........................................4 2 Getting Started 7 2.1 Prerequisites...............................................7 2.2 Installation................................................7 2.3 Compiler configuration..........................................9 2.4 Vendor-Specific Compiler Configuration................................ 13 2.5 System Packages............................................. 16 2.6 Utilities Configuration.......................................... 18 2.7 GPG Signing............................................... 20 2.8 Spack on Cray.............................................. 21 3 Basic Usage 25 3.1 Listing available packages........................................ 25 3.2 Installing and uninstalling........................................ 42 3.3 Seeing installed packages........................................ 44 3.4 Specs & dependencies.......................................... 46 3.5 Virtual dependencies........................................... 50 3.6 Extensions & Python support...................................... 53 3.7 Filesystem requirements........................................
  • Gnu Libiberty September 2001 for GCC 3

    Gnu Libiberty September 2001 for GCC 3

    gnu libiberty September 2001 for GCC 3 Phil Edwards et al. Copyright c 2001 Free Software Foundation, Inc. Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, with no Front-Cover Texts, and with no Back-Cover Texts. A copy of the license is included in the section entitled “GNU Free Documentation License”. i Table of Contents 1 Using ............................................ 1 2 Overview ........................................ 2 2.1 Supplemental Functions ........................................ 2 2.2 Replacement Functions ......................................... 2 2.2.1 Memory Allocation ........................................ 2 2.2.2 Exit Handlers ............................................. 2 2.2.3 Error Reporting ........................................... 2 2.3 Extensions ..................................................... 3 3 Obstacks......................................... 4 3.1 Creating Obstacks.............................................. 4 3.2 Preparing for Using Obstacks................................... 4 3.3 Allocation in an Obstack ....................................... 5 3.4 Freeing Objects in an Obstack.................................. 6 3.5 Obstack Functions and Macros ................................. 7 3.6 Growing Objects ............................................... 8 3.7 Extra Fast Growing Objects ...................................
  • Practical Control-Flow Integrity

    Practical Control-Flow Integrity

    Practical Control-Flow Integrity by Ben Niu Presented to the Graduate and Research Committee of Lehigh University in Candidacy for the Degree of Doctor of Philosophy in Computer Science Lehigh University January, 2016 Copyright © 2015 Ben Niu. All rights reserved. ii Approved and recommended for acceptance as a dissertation in partial fulfillment of the re- quirements for the degree of Doctor of Philosophy. Ben Niu Practical Control-Flow Integrity Date Gang Tan, Dissertation Director Accepted Date Committee Members Gang Tan (Chair) Mooi-Choo Chuah Michael Spear Stephen McCamant iii ACKNOWLEDGEMENTS I am very grateful to my great advisor Prof. Gang Tan. I had no idea how to do research when I came to Lehigh, and he taught me what to think of, how to think, how to present my thoughts, and how to write them down. His door was always open for discussion, he replied emails during weekends, and he provided detailed guidance on any technical problem. I was constantly surprised at his breadth of knowledge and depth of understanding, and I enjoyed working with him. I also thank my thesis committee members, Prof. Mooi-Choo Chuah, Prof. Michael Spear, and Prof. Stephen McCamant for their courses, research works and insightful comments on my research. Michael’s parallel programming course introduced me lock-free algorithms and his operating system course consolidated my system programming skills. Stephen’s research on SFI provided me a foundation in my research, without which I would be still looking for decent solutions. I appreciate my colleagues at MSRC during my internship at Microsoft, especially Matt & Ken, Suha, Vishal, Swamy, Joe, Axel and Marcus.
  • Kafl: Hardware-Assisted Feedback Fuzzing for OS Kernels

    Kafl: Hardware-Assisted Feedback Fuzzing for OS Kernels

    kAFL: Hardware-Assisted Feedback Fuzzing for OS Kernels Sergej Schumilo1, Cornelius Aschermann1, Robert Gawlik1, Sebastian Schinzel2, Thorsten Holz1 1Ruhr-Universität Bochum, 2Münster University of Applied Sciences Motivation IJG jpeg libjpeg-turbo libpng libtiff mozjpeg PHP Mozilla Firefox Internet Explorer PCRE sqlite OpenSSL LibreOffice poppler freetype GnuTLS GnuPG PuTTY ntpd nginx bash tcpdump JavaScriptCore pdfium ffmpeg libmatroska libarchive ImageMagick BIND QEMU lcms Adobe Flash Oracle BerkeleyDB Android libstagefright iOS ImageIO FLAC audio library libsndfile less lesspipe strings file dpkg rcs systemd-resolved libyaml Info-Zip unzip libtasn1OpenBSD pfctl NetBSD bpf man mandocIDA Pro clamav libxml2glibc clang llvmnasm ctags mutt procmail fontconfig pdksh Qt wavpack OpenSSH redis lua-cmsgpack taglib privoxy perl libxmp radare2 SleuthKit fwknop X.Org exifprobe jhead capnproto Xerces-C metacam djvulibre exiv Linux btrfs Knot DNS curl wpa_supplicant Apple Safari libde265 dnsmasq libbpg lame libwmf uudecode MuPDF imlib2 libraw libbson libsass yara W3C tidy- html5 VLC FreeBSD syscons John the Ripper screen tmux mosh UPX indent openjpeg MMIX OpenMPT rxvt dhcpcd Mozilla NSS Nettle mbed TLS Linux netlink Linux ext4 Linux xfs botan expat Adobe Reader libav libical OpenBSD kernel collectd libidn MatrixSSL jasperMaraDNS w3m Xen OpenH232 irssi cmark OpenCV Malheur gstreamer Tor gdk-pixbuf audiofilezstd lz4 stb cJSON libpcre MySQL gnulib openexr libmad ettercap lrzip freetds Asterisk ytnefraptor mpg123 exempi libgmime pev v8 sed awk make