DOCSLIB.ORG

Memory Error Detection for Large-Scale Applications and Fuzz Testing

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Memory Error Detection for Large-Scale Applications and Fuzz Testing Enhancing Memory Error Detection for Large-Scale Applications and Fuzz testing Wookhyun Han, Byunggil Joe, Byoungyoung Lee*, Chengyu Song†, Insik Shin KAIST, *Purdue, †UCR 1 Memory error glibc: getaddrinfo Heartbleed Shellshock stack-based buffer overflow • Information leakage – Heartbleed • Privilege escalation – Shellshock • Remote code execution – Shellshock, glibc, Conficker 2 Memory error detection • Pointer-based [SoftBound+CETS, Intel MPX] • Hardware support (cannot detect temporal memory errors) • Challenges to support complex applications • Redzone-based [AddressSanitizer (ASan)] • Compatible to complex applications • Most popular in practice Google Chrome, Mozilla Firefox, Linux Kernel American Fuzzy Lop (AFL), ClusterFuzz, OSS-Fuzz 3 Redzone-based memory error detection • Buffer overflow (spatial memory errors) ptrX Shadow memory: a bitmap to validate all addresses objX Check before access Shadow memory Accessible 4 Redzone-based memory error detection • Buffer overflow (spatial memory errors) ptrX Shadow memory: a bitmap to validate all addresses objX Check before access Redzone: inaccessible region between objects Shadow memory Accessible Inaccessible (redzone) 4 Redzone-based memory error detection • Buffer overflow (spatial memory errors) ptrX Shadow memory: a bitmap to validate all addresses objX Error! Redzone: inaccessible region between objects Shadow memory Accessible Inaccessible (redzone) 4 Redzone-based memory error detection • Use-after-free (temporal memory errors) ptrX objX Accessible Inaccessible Shadow memory 5 Redzone-based memory error detection • Use-after-free (temporal memory errors) ptrX ptrX objX free(ptrX) Quarantined Region is invalidated and quarantined, but not actually deallocated Accessible Inaccessible Shadow memory 5 Redzone-based memory error detection • Use-after-free (temporal memory errors) ptrX ptrX Hold the objX free(ptrX) Quarantined region until quarantine zone is full (FIFO) Accessible Inaccessible Shadow memory 5 Redzone-based memory error detection • Use-after-free (temporal memory errors) ptrX ptrX ptrY ptrY = Quarantined malloc() TheobjX regionfree( ptrXis )actually objY deallocated, and can be allocated to a new object Accessible Inaccessible Shadow memory 5 Limitations of redzone-based approach 1. What if a pointer accesses beyond redzone? ptrX objX objY 6 Limitations of redzone-based approach 1. What if a pointer accesses beyond redzone? objX ptrX objY Spatial memory error 6 Limitations of redzone-based approach 1. What if a pointer 2. What if a dangling pointer accesses beyond accesses after another object redzone? is allocated in the region? objX ptrX ptrX objY objX Spatial memory error 6 Limitations of redzone-based approach 1. What if a pointer 2. What if a dangling pointer accesses beyond accesses after another object redzone? is allocated in the region? objX ptrX ptrX ptrX objY objX objZ Spatial memory error Temporal memory error 6 Limitations of redzone-based approach 1. What if a pointer 2. What if a dangling pointer accesses beyond accesses after another object redzone? is allocated in the region? objX ptrX ptrX ptrX objY Cannot detect!objX objZ Spatial memory error Temporal memory error 6 Motivation P1 • To enhance detectability of redzone- obj1 based memory error detection • P1. Large gap to detect spatial memory errors P1 • P2. Large quarantine zone to detect temporal memory errors obj1 P1 7 Motivation P1 • To enhance detectability of redzone- P2 obj1 based memory error detection • P1. Large gap to detect spatial memory errors P1 • P2. Large quarantine zone to detect temporal memory errors P2 obj2obj1 P1 7 Motivation P1 • To enhance detectability of redzone- P2 obj1 based memory error detection • P1. Large gap to detect spatial memory errors P1 • P2. Large quarantine zone to detect temporal memory errors P2 obj2obj1 Huge physical memory P1 required 7 MEDS overview • Enhances detectability of redzone-based memory error detection • Idea: Fully utilize 64-bit virtual address space to support • P1. Large gap to detect spatial error • P2. Large quarantine zone to detect temporal error • Approach: minimize physical memory use • Page aliasing allocator and page protection • Hierarchical memory error detection 8 Page aliasing (P1) • Maps multiple virtual pages to single physical page Virtual obj1 A memory page obj2 Allocated Redzone Page aliasing obj4 9 Page aliasing (P1) • Maps multiple virtual pages to single physical page Virtual obj1 Physical obj1 obj2 A memory page obj2 obj3 obj4 Allocated Redzone Page aliasing obj4 9 Page aliasing (P1) • Maps multiple virtual pages to single physical page Virtual obj1 Redzone itself does not Physical occupy physical memory obj1 obj2 A memory page obj2 obj3 obj4 Allocated Redzone Page aliasing obj4 9 Page protection (P1) • Redzone only pages are unmapped Virtual obj1 Physical obj1 A memory page obj2 obj3 Unmapped page obj4 obj2 Allocated Redzone Page aliasing 10 Page protection (P1) • Redzone only pages are unmapped Do not occupy shadow memory and physical Virtual memory obj1 Physical obj1 A memory page obj2 obj3 Unmapped page obj4 obj2 Allocated Redzone Page aliasing 10 Page aliasing & Page protection (P2) Virtual obj1 Physical obj1 obj2 A memory page obj3 obj4 obj4 Unmapped page Allocated Redzone Page aliasing 11 Page aliasing & Page protection (P2) Virtual Virtual obj1 Quarantined Physical Physical obj1 obj2 obj2 A memory page obj3 obj3 obj4 obj4 obj4 obj4 Unmapped page Allocated Redzone Page aliasing 11 Page aliasing & Page protection (P2) Virtual Virtual obj1 Quarantined Physical Physical obj1 objX obj2 obj2 A memory page obj3 obj3 obj4 obj4 obj4 obj4 Unmapped page Allocated objX Redzone Page aliasing 11 Page aliasing & Page protection (P2) Virtual Virtual Reuse physical obj1 memory immediately, Quarantined while not reusing Physical Physical virtual addresses obj1 objX obj2 obj2 A memory page obj3 obj3 obj4 obj4 obj4 obj4 Unmapped page Allocated objX Redzone Page aliasing 11 Hierarchical memory error detection • Many different ways to represent redzones Further optimizing physical memory uses ptr 12 Hierarchical memory error detection • Many different ways to represent redzones Further optimizing physical memory uses ptr #1. Shadow memory is invalid 12 Hierarchical memory error detection • Many different ways to represent redzones Further optimizing physical memory uses ptr #1. Shadow memory is invalid #2. Virtual page is unmapped 12 Hierarchical memory error detection • Many different ways to represent redzones Further optimizing physical memory uses ptr #1. Shadow memory is invalid #2. Virtual page is unmapped #3. Shadow memory is unmapped 12 Evaluation • Configuration ASan MEDS Improv. Redzone 8-1024 bytes 4MB 16,384x Quarantine 128MB 80TB 65,536x • ASan cannot use configuration for MEDS (lack of memory) • Compatibility • Performance: 2 times slowdown • Detection (fuzz testing): 68% more detection 13 Compatibility • Unit tests from real-world applications • Test cases in Chrome, Firefox, Nginx • All Passed • Memory error unit tests • ASan unit tests • All Passed • NIST Juliet test suites • All Passed except random access tests ASan: 35% vs. MEDS: 98% 14 Micro-scale performance overhead • TLB misses • 5 times more than ASan (more virtual pages with page aliasing) • Number of system calls • mmap(), munmap(), and mremap() • 32 times more than ASan (page aliasing and page protection) • Memory footprint • 218% more than baseline • 68% more than ASan (much larger redzone and quarantine) 15 End-to-end performance overhead • 108% compared to baseline, 86% to ASan 4 3 2 1 Baseline 0 Chrome Firefox Apache Nginx ASan MEDS 16 End-to-end performance overhead • 108% compared to baseline, 86% to ASan 4 3 41% to baseline 22% to ASan 2 1 Baseline 0 Chrome Firefox Apache Nginx ASan MEDS 16 End-to-end performance overhead • 108% compared to baseline, 86% to ASan Large number of 4 small objects on stack 41% to baseline 3 243% to baseline 22% to ASan 2 211% to ASan 1 Baseline 0 Chrome Firefox Apache Nginx ASan MEDS 16 Detection (fuzz testing) • Run AFL (8 cores, 6 hours) • Despite the performance overhead, explore 68.3% more unique crashes than ASan 4 3.5 3 2.5 2 1.5 1 ASan 0.5 0 17 Detection (fuzz testing) • Run AFL (8 cores, 6 hours) • Despite the performance overhead, explore 68.3% more unique crashes than ASan 4 MEDS finds more unique crashes in 3.5 3 initial phase, but saturated in the end 2.5 2 1.5 1 ASan 0.5 0 17 Detection (fuzz testing) • Number of unique crashes with time spent (metacam) 70 Saturated 60 50 40 30 20 Found crashes Found 10 0 1 2 3 4 5 6 7 8 Time spent (hrs) ASan MEDS 18 How MEDS explores more crashes? • More input sets can be detected • Higher probability to detect int a[10]; • Bugs can be found earlier than ASan a[x] = x; • Fuzzer can focus on the other paths • MEDS can detect the cases that ASan cannot detect struct A { • Always bypass redzone int num[10]; }; • e.g., Miscalculation of structure array size struct A *a = • Size of the structure is larger than redzone malloc(sizeof(struct A)); size ... • Access to certain element cannot be detected. (a+i)->num[8] = i; 19 How MEDS explores more crashes? • More input sets can be detected • Higher probability to detect int a[10]; • Bugs can be found earlier than ASan a[x] = x; • Fuzzer can focus on the other paths • MEDS can detect the cases that ASan cannot detect struct A { • Always bypass redzone int num[10]; }; • e.g., Miscalculation of structure array size struct A *a = • Size of the structure is larger than redzone malloc(sizeof(struct A)); size ... • Access to certain element cannot be detected. (a+i)->num[8] = i; 19 How MEDS explores more crashes? • More input sets can be detected • Higher probability to detect int a[10]; • Bugs can be found earlier than ASan a[x] = x; • Fuzzer can focus on the other paths • MEDS can detect the cases that ASan cannot detect struct A { • Always bypass redzone int num[10]; }; • e.g., Miscalculation of structure array size struct A *a = • Size of the structure is larger than redzone malloc(sizeof(struct A)); size ... • Access to certain element cannot be detected.
Load more

Recommended publications
  • Memory Safety Without Garbage Collection for Embedded Applications
    Memory Safety Without Garbage Collection for Embedded Applications DINAKAR DHURJATI, SUMANT KOWSHIK, VIKRAM ADVE, and CHRIS LATTNER University of Illinois at Urbana-Champaign Traditional approaches to enforcing memory safety of programs rely heavily on run-time checks of memory accesses and on garbage collection, both of which are unattractive for embedded ap- plications. The goal of our work is to develop advanced compiler techniques for enforcing memory safety with minimal run-time overheads. In this paper, we describe a set of compiler techniques that, together with minor semantic restrictions on C programs and no new syntax, ensure memory safety and provide most of the error-detection capabilities of type-safe languages, without using garbage collection, and with no run-time software checks, (on systems with standard hardware support for memory management). The language permits arbitrary pointer-based data structures, explicit deallocation of dynamically allocated memory, and restricted array operations. One of the key results of this paper is a compiler technique that ensures that dereferencing dangling pointers to freed memory does not violate memory safety, without annotations, run-time checks, or garbage collection, and works for arbitrary type-safe C programs. Furthermore, we present a new inter- procedural analysis for static array bounds checking under certain assumptions. For a diverse set of embedded C programs, we show that we are able to ensure memory safety of pointer and dy- namic memory usage in all these programs with no run-time software checks (on systems with standard hardware memory protection), requiring only minor restructuring to conform to simple type restrictions. Static array bounds checking fails for roughly half the programs we study due to complex array references, and these are the only cases where explicit run-time software checks would be needed under our language and system assumptions.
    [Show full text]
  • Memory Leak Or Dangling Pointer
    Modern C++ for Computer Vision and Image Processing Igor Bogoslavskyi Outline Using pointers Pointers are polymorphic Pointer “this” Using const with pointers Stack and Heap Memory leaks and dangling pointers Memory leak Dangling pointer RAII 2 Using pointers in real world Using pointers for classes Pointers can point to objects of custom classes: 1 std::vector<int> vector_int; 2 std::vector<int >* vec_ptr = &vector_int; 3 MyClass obj; 4 MyClass* obj_ptr = &obj; Call object functions from pointer with -> 1 MyClass obj; 2 obj.MyFunc(); 3 MyClass* obj_ptr = &obj; 4 obj_ptr->MyFunc(); obj->Func() (*obj).Func() ↔ 4 Pointers are polymorphic Pointers are just like references, but have additional useful properties: Can be reassigned Can point to ‘‘nothing’’ (nullptr) Can be stored in a vector or an array Use pointers for polymorphism 1 Derived derived; 2 Base* ptr = &derived; Example: for implementing strategy store a pointer to the strategy interface and initialize it with nullptr and check if it is set before calling its methods 5 1 #include <iostream > 2 #include <vector > 3 using std::cout; 4 struct AbstractShape { 5 virtual void Print() const = 0; 6 }; 7 struct Square : public AbstractShape { 8 void Print() const override { cout << "Square\n";} 9 }; 10 struct Triangle : public AbstractShape { 11 void Print() const override { cout << "Triangle\n";} 12 }; 13 int main() { 14 std::vector<AbstractShape*> shapes; 15 Square square; 16 Triangle triangle; 17 shapes.push_back(&square); 18 shapes.push_back(&triangle); 19 for (const auto* shape : shapes) { shape->Print(); } 20 return 0; 21 } 6 this pointer Every object of a class or a struct holds a pointer to itself This pointer is called this Allows the objects to: Return a reference to themselves: return *this; Create copies of themselves within a function Explicitly show that a member belongs to the current object: this->x(); 7 Using const with pointers Pointers can point to a const variable: 1 // Cannot change value , can reassign pointer.
    [Show full text]
  • An Evolutionary Study of Linux Memory Management for Fun and Profit Jian Huang, Moinuddin K
    An Evolutionary Study of Linux Memory Management for Fun and Profit Jian Huang, Moinuddin K. Qureshi, and Karsten Schwan, Georgia Institute of Technology https://www.usenix.org/conference/atc16/technical-sessions/presentation/huang This paper is included in the Proceedings of the 2016 USENIX Annual Technical Conference (USENIX ATC ’16). June 22–24, 2016 • Denver, CO, USA 978-1-931971-30-0 Open access to the Proceedings of the 2016 USENIX Annual Technical Conference (USENIX ATC ’16) is sponsored by USENIX. An Evolutionary Study of inu emory anagement for Fun and rofit Jian Huang, Moinuddin K. ureshi, Karsten Schwan Georgia Institute of Technology Astract the patches committed over the last five years from 2009 to 2015. The study covers 4587 patches across Linux We present a comprehensive and uantitative study on versions from 2.6.32.1 to 4.0-rc4. We manually label the development of the Linux memory manager. The each patch after carefully checking the patch, its descrip- study examines 4587 committed patches over the last tions, and follow-up discussions posted by developers. five years (2009-2015) since Linux version 2.6.32. In- To further understand patch distribution over memory se- sights derived from this study concern the development mantics, we build a tool called MChecker to identify the process of the virtual memory system, including its patch changes to the key functions in mm. MChecker matches distribution and patterns, and techniues for memory op- the patches with the source code to track the hot func- timizations and semantics. Specifically, we find that tions that have been updated intensively.
    [Show full text]
  • Diehard: Probabilistic Memory Safety for Unsafe Languages
    DieHard: Probabilistic Memory Safety for Unsafe Languages Emery D. Berger Benjamin G. Zorn Dept. of Computer Science Microsoft Research University of Massachusetts Amherst One Microsoft Way Amherst, MA 01003 Redmond, WA 98052 [email protected] [email protected] Abstract Invalid frees: Passing illegal addresses to free can corrupt the Applications written in unsafe languages like C and C++ are vul- heap or lead to undefined behavior. nerable to memory errors such as buffer overflows, dangling point- Double frees: Repeated calls to free of objects that have already ers, and reads of uninitialized data. Such errors can lead to program been freed undermine the integrity of freelist-based allocators. crashes, security vulnerabilities, and unpredictable behavior. We present DieHard, a runtime system that tolerates these errors while Tools like Purify [17] and Valgrind [28, 34] allow programmers to probabilistically maintaining soundness. DieHard uses randomiza- pinpoint the exact location of these memory errors (at the cost of a tion and replication to achieve probabilistic memory safety through 2-25X performance penalty), but only reveal those bugs found dur- the illusion of an infinite-sized heap. DieHard’s memory manager ing testing. Deployed programs thus remain vulnerable to crashes randomizes the location of objects in a heap that is at least twice or attack. Conservative garbage collectors can, at the cost of in- as large as required. This algorithm not only prevents heap corrup- creased runtime and additional memory [10, 20], disable calls to tion but also provides a probabilistic guarantee of avoiding memory free and so eliminate three of the above errors (invalid frees, dou- errors.
    [Show full text]
  • Simple, Fast and Safe Manual Memory Management
    Simple, Fast and Safe Manual Memory Management Piyus Kedia Manuel Costa Matthew Aaron Blankstein ∗ Microsoft Research, India Parkinson Kapil Vaswani Princeton University, USA [email protected] Dimitrios Vytiniotis [email protected] Microsoft Research, UK manuelc,mattpark,kapilv,[email protected] Abstract cause the latter are more efficient. As a consequence, many Safe programming languages are readily available, but many applications continue to have exploitable memory safety applications continue to be written in unsafe languages be- bugs. One of the main reasons behind the higher efficiency cause of efficiency. As a consequence, many applications of unsafe languages is that they typically use manual mem- continue to have exploitable memory safety bugs. Since ory management, which has been shown to be more efficient garbage collection is a major source of inefficiency in the than garbage collection [19, 21, 24, 33, 34, 45]. Thus, replac- implementation of safe languages, replacing it with safe ing garbage collection with manual memory management in manual memory management would be an important step safe languages would be an important step towards solv- towards solving this problem. ing this problem. The challenge is how to implement man- Previous approaches to safe manual memory manage- ual memory management efficiently, without compromising ment use programming models based on regions, unique safety. pointers, borrowing of references, and ownership types. We Previous approaches to safe manual memory manage- propose a much simpler programming model that does not ment use programming models based on regions [20, 40], require any of these concepts. Starting from the design of an unique pointers [22, 38], borrowing of references [11, 12, imperative type safe language (like Java or C#), we just add 42], and ownership types [10, 12, 13].
    [Show full text]
  • Efficient High Frequency Checkpointing for Recovery and Debugging Vogt, D
    VU Research Portal Efficient High Frequency Checkpointing for Recovery and Debugging Vogt, D. 2019 document version Publisher's PDF, also known as Version of record Link to publication in VU Research Portal citation for published version (APA) Vogt, D. (2019). Efficient High Frequency Checkpointing for Recovery and Debugging. General rights Copyright and moral rights for the publications made accessible in the public portal are retained by the authors and/or other copyright owners and it is a condition of accessing publications that users recognise and abide by the legal requirements associated with these rights. • Users may download and print one copy of any publication from the public 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 public portal ? Take down policy If you believe that this document breaches copyright please contact us providing details, and we will remove access to the work immediately and investigate your claim. E-mail address: [email protected] Download date: 30. Sep. 2021 Efficient High Frequency Checkpointing for Recovery and Debugging Ph.D. Thesis Dirk Vogt Vrije Universiteit Amsterdam, 2019 This research was funded by the European Research Council under the ERC Advanced Grant 227874. Copyright © 2019 by Dirk Vogt ISBN 978-94-028-1388-3 Printed by Ipskamp Printing BV VRIJE UNIVERSITEIT Efficient High Frequency Checkpointing for Recovery and Debugging ACADEMISCH PROEFSCHRIFT ter verkrijging van de graad Doctor aan de Vrije Universiteit Amsterdam, op gezag van de rector magnificus prof.dr.
    [Show full text]
  • 6.828: Virtual Memory for User Programs
    6.828: Virtual Memory for User Programs Adam Belay <[email protected]> Plan for today • Previously: Discussed using virtual memory tricks to optimize the kernel • This lecture is about virtual memory for user programs: • Concurrent garbage collection • Generational garbage collection • Concurrent checkpointing • Data-compression paging • Persistent stores What primitives do we need? • Trap: handle page-fault traps in usermode • Prot1: decrease the accessibility of a page • ProtN: decrease the accessibility of N pages • Unprot: increase the accessibility of a page • Dirty: returns a list of dirtied pages since previous call • Map2: map the same physical page at two different virtual addresses, at different levels of protection, in the same address space What about UNIX? • Processes manage virtual memory through higher- level abstractions • An address space consists of a non-overlapping list of Virtual Memory Areas (VMAs) and a page table • Each VMA is a contiguous range of virtual addresses that shares the same permissions and is backed by the same object (e.g. a file or anonymous memory) • VMAs help the kernel decide how to handle page faults Unix: mmap() • Maps memory into the address space • Many flags and options • Example: mapping a file mmap(NULL, len, PROT_READ | PROT_WRITE, MAP_PRIVATE, fd, offset); • Example: mapping anonymous memory mmap(NULL, len, PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANONYMOUS, -1, 0); Unix: mprotect() • Changes the permissions of a mapping • PROT_READ, PROT_WRITE, and PROT_EXEC • Example: make mapping read-only mprotect(addr, len, PROT_READ); • Example: make mapping trap on any acCess mprotect(addr, len, PROT_NONE); Unix: munmap() • Removes a mapping • Example: munmap(addr, len); Unix: sigaction() • Configures a signal handler • Example: get signals for memory access violations act.sa_sigaction = handle_sigsegv; act.sa_flags = SA_SIGINFO; sigemptyset(&act.sa_mask); sigaction(SIGSEGV, &act, NULL); Unix: Modern implementations are very complex e.g.
    [Show full text]
  • Optimization Techniques for Memory Virtualization-Based Resource Management
    SSStttooonnnyyy BBBrrrooooookkk UUUnnniiivvveeerrrsssiiitttyyy The official electronic file of this thesis or dissertation is maintained by the University Libraries on behalf of The Graduate School at Stony Brook University. ©©© AAAllllll RRRiiiggghhhtttsss RRReeessseeerrrvvveeeddd bbbyyy AAAuuuttthhhooorrr... Optimization Techniques for Memory Virtualization-based Resource Management A Dissertation Presented by Jui-Hao Chiang to The Graduate School in Partial Fulfillment of the Requirements for the Degree of Doctor of Philosophy in Computer Science Stony Brook University December 2012 Stony Brook University The Graduate School Jui-Hao Chiang We, the dissertation committee for the above candidate for the Doctor of Philosophy degree, hereby recommend acceptance of this dissertation. Tzi-cker Chiueh { Dissertation Advisor Professor, Department of Computer Science Jie Gao { Chairperson of Defense Associate Professor, Department of Computer Science Rob Johnson Assistant Professor, Department of Computer Science Ted Teng Professor, Department of Technology and Society This dissertation is accepted by the Graduate School. Charles Taber Interim Dean of the Graduate School ii Abstract of the Dissertation Optimization Techniques for Memory Virtualization-based Resource Management by Jui-Hao Chiang Doctor of Philosophy in Computer Science Stony Brook University 2012 Memory virtualization abstracts the physical memory resources in a virtualized server in such a way that offers many resource man- agement advantages, such as consolidation, sharing,
    [Show full text]
  • Experience with Safe Manual Memory-Management in Cyclone
    Experience With Safe Manual Memory-Management in Cyclone Michael Hicks Greg Morrisett University of Maryland, College Park Harvard University [email protected] [email protected] Dan Grossman Trevor Jim University of Washington AT&T Labs Research [email protected] [email protected] ABSTRACT bring the “Mohammad of type safety” to the “mountain of existing The goal of the Cyclone project is to investigate type safety for low- C code.” level languages such as C. Our most difficult challenge has been Toward that end, we have been developing Cyclone, a type-safe providing programmers control over memory management while dialect of C [23]. Cyclone uses a combination of programmer- retaining type safety. This paper reports on our experience trying supplied annotations, an advanced type system, a flow analysis, to integrate and effectively use two previously proposed, type-safe and run-time checks to ensure that programs are type safe. When memory management mechanisms: statically-scoped regions and we started the project, we relied entirely on heap allocation and unique pointers. We found that these typing mechanisms can be the Boehm-Demers-Weiser (BDW) conservative garbage collector combined to build alternative memory-management abstractions, (GC) to recycle memory safely. BDW provides convenient inter- such as reference counted objects and arenas with dynamic life- operability with legacy libraries and makes it easy to support poly- times, and thus provide a flexible basis. Our experience—porting morphism without needing run-time type tags. C programs and building new applications for resource-constrained While the BDW collector provides convenience, it does not al- systems—confirms that experts can use these features to improve ways provide the performance or control needed by low-level sys- memory footprint and sometimes to improve throughput when used tems applications.
    [Show full text]
  • Dangling Pointer
    Dangling Pointer Jonathan Afek, 1/8/07, BlackHat USA 1 Table of Contents What is a Dangling Pointer? Code Injection Object Overwriting Demonstration Remediation Summary Q&A 2 What is a Dangling Pointer? Invalid Pointer: Real Life Example Dangling Dangerous Pointer1 Pointer2 Pointer3 Pointer Exploitable Common Application Code: Pointer3 = new Object(); … delete Pointer3; Overwrite Deleted … Object Object NewObject Data the object Object Pointer3->func(); 3 What is a Dangling Pointer? Assembly – Memory Layout – Registers – Assembly code 4 Where are We What is a Dangling Pointer? Code Injection Object Overwriting Demonstration Remediation Summary Q&A 5 Code Injection – The Layout of an Object Class_A: Instance_A memory Class_A VFTable vfunc_A1 Code classVFTABLE PointerClass_A vfunc_A1 address Assembly code {member_of_A vfunc_A2 address int member_of_A;vfunc_A 3 address public : vfunc_A2 Code virtual long vfunc_A1(); { Assembly code ... virtual long vfunc_A2(); MOV EAX,… [ECX] this.vfunc_A3();virtual long vfunc_A3(); ... static void sfunc_A();CALL [EAX + 8] vfunc_A3 Code } void funcA(); … Assembly code }; 6 Code Injection – The Double Reference Exploit Exploit Overview: – Free the Object – Overwrite the Object – Execute a Virtual Function 77 Code Injection – The Double Reference Exploit Object Allocated Object De-allocated Shellcode Overwriting Object Finding a “VFTable” VFunc3 Executed Application Code: ECX – Original Object EAX – “VFTABLE” a->v_func3();a =delete new a;A(); “VFTABLE” “VFTABLE” Pointer Memory Junk MOV EAX,… [ECX] Memory Junk CALL [EAX + 8] Pointer OriginalFreed Space Object … SHELLCODE Memory Junk Memory Junk CALL/JMP ECX 8 Where are We What is a Dangling Pointer? Code Injection Object Overwriting Demonstration Remediation Summary Q&A 9 Object Overriding Allocation Implementation – C-Runtime heap – C-Runtime functions • Malloc • Free • New • Delete • Etc.
    [Show full text]
  • Garbage Collection (1)
    Garbage Collection (1) Advanced Operating Systems Lecture 8 Lecture Outline • Introduction • Reference counting • Garbage collection • Mark-sweep • Mark-compact • Copying collectors • … "2 Introduction • Wide distrust of automatic memory management in real-time, embedded, and systems programming • Perception of high processor and memory overheads, unpredictable poor timing behaviour • But, memory management problems are common in code with manual memory management! • Memory leaks and unpredictable memory allocation performance (calls to malloc() can vary in execution time by several orders of magnitude) • Memory corruption and buffer overflows • Performance of automatic memory management is much better than in the past • Not all problems solved, but there are garbage collectors with predictable timing, suitable for real-time applications • Moore’s law makes the overheads more acceptable !3 Automatic Memory Management • Memory/object allocation and deallocation may be manual or automatic • Automatic allocation/deallocation of variables on the stack is common • In the example code, memory for di is int saveDataForKey(char *key, FILE *outf)! automatically allocated when the function {! executes, and freed when it completes struct DataItem di;! ! • Extremely simple and efficient memory if (findData(&di, key)) {! management for languages like C/C++ saveData(&di, outf);! that have complex value types return 1;! • Useless for Java-like languages, where }! objects are allocated on the heap return 0;! } ! • Memory allocated on the heap is allocated
    [Show full text]
  • ANSWER KEY Roll No
    ESC 101: Fundamentals of Computing End Semester Examination Date: 25 – 04 - 2019 Name ANSWER KEY Roll No. Dept. Section B Instructions: Total 120 Marks 1. This question paper contains a total of 20 printed side of paper. 2. Write your roll number and section on every sheet of this booklet. 3. Write final answers neatly with a blue/black pen in the given boxes. 4. Answers written outside the box will not be graded. Q 1.1 Fill in the blanks. (1 + 1 = 2 marks) a) The time complexity of merge sort for linked list is O(n log n) in big O notation. b) Worst case time complexity of searching in binary search tree is O(log n) False (True/False). Q 1.2 Fill in the blanks to complete the following code. a) Function Description: Given a 2-dimentional m x n array mat having all its rows sorted in ascending order from left to right and all its columns sorted in ascending order from top to bottom, findKey checks whether key exists in the array or not. Returns 1 if key exists and 0 otherwise. You can assume that the 2D array was dynamically created in the main() function from an int** and that is passed to the function. (1 + 1 + 1 + 1 + 1 + 1 = 6 marks) int findKey(int** mat, int m, int n, int key) { int x = 0 ; int y = n - 1 ; While( x<m && y>=0 ) { if(mat[x][y] < key) { ++x ; } else if(mat[x][y] > key) { --y ; } else { return 1; } } return 0 ; } Roll No.
    [Show full text]