DOCSLIB.ORG

Static Binary Instrumentation with Applications to COTS Software Security

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Static Binary Instrumentation with Applications to COTS Software Security Static Binary Instrumentation with Applications to COTS Software Security A Dissertation presented by Mingwei Zhang to The Graduate School in Partial Fulfillment of the Requirements for the Degree of Doctor of Philosophy in Computer Science Stony Brook University August 2015 Copyright by Mingwei Zhang 2015 Stony Brook University The Graduate School Mingwei Zhang We, the dissertation committee for the above candidate for the Doctor of Philosophy degree, hereby recommend acceptance of this dissertation R. Sekar - Dissertation Advisor Professor in Department of Computer Science Mike Ferdman - Chairperson of Defense Assistant Professor in Department of Computer Science Michalis Polychronakis - Committee Member Assistant Professor in Department of Computer Science Zhiqiang Lin - Committee Member Assistant Professor in Department of Computer Science University of Texas at Dallas This dissertation is accepted by the Graduate School Charles Taber Dean of the Graduate School ii Abstract of the Dissertation Static Binary Instrumentation with Applications to COTS Software Security by Mingwei Zhang Doctor of Philosophy in Computer Science Stony Brook University 2015 Binary instrumentation has assumed an important role in software security, as well as related areas such as debugging and monitoring. Binary instrumentation can be performed statically or dynamically. Static binary instrumentation (SBI) is attractive because of its simplicity and efficiency. However, none of the previous SBI systems support secure instrumentation of COTS binaries. This is because of several challenges including: (a) static binary code disassembly errors, (b) dif- ficulty of handling indirect control flow transfers, (c) ensuring completeness of instrumentation, i.e., instrumenting all of the code, including code contained in system libraries and compiler-generated stubs, and (d) maintaining compatibility with complex code, i.e., ensuring that the instrumentation does not break any existing code. We have developed a new static binary instrumentation approach, and present a software platform called PSI that implements this approach. PSI integrates a coarse grained control flow integrity (CFI) property as the basis of secure, non- bypassable instrumentation. PSI scales to large and complex stripped binaries, including low-level system libraries. It provides a powerful API that simplifies the development of custom instrumentations. We describe our approach, present several interesting security instrumentations, and analyze the performance of PSI. Our experiments on several real-world ap- plications demonstrate that PSI's runtime overheads are about an order of mag- nitude smaller than that of the most popular platforms available today, such as iii DynamoRIO and Pin. (Both these platforms rely on dynamic instrumentation.) PSI has been tested on over 300 MB of binaries. In addition to our platform PSI, we describe two novel security applications de- veloped using PSI. First, we present a comprehensive defense against injected code attacks that ensures code integrity at all times, even against very power- ful adversaries. Second, we present a defense against code reuse attacks such as return-oriented programming (ROP) that is effective against adversaries possess- ing a wide range of capabilities. iv Dedicated to my wife, my parents and friends. v Contents Abstract iii Contents vi List of Figuresx Acknowledgements xii 1 Introduction1 1.1 Existing binary instrumentation techniques..............1 1.2 Challenges of static binary instrumentation..............2 1.3 Contributions..............................5 1.4 Dissertation organization........................6 2 Core Static Binary Instrumentation Techniques7 2.1 Binary disassembly...........................7 2.1.1 Existing disassembly techniques................7 2.1.2 PSI disassembly algorithm...................9 2.1.3 Disassembler implementation................. 10 2.2 Binary analysis............................. 11 2.2.1 Identifying code pointer constants............... 12 2.2.2 Identifying computed code pointers.............. 12 2.2.3 Identifying other code addresses................ 15 2.3 Binary instrumentation......................... 15 2.3.1 Background........................... 15 2.3.2 Binary instrumentation in PSI................. 17 2.3.3 Address translation for indirect control transfer....... 17 2.3.4 Signal handling......................... 19 2.3.5 Modular instrumentation.................... 20 2.4 Optimizations.............................. 21 2.4.1 Improving branch prediction.................. 22 2.4.2 Avoiding address translation.................. 23 2.4.3 Removing transparency..................... 24 vi 2.5 Control flow integrity policy...................... 24 2.5.1 Definition of control flow integrity............... 25 2.5.2 CFI policies and strength evaluation............. 25 2.5.3 Coarser grained CFIs..................... 27 2.5.4 Non-bypassable instrumentation................ 29 2.5.5 Formal proof of non-bypassable instrumentation....... 31 2.6 Summary................................ 35 3 Platform Implementation, API and Evaluation 36 3.1 System implementation......................... 36 3.2 Instrumentation API.......................... 38 3.2.1 Insertion of assembly code snippets.............. 39 3.2.2 Insertion of calls to instrumentation functions........ 39 3.2.3 Controlling address translation................ 40 3.2.4 Runtime event handling.................... 41 3.2.5 Development of instrumentation tools............. 42 3.3 On-demand instrumentation...................... 43 3.4 Illustrative instrumentation examples................. 44 3.4.1 Basic block counting...................... 44 3.4.2 System call policy enforcement................ 46 3.4.3 Library load policy enforcement................ 46 3.4.4 Shadow stack.......................... 46 3.5 System Evaluation........................... 49 3.5.1 Functionality.......................... 50 3.5.1.1 Testing transformed code.............. 50 3.5.1.2 Correctness of disassembly.............. 51 3.5.1.3 Testing code generated by alternative compilers.. 52 3.5.2 Security evaluation....................... 52 3.5.2.1 CFI effectiveness evaluation............. 52 3.5.2.2 Control-Flow hijack attacks............. 53 3.5.2.3 ROP attacks..................... 54 3.5.3 Performance evaluation on baseline system.......... 55 3.5.3.1 CPU intensive benchmarks............. 56 3.5.3.2 Microbenchmarks................... 58 3.5.3.3 Commonly used applications............ 59 3.5.4 Performance evaluation on sample instrumentations..... 62 3.5.4.1 Basic-block counting................. 62 3.5.4.2 Shadow stack..................... 63 3.6 Summary................................ 63 4 Application: Practical Protection From Code Reuse Attacks 65 4.1 Motivation................................ 65 4.2 Threat model.............................. 68 4.3 System design overview......................... 68 vii 4.4 Code pointer remapping........................ 69 4.4.1 Tightening baseline policy................... 70 4.4.2 Remapping code pointers.................... 71 4.5 Code space isolation.......................... 74 4.5.1 Static analysis for identifying data.............. 76 4.5.2 Separating instrumented code from original code....... 77 4.5.2.1 Protecting instrumented code............ 78 4.5.2.2 Protecting global address translation table..... 79 4.5.2.3 Protecting internal data structures......... 80 4.5.3 Randomization......................... 80 4.6 Implementation............................. 81 4.7 Evaluation............................... 84 4.7.1 Code pointer remapping.................... 84 4.7.2 Static analysis.......................... 84 4.7.3 Strength of randomization................... 86 4.7.4 Runtime performance...................... 87 4.7.5 GUI program startup overhead................ 88 4.8 Discussion............................... 89 4.8.1 Harvesting return addresses.................. 89 4.8.2 Call-oriented programming................... 90 4.9 Summary................................ 91 5 Application: Comprehensive Protection From Code Injection At- tacks 92 5.1 Motivation................................ 92 5.1.1 Property and Approach.................... 94 5.1.2 Key features........................... 95 5.2 Possible code injection vectors..................... 96 5.2.1 Direct attacks.......................... 97 5.2.2 Loader subversion attacks................... 97 5.2.2.1 Control hijacking attacks.............. 97 5.2.2.2 Data corruption attacks............... 98 5.2.2.3 Attacks based on data races............. 99 5.2.3 Case study: code injection using text relocation....... 100 5.2.3.1 Bypassing ASLR................... 100 5.2.3.2 Corrupting loader data structure.......... 101 5.2.3.3 Invoke text relocation function........... 102 5.3 System design.............................. 103 5.3.1 State model........................... 103 5.3.2 State model enforcement.................... 104 5.3.2.1 Operation to open a library............. 104 5.3.2.2 Operations to map file into memory........ 106 5.3.2.3 Segment boundaries................. 106 5.3.3 Code integrity enforcement................... 107 viii 5.3.4 Library loading policy..................... 109 5.3.5 Compatibility with code patching............... 110 5.3.6 Protected memory....................... 110 5.3.7 Support for dynamic code................... 112 5.4 Implementation............................. 114 5.5 Evaluation............................... 114 5.5.1 Micro-benchmark for program loading...........
Load more

Recommended publications
  • Dynamic Optimization of IA-32 Applications Under Dynamorio by Timothy Garnett
    Dynamic Optimization of IA-32 Applications Under DynamoRIO by Timothy Garnett Submitted to the Department of Electrical Engineering and Computer Science in Partial Fulfillment of the Requirements for the Degree of Master of Engineering in Computer Science Abstract The ability of compilers to optimize programs statically is diminishing. The advent and increased use of shared libraries, dynamic class loading, and runtime binding means that the compiler has, even with difficult to accurately obtain profiling data, less and less knowledge of the runtime state of the program. Dynamic optimization systems attempt to fill this gap by providing the ability to optimize the application at runtime when more of the system's state is known and very accurate profiling data can be obtained. This thesis presents two uses of the DynamoRIO runtime introspection and modification system to optimize applications at runtime. The first is a series of optimizations for interpreters running under DynamoRIO's logical program counter extension. The optimizations include extensions to DynamoRIO to allow the interpreter writer add a few annotations to the source code of his interpreter that enable large amounts of optimization. For interpreters instrumented as such, improvements in performance of 20 to 60 percent were obtained. The second use is a proof of concept for accelerating the performance of IA-32 applications running on the Itanium processor by dynamically translating hot trace paths into Itanium IA-64 assembly through DynamoRIO while allowing the less frequently executed potions of the application to run in Itanium's native IA-32 hardware emulation. This transformation yields speedups of almost 50 percent on small loop intensive benchmarks.
    [Show full text]
  • Dynamic Binary Translation & Instrumentation
    Dynamic Binary Translation & Instrumentation Pin Building Customized Program Analysis Tools with Dynamic Instrumentation CK Luk, Robert Cohn, Robert Muth, Harish Patil, Artur Klauser, Geoff Lowney, Steven Wallace, Kim Hazelwood Intel Vijay Janapa Reddi University of Colorado http://rogue.colorado.edu/Pin PLDI’05 2 Instrumentation • Insert extra code into programs to collect information about execution • Program analysis: • Code coverage, call-graph generation, memory-leak detection • Architectural study: • Processor simulation, fault injection • Existing binary-level instrumentation systems: • Static: • ATOM, EEL, Etch, Morph • Dynamic: • Dyninst, Vulcan, DTrace, Valgrind, Strata, DynamoRIO C Pin is a new dynamic binary instrumentation system PLDI’05 3 A Pintool for Tracing Memory Writes #include <iostream> #include "pin.H" executed immediately before a FILE* trace; write is executed • Same source code works on the 4 architectures VOID RecordMemWrite(VOID* ip, VOID* addr, UINT32 size) { fprintf(trace,=> “%p: Pin Wtakes %p %dcare\n”, of ip, different addr, size); addressing modes } • No need to manually save/restore application state VOID Instruction(INS ins, VOID *v) { if (INS_IsMemoryWrite(ins))=> Pin does it for you automatically and efficiently INS_InsertCall(ins, IPOINT_BEFORE, AFUNPTR(RecordMemWrite), IARG_INST_PTR, IARG_MEMORYWRITE_EA, IARG_MEMORYWRITE_SIZE, IARG_END); } int main(int argc, char * argv[]) { executed when an instruction is PIN_Init(argc, argv); dynamically compiled trace = fopen(“atrace.out”, “w”); INS_AddInstrumentFunction(Instruction,
    [Show full text]
  • Pin: Building Customized Program Analysis Tools with Dynamic Instrumentation
    Pin: Building Customized Program Analysis Tools with Dynamic Instrumentation Chi-Keung Luk Robert Cohn Robert Muth Harish Patil Artur Klauser Geoff Lowney Steven Wallace Vijay Janapa Reddi Kim Hazelwood Intel Corporation ¡ University of Colorado ¢¤£¦¥¨§ © £ ¦£ "! #%$&'( £)&(¦*+©-,.+/01$©-!2 ©-,2¦3 45£) 67©2, £¦!2 "0 Abstract 1. Introduction Robust and powerful software instrumentation tools are essential As software complexity increases, instrumentation—a technique for program analysis tasks such as profiling, performance evalu- for inserting extra code into an application to observe its behavior— ation, and bug detection. To meet this need, we have developed is becoming more important. Instrumentation can be performed at a new instrumentation system called Pin. Our goals are to pro- various stages: in the source code, at compile time, post link time, vide easy-to-use, portable, transparent, and efficient instrumenta- or at run time. Pin is a software system that performs run-time tion. Instrumentation tools (called Pintools) are written in C/C++ binary instrumentation of Linux applications. using Pin’s rich API. Pin follows the model of ATOM, allowing the The goal of Pin is to provide an instrumentation platform for tool writer to analyze an application at the instruction level with- building a wide variety of program analysis tools for multiple archi- out the need for detailed knowledge of the underlying instruction tectures. As a result, the design emphasizes ease-of-use, portabil- set. The API is designed to be architecture independent whenever ity, transparency, efficiency, and robustness. This paper describes possible, making Pintools source compatible across different archi- the design of Pin and shows how it provides these features.
    [Show full text]
  • Netflix Security Requirements for Android Platforms Version 1.0 December 6, 2010
    Netflix Security Requirements for Android Platforms Version 1.0 December 6, 2010 Netflix Confidential Overall Security Philosophy • Netflix and Partners are working together to create a market for connected platforms and services • For long-term success, this requires a healthy and secure ecosystem – Based on best practices – Transparency between content, service, and platform partners – Proactive cooperation, rapid response • Our mutual success depends on it – Breaches hurt everyone Netflix Confidential Typical Studio Requirements • Platforms must meet agreed-upon robustness specifications (Netflix Robustness Rules, DRM providers’ robustness rules) • Platform partners must submit sample products and security documentation to Netflix for certification. – Netflix must review documentation and assess compliance with robustness specifications • If a platform is breached, Netflix or partner may be required to revoke individual or class of platforms. • In case of extended breach or platform non-compliance, studio has option to suspend availability of content to the Netflix service. – Such action would adversely affect all platforms and all Netflix subscribers. Netflix Confidential Android vs. Studio Requirements • Most Android platforms have been “rooted” – yields full control of system – history suggests this problem will not go away • Once rooting occurs, Linux security model is insufficient to protect content -related assets • Without modification, these platforms do not allow Netflix to meet contractual obligations to studios • We are aggressively working with partners to address this vulnerability Netflix Confidential High-Level Platform Security Concerns • Content Protection – DRM keys – Content keys – AV content • Application Security – Application keys – Access to Netflix APIs & functionality – Non-modifiability – Non-migrateability Netflix Confidential Content Protection: DRM Keys • Group key – typically provisioned in manufacturing – one key for entire class of devices (e.g.
    [Show full text]
  • Structuring the Smartphone Industry: Is the Mobile Internet OS Platform the Key?
    A Service of Leibniz-Informationszentrum econstor Wirtschaft Leibniz Information Centre Make Your Publications Visible. zbw for Economics Kenney, Martin; Pon, Bryan Working Paper Structuring the smartphone industry: Is the mobile internet OS platform the key? ETLA Discussion Papers, No. 1238 Provided in Cooperation with: The Research Institute of the Finnish Economy (ETLA), Helsinki Suggested Citation: Kenney, Martin; Pon, Bryan (2011) : Structuring the smartphone industry: Is the mobile internet OS platform the key?, ETLA Discussion Papers, No. 1238, The Research Institute of the Finnish Economy (ETLA), Helsinki This Version is available at: http://hdl.handle.net/10419/44498 Standard-Nutzungsbedingungen: Terms of use: Die Dokumente auf EconStor dürfen zu eigenen wissenschaftlichen Documents in EconStor may be saved and copied for your Zwecken und zum Privatgebrauch gespeichert und kopiert werden. personal and scholarly purposes. Sie dürfen die Dokumente nicht für öffentliche oder kommerzielle You are not to copy documents for public or commercial Zwecke vervielfältigen, öffentlich ausstellen, öffentlich zugänglich purposes, to exhibit the documents publicly, to make them machen, vertreiben oder anderweitig nutzen. publicly available on the internet, or to distribute or otherwise use the documents in public. Sofern die Verfasser die Dokumente unter Open-Content-Lizenzen (insbesondere CC-Lizenzen) zur Verfügung gestellt haben sollten, If the documents have been made available under an Open gelten abweichend von diesen Nutzungsbedingungen
    [Show full text]
  • Internet of Nano-Things, Things and Everything: Future Growth Trends
    future internet Review Internet of Nano-Things, Things and Everything: Future Growth Trends Mahdi H. Miraz 1 ID , Maaruf Ali 2, Peter S. Excell 3,* and Richard Picking 3 1 Centre for Financial Regulation and Economic Development (CFRED), The Chinese University of Hong Kong, Sha Tin, Hong Kong, China; [email protected] 2 International Association of Educators and Researchers (IAER), Kemp House, 160 City Road, London EC1V 2NX, UK; [email protected] 3 Faculty of Art, Science and Technology, Wrexham Glyndwrˆ University, Wrexham LL11 2AW, UK; [email protected] * Correspondence: [email protected]; Tel.: +44-797-480-6644 Received: 22 June 2018; Accepted: 25 July 2018; Published: 28 July 2018 Abstract: The current statuses and future promises of the Internet of Things (IoT), Internet of Everything (IoE) and Internet of Nano-Things (IoNT) are extensively reviewed and a summarized survey is presented. The analysis clearly distinguishes between IoT and IoE, which are wrongly considered to be the same by many commentators. After evaluating the current trends of advancement in the fields of IoT, IoE and IoNT, this paper identifies the 21 most significant current and future challenges as well as scenarios for the possible future expansion of their applications. Despite possible negative aspects of these developments, there are grounds for general optimism about the coming technologies. Certainly, many tedious tasks can be taken over by IoT devices. However, the dangers of criminal and other nefarious activities, plus those of hardware and software errors, pose major challenges that are a priority for further research. Major specific priority issues for research are identified.
    [Show full text]
  • An Infrastructure for Adaptive Dynamic Optimization
    An Infrastructure for Adaptive Dynamic Optimization Derek Bruening, Timothy Garnett, and Saman Amarasinghe Laboratory for Computer Science Massachusetts Institute of Technology Cambridge, MA 02139 fiye,timothyg,[email protected] Abstract ing profile information improves the predictions but still falls short for programs whose behavior changes dynami- Dynamic optimization is emerging as a promising ap- cally. Additionally, many software vendors are hesitant to proach to overcome many of the obstacles of traditional ship binaries that are compiled with high levels of static op- static compilation. But while there are a number of com- timization because they are hard to debug. piler infrastructures for developing static optimizations, Shifting optimizations to runtime solves these problems. there are very few for developing dynamic optimizations. Dynamic optimization allows the user to improve the per- We present a framework for implementing dynamic analy- formance of binaries without relying on how they were ses and optimizations. We provide an interface for build- compiled. Furthermore, several types of optimizations are ing external modules, or clients, for the DynamoRIO dy- best suited to a dynamic optimization framework. These in- namic code modification system. This interface abstracts clude adaptive, architecture-specific, and inter-module opti- away many low-level details of the DynamoRIO runtime mizations. system while exposing a simple and powerful, yet efficient Adaptive optimizations require instant responses to and lightweight, API. This is achieved by restricting opti- changes in program behavior. When performed statically, a mization units to linear streams of code and using adaptive single profiling run is taken to be representative of the pro- levels of detail for representing instructions.
    [Show full text]
  • Using Dynamic Binary Instrumentation for Security(And How You May Get
    King’s Research Portal Document Version Peer reviewed version Link to publication record in King's Research Portal Citation for published version (APA): Cono D'Elia, D., Coppa, E., Palmaro, F., & Cavallaro, L. (Accepted/In press). SoK: Using Dynamic Binary Instrumentation for Security (And How You May Get Caught Red Handed). In ACM Asia Conference on Information, Computer and Communications Security (ASIACCS 2019) Citing this paper Please note that where the full-text provided on King's Research Portal is the Author Accepted Manuscript or Post-Print version this may differ from the final Published version. If citing, it is advised that you check and use the publisher's definitive version for pagination, volume/issue, and date of publication details. And where the final published version is provided on the Research Portal, if citing you are again advised to check the publisher's website for any subsequent corrections. General rights Copyright and moral rights for the publications made accessible in the Research Portal are retained by the authors and/or other copyright owners and it is a condition of accessing publications that users recognize and abide by the legal requirements associated with these rights. •Users may download and print one copy of any publication from the Research Portal for the purpose of private study or research. •You may not further distribute the material or use it for any profit-making activity or commercial gain •You may freely distribute the URL identifying the publication in the Research Portal Take down policy If you believe that this document breaches copyright please contact [email protected] providing details, and we will remove access to the work immediately and investigate your claim.
    [Show full text]
  • Id, Conf 20Xx
    ID, CONF 20XX - Where is the policy enforced? -- When is the policy imposed? -- What is protected by the policy? (fine grained) -- What is protected by the policy? (coarse grained) -- Requirements of the person applying the sandbox -- Requirements of the application -- Security Policy Type -- Policy enforcements place in kill chain -- Policy Management -- Policy Construction -- Validation Claim -- Validation -- KCoFI, Oakland 2014 - Where is the policy enforced? -- System: “KCoFI protects commodity operating systems from classical control- flow hijack attacks, return-to-user attacks, and code segment modification attacks.” When is the policy imposed? -- Hybrid: “KCoFI has several unique requirements. First, it must instrument commodity OS kernel code; existing CFI enforcement mechanisms use either compiler or binary instrumentation [4], [10], [18]. Second, KCoFI must understand how and when OS kernel code interacts with the hardware. For example, it must understand when the OS is modifying hardware page tables in order to prevent errors like writeable and executable memory. Third, KCoFI must be able to control modification of interrupted program state in order to prevent ret2usr attacks.” What is protected by the policy? (fine grained) -- Code instructions: See Where is the policy enforced? What is protected by the policy? (coarse grained) -- System Level Component: See Where is the policy enforced? Requirements of the person applying the sandbox -- Install a tool: “The SVA-OS instructions described later in this section are implemented as a run-time library that is linked into the kernel.” Requirements of the application -- Use special compiler: “All software, including the operating system and/or hypervisor, is compiled to the virtual instruction set that SVA provides.” Requirements of the application -- Use sandbox as framework/library: “Because the operating system must interface with the hardware via the SVA-OS instructions, it must be ported to the SVA virtual instruction set.
    [Show full text]
  • Coverage-Guided Fuzzing of Grpc Interface
    Niko Lappalainen COVERAGE-GUIDED FUZZING OF GRPC INTERFACE Master of Science Thesis Faculty of Information Technology and Communication Sciences Examiners: Marko Helenius Billy Brumley January 2021 i ABSTRACT Niko Lappalainen: Coverage-guided fuzzing of gRPC interface Master of Science Thesis Tampere University Master’s Degree Programme in Information Technology January 2021 Fuzz testing has emerged as a cost-effective method of finding security issues in many real- world targets. The software company M-Files Inc. wanted to incorporate fuzz testing to harden the security of their product M-Files Server. The newly implemented gRPC API was set as the target interface to be fuzzed. This thesis was requested to find a suitable fuzzing tool, and to verify that the tool could find and report issues. Another objective of this thesis was to determine a criterion for stopping fuzzing when adequate testing coverage has been achieved without having to run the fuzzer perpetually. To select a suitable fuzzing tool, some requirements had to be defined. Requirements and selection criteria were set based on the properties of the M-Files system as well as the target interface. Next, various fuzzing tool options were gathered from different sources. These options were validated based on the set requirements to select a short list of tools that could be analysed more closely. The suitable tool was selected from these based on their ease of integration and suspected performance. The coverage-guided WinAFL was evaluated as the most suitable from the considered options. The selected fuzzing tool was used to test M-Files Server in order to record its results.
    [Show full text]
  • Valgrind a Framework for Heavyweight Dynamic Binary
    VValgrindalgrind AA FramFrameweworkork forfor HHeavyweavyweighteight DDynamynamicic BBinaryinary InstrumInstrumentationentation Nicholas Nethercote — National ICT Australia Julian Seward — OpenWorks LLP 1 FAFAQQ #1#1 • How do you pronounce “Valgrind”? • “Val-grinned”, not “Val-grined” • Don’t feel bad: almost everyone gets it wrong at first 2 DDBBAA toolstools • Program analysis tools are useful – Bug detectors – Profilers – Visualizers • Dynamic binary analysis (DBA) tools – Analyse a program’s machine code at run-time – Augment original code with analysis code 3 BBuildinguilding DDBBAA toolstools • Dynamic binary instrumentation (DBI) – Add analysis code to the original machine code at run-time – No preparation, 100% coverage • DBI frameworks – Pin, DynamoRIO, Valgrind, etc. Tool Framework + = Tool plug-in 4 PriorPrior wworkork Well-studied Not well-studied Framework performance Instrumentation capabilities Simple tools Complex tools • Potential of DBI has not been fully exploited – Tools get less attention than frameworks – Complex tools are more interesting than simple tools 5 ShadowShadow valuevalue toolstools 6 ShadowShadow valuevalue toolstools (I)(I) • Shadow every value with another value that describes it – Tool stores and propagates shadow values in parallel Tool(s) Shadow values help find... Memcheck Uses of undefined values bugs Annelid Array bounds violations Hobbes Run-time type errors TaintCheck, LIFT, TaintTrace Uses of untrusted values security “Secret tracker” Leaked secrets DynCompB Invariants properties Redux Dynamic
    [Show full text]
  • Closed Systems” an AnTrust Problem?
    Volume 7 I Number 1 I Spring 2011 Are “Closed Systems” an Antrust Problem? Hanno F. Kaiser Latham & Watkins LLP Published in Compeon Policy Internaonal (print ISSN 1554-0189, online Copyright © 2011 ISSN 1554-6853) Spring 2011, Vol. 7. No. 1. For more arcles and Compeon Policy Internaonal, I informaon, visit www.compeonpolicyinternaonal.com Inc. Are “Closed Systems” an Antitrust Problem? By Hanno F. Kaiser* losed computer systems have come under attack as harmful to freedom, Cinnovation, and competition. Open computer systems, in contrast, are said to promote such values. This article assesses the specific claim that closed sys- tems, compared to open systems, are inherently anticompetitive. It concludes that competition policy arguments against closed systems are at best inconclu- sive and that closed systems should not be put in an antitrust suspect class. *Partner, Latham & Watkins LLP, San Francisco. The views in this article are my own, so please do not impute them to my firm or my clients. This article is licensed under a Creative Commons Attribution 3.0 license. 91 Hanno F. Kaiser I. Civic and Economic Criticisms of “Closed Systems” In his influential book The Future of the Internet and How to Stop It1 Jonathan Zittrain argues that we are headed for a future in which general purpose comput- ers, which he calls “generative systems,” will be replaced by locked-down, teth- ered computing appliances:2 “The PC revolution was launched with PCs that invited innovation by oth- ers. So, too, with the Internet. Both were generative: they were designed to accept any contribution that followed a basic set of rules (either coded for a particular operating system, or respecting the protocols of the Internet.
    [Show full text]