The Experts below are selected from a list of 183 Experts worldwide ranked by ideXlab platform
Benjamin G. Zorn - One of the best experts on this subject based on the ideXlab platform.
-
DieHard: Efficient Probabilistic Memory Safety
2008Co-Authors: Emery D. Berger, Benjamin G. ZornAbstract:Applications written in unsafe languages like C and C++ are vulnerable to memory errors such as buffer overflows, dangling pointers, and reads of uninitialized data. Such errors can lead to program crashes, security vulnerabilities, and unpredictable behavior. We present DieHard, a randomized runtime system that tolerates these errors while probabilistically maintaining soundness. DieHard uses randomization to achieve probabilistic memory safety by approximating an infinite-sized Heap. DieHard’s memory manager randomizes the location of objects in a Heap that dynamically adapts to be a constant factor larger than required. In exchange for this increased space consumption and a modest degradation in performance (geometric mean 6%), DieHard both prevents Heap Corruption and provides probabilistic guarantees of avoiding memory errors like dangling pointers and Heap buffer overflows. For additional safety, DieHard can operate in a replicated mode where multiple replicas of the same application are run simultaneously. By initializing each replica with a different random seed and requiring agreement on output, this replicated version of DieHard increases the likelihood of correct execution because errors are unlikely to have the same effect across all replicas. We present analytical and experimental results that show DieHard’s resilience to a wide range of memory errors, and report on a broad deployment of DieHard to the general public
-
PLDI - DieHard: probabilistic memory safety for unsafe languages
Proceedings of the 2006 ACM SIGPLAN conference on Programming language design and implementation - PLDI '06, 2006Co-Authors: Emery D. Berger, Benjamin G. ZornAbstract:Applications written in unsafe languages like C and C++ are vulnerable to memory errors such as buffer overflows, dangling pointers, and reads of uninitialized data. Such errors can lead to program crashes, security vulnerabilities, and unpredictable behavior. We present DieHard, a runtime system that tolerates these errors while probabilistically maintaining soundness. DieHard uses randomization and replication to achieve probabilistic memory safety by approximating an infinite-sized Heap. DieHard's memory manager randomizes the location of objects in a Heap that is at least twice as large as required. This algorithm prevents Heap Corruption and provides a probabilistic guarantee of avoiding memory errors. For additional safety, DieHard can operate in a replicated mode where multiple replicas of the same application are run simultaneously. By initializing each replica with a different random seed and requiring agreement on output, the replicated version of Die-Hard increases the likelihood of correct execution because errors are unlikely to have the same effect across all replicas. We present analytical and experimental results that show DieHard's resilience to a wide range of memory errors, including a Heap-based buffer overflow in an actual application.
Emery D. Berger - One of the best experts on this subject based on the ideXlab platform.
-
DieHard: Efficient Probabilistic Memory Safety
2008Co-Authors: Emery D. Berger, Benjamin G. ZornAbstract:Applications written in unsafe languages like C and C++ are vulnerable to memory errors such as buffer overflows, dangling pointers, and reads of uninitialized data. Such errors can lead to program crashes, security vulnerabilities, and unpredictable behavior. We present DieHard, a randomized runtime system that tolerates these errors while probabilistically maintaining soundness. DieHard uses randomization to achieve probabilistic memory safety by approximating an infinite-sized Heap. DieHard’s memory manager randomizes the location of objects in a Heap that dynamically adapts to be a constant factor larger than required. In exchange for this increased space consumption and a modest degradation in performance (geometric mean 6%), DieHard both prevents Heap Corruption and provides probabilistic guarantees of avoiding memory errors like dangling pointers and Heap buffer overflows. For additional safety, DieHard can operate in a replicated mode where multiple replicas of the same application are run simultaneously. By initializing each replica with a different random seed and requiring agreement on output, this replicated version of DieHard increases the likelihood of correct execution because errors are unlikely to have the same effect across all replicas. We present analytical and experimental results that show DieHard’s resilience to a wide range of memory errors, and report on a broad deployment of DieHard to the general public
-
PLDI - DieHard: probabilistic memory safety for unsafe languages
Proceedings of the 2006 ACM SIGPLAN conference on Programming language design and implementation - PLDI '06, 2006Co-Authors: Emery D. Berger, Benjamin G. ZornAbstract:Applications written in unsafe languages like C and C++ are vulnerable to memory errors such as buffer overflows, dangling pointers, and reads of uninitialized data. Such errors can lead to program crashes, security vulnerabilities, and unpredictable behavior. We present DieHard, a runtime system that tolerates these errors while probabilistically maintaining soundness. DieHard uses randomization and replication to achieve probabilistic memory safety by approximating an infinite-sized Heap. DieHard's memory manager randomizes the location of objects in a Heap that is at least twice as large as required. This algorithm prevents Heap Corruption and provides a probabilistic guarantee of avoiding memory errors. For additional safety, DieHard can operate in a replicated mode where multiple replicas of the same application are run simultaneously. By initializing each replica with a different random seed and requiring agreement on output, the replicated version of Die-Hard increases the likelihood of correct execution because errors are unlikely to have the same effect across all replicas. We present analytical and experimental results that show DieHard's resilience to a wide range of memory errors, including a Heap-based buffer overflow in an actual application.
-
Diehard: Probabilistic memory safety for unsafe languages
ACM Press, 2006Co-Authors: Emery D. BergerAbstract:Applications written in unsafe languages like C and C++ are vulnerable to memory errors such as buffer overflows, dangling pointers, and reads of uninitialized data. Such errors can lead to program crashes, security vulnerabilities, and unpredictable behavior. We present DieHard, a runtime system that tolerates these errors while probabilistically maintaining soundness. DieHard uses randomization and replication to achieve probabilistic memory safety by approximating an infinite-sized Heap. DieHard’s memory manager randomizes the location of objects in a Heap that is at least twice as large as required. This algorithm prevents Heap Corruption and provides a probabilistic guarantee of avoiding memory errors. For additional safety, DieHard can operate in a replicated mode where multiple replicas of the same application are run simultaneously. By initializing each replica with a different random seed and requiring agreement on output, the replicated version of Die-Hard increases the likelihood of correct execution because errors are unlikely to have the same effect across all replicas. We present analytical and experimental results that show DieHard’s resilience to a wide range of memory errors, including a Heap-based buffer overflow in an actual application
-
Diehard: Probabilistic memory safety for unsafe languages
ACM Press, 2006Co-Authors: Emery D. BergerAbstract:Applications written in unsafe languages like C and C++ are vulnerable to memory errors such as buffer overflows, dangling pointers, and reads of uninitialized data. Such errors can lead to program crashes, security vulnerabilities, and unpredictable behavior. We present DieHard, a runtime system that tolerates these errors while probabilistically maintaining soundness. DieHard uses randomization and replication to achieve probabilistic memory safety through the illusion of an infinite-sized Heap. DieHard’s memory manager randomizes the location of objects in a Heap that is at least twice as large as required. This algorithm not only prevents Heap Corruption but also provides a probabilistic guarantee of avoiding memory errors. For additional safety, DieHard can operate in a replicated mode where multiple replicas of the same application are run simultaneously. By initializing each replica with a different random seed and requiring agreement on output, the replicated version of DieHard increases the likelihood of correct execution because errors are unlikely to have the same effect across all replicas. We present analytical and experimental results that show DieHard’s resilience to a wide range of memory errors, including a Heap-based buffer overflow in an actual application. 1
Ravishankar K. Iyer - One of the best experts on this subject based on the ideXlab platform.
-
SEC - Formal Reasoning of Various Categories of Widely Exploited Security Vulnerabilities Using Pointer Taintedness Semantics
Security and Protection in Information Processing Systems, 2004Co-Authors: Shuo Chen, Karthik Pattabiraman, Zbigniew Kalbarczyk, Ravishankar K. IyerAbstract:This paper is motivated by a low level analysis of various categories of severe security vulnerabilities, which indicates that a common characteristic of many classes of vulnerabilities is pointer taintedness. A pointer is said to be tainted if a user input can directly or indirectly be used as a pointer value. In order to reason about pointer taintedness, a memory model is needed. The main contribution of this paper is the formal definition of a memory model using equational logic, which is used to reason about pointer taintedness. The reasoning is applied to several library functions to extract security preconditions, which must be satisfied to eliminate the possibility of pointer taintedness. The results show that pointer taintedness analysis can expose different classes of security vulnerabilities, such as format string, Heap Corruption and buffer overflow vulnerabilities, leading us to believe that pointer taintedness provides a unifying perspective for reasoning about security vulnerabilities.
-
Formal Reasoning of Various Categories of Widely Exploited Security Vulnerabilities Using Pointer Taintedness Semantics
2004Co-Authors: Shuo Chen, Karthik Pattabiraman, Zbigniew Kalbarczyk, Ravishankar K. IyerAbstract:Abstract: This paper is motivated by a low level analysis of various categories of severe security vulnerabilities, which indicates that a common characteristic of many classes of vulnerabilities is pointer taintedness. A pointer is said to be tainted if a user input can directly or indirectly be used as a pointer value. In order to reason about pointer taintedness, a memory model is needed. The main contribution of this paper is the formal definition of a memory model using equational logic, which is used to reason about pointer taintedness. The reasoning is applied to several library functions to extract security preconditions, which must be satisfied to eliminate the possibility of pointer taintedness. The results show that pointer taintedness analysis can expose different classes of security vulnerabilities, such as format string, Heap Corruption and buffer overflow vulnerabilities, leading us to believe that pointer taintedness provides a unifying perspective for reasoning about security vulnerabilities
Shuo Chen - One of the best experts on this subject based on the ideXlab platform.
-
SEC - Formal Reasoning of Various Categories of Widely Exploited Security Vulnerabilities Using Pointer Taintedness Semantics
Security and Protection in Information Processing Systems, 2004Co-Authors: Shuo Chen, Karthik Pattabiraman, Zbigniew Kalbarczyk, Ravishankar K. IyerAbstract:This paper is motivated by a low level analysis of various categories of severe security vulnerabilities, which indicates that a common characteristic of many classes of vulnerabilities is pointer taintedness. A pointer is said to be tainted if a user input can directly or indirectly be used as a pointer value. In order to reason about pointer taintedness, a memory model is needed. The main contribution of this paper is the formal definition of a memory model using equational logic, which is used to reason about pointer taintedness. The reasoning is applied to several library functions to extract security preconditions, which must be satisfied to eliminate the possibility of pointer taintedness. The results show that pointer taintedness analysis can expose different classes of security vulnerabilities, such as format string, Heap Corruption and buffer overflow vulnerabilities, leading us to believe that pointer taintedness provides a unifying perspective for reasoning about security vulnerabilities.
-
Formal Reasoning of Various Categories of Widely Exploited Security Vulnerabilities Using Pointer Taintedness Semantics
2004Co-Authors: Shuo Chen, Karthik Pattabiraman, Zbigniew Kalbarczyk, Ravishankar K. IyerAbstract:Abstract: This paper is motivated by a low level analysis of various categories of severe security vulnerabilities, which indicates that a common characteristic of many classes of vulnerabilities is pointer taintedness. A pointer is said to be tainted if a user input can directly or indirectly be used as a pointer value. In order to reason about pointer taintedness, a memory model is needed. The main contribution of this paper is the formal definition of a memory model using equational logic, which is used to reason about pointer taintedness. The reasoning is applied to several library functions to extract security preconditions, which must be satisfied to eliminate the possibility of pointer taintedness. The results show that pointer taintedness analysis can expose different classes of security vulnerabilities, such as format string, Heap Corruption and buffer overflow vulnerabilities, leading us to believe that pointer taintedness provides a unifying perspective for reasoning about security vulnerabilities
James C. Foster - One of the best experts on this subject based on the ideXlab platform.
-
buffer overflow attacks
2005Co-Authors: James C. Foster, Vitaly Osipov, Nish BhallaAbstract:Will the Code You Write Today Headline Tomorrow's BugTraq Mail List? Includes Numbered-by-Line Exploit Code Examples That Illustrate the Differences Between Stack Overflows, Heap Corruption, and Format String Bugs Provides Case Studies for Most Major Platforms and Environments, Including Windows, FreeBSD, FrontPage, and Linux Avoid Worm or Custom Exploits by Analyzing Your Source Code to Detect Buffer Overflow Vulnerabilities Forensic investigations of notorious Internet attacks, such as the SQL Slammer and Blaster Worms, reveal buffer overflows to be the sophisticated hacker's "vulnerability of choice". These worms crippled the Internet and cost billions of dollars to clean up. Now, even more powerful and insidious threats have appeared in the form of "custom exploits". These one-time only exploits are custom crafted to attack your enterprise, making them even more difficult to detect and defend. No catchy names, no media coverage; just your own personal disaster. James C. Foster's Buffer Overflow Attacks clearly demonstrates that the only way to defend against the endless variety of buffer overflow attacks is to implement a comprehensive design, coding and test plan for all of your applications. From Dave Aitel's Foreword through the last appendix, this is the only book dedicated exclusively to detecting, exploiting, and preventing buffer overflow attacks. CONTENTS OF THIS BOOK INCLUDE Buffer Overflows: The Essentials Understanding Shellcode Writing Shellcode Win32 Assembly Case Study: FreeBSD NN Exploit Code Case Study: xlockmore User Supplied Format String Vulnerability (CVE-2000-0763) Case Study: FrontPage Denial of Service Utilizing WinSock Stack Overflows Heap Corruption Format String Attacks Windows Buffer Overflows Case Study: cURL buffer overflow on Linux Case Study: OpenSSL SSLv2 Malformed Client Key Remote Buffer Overflow Vulnerability (CAN-2002-0656) Case Study: X11R6 4.2 XLOCALEDIR Overflow Case Study: Microsoft MDAC Denial of Service Case Study: Local UUX Buffer Overflow on HPUX Finding Buffer Overflows in Source Case Study: InlineEgg I Case Study: InlineEgg II Case Study: [email protected] Exploit Code Case Study: Microsoft CodeBlue Exploit Code The Complete Data Conversion Table Useful Syscalls Additional Exploit References
-
Chapter 6 – Heap Corruption
Buffer Overflow Attacks, 2005Co-Authors: James C. Foster, Vitaly Osipov, Nish Bhalla, Niels Heinen, Dave AitelAbstract:Publisher Summary Heap Corruption bugs are just another face of buffer overflows. The simplest case of exploitation occurs when two allocated buffers are adjacent in memory and an attacker can supply some input that will overflow the first of these buffers. Afterward, the contents of the second buffer will be overwritten and when the program tries to use the data in the second buffer, it will use the one provided by an attacker. This is also true for statically allocated variables. More advanced methods of exploitation exist for the two most common implementations of malloc Heap memory manager. Both lead to overwriting of an arbitrary location in memory with the attacker-supplied data. There are two ways of exploitation based on different steps of freeing the memory chunk: forward consolidation and backward consolidation. They require that an attacker create a fake memory chunk somewhere inside the buffer being overflowed. After that, this fake chunk is processed by free() and an overwrite occurs. Sometimes it is enough that an overflow overwrites only five (or even one) bytes of the second buffer.
-
chapter 6 Heap Corruption
Buffer Overflow Attacks#R##N#Detect Exploit Prevent, 2005Co-Authors: James C. Foster, Vitaly Osipov, Nish Bhalla, Niels Heinen, Dave AitelAbstract:Publisher Summary Heap Corruption bugs are just another face of buffer overflows. The simplest case of exploitation occurs when two allocated buffers are adjacent in memory and an attacker can supply some input that will overflow the first of these buffers. Afterward, the contents of the second buffer will be overwritten and when the program tries to use the data in the second buffer, it will use the one provided by an attacker. This is also true for statically allocated variables. More advanced methods of exploitation exist for the two most common implementations of malloc Heap memory manager. Both lead to overwriting of an arbitrary location in memory with the attacker-supplied data. There are two ways of exploitation based on different steps of freeing the memory chunk: forward consolidation and backward consolidation. They require that an attacker create a fake memory chunk somewhere inside the buffer being overflowed. After that, this fake chunk is processed by free() and an overwrite occurs. Sometimes it is enough that an overflow overwrites only five (or even one) bytes of the second buffer.
-
Chapter 7 – Writing Exploits II
Writing Security Tools and Exploits, 2005Co-Authors: James C. Foster, Vincent LiuAbstract:Publisher Summary This chapter focus on exploiting overflow-related vulnerabilities, including stack overflows, Heap Corruption, and integer bugs. It covers the functions and system calls that will be used and implemented in programs. A solid understanding of debugging, system architecture, and memory layout is required to successfully exploit a buffer overflow problem. Shellcode design coupled with limitations of the vulnerability can hinder or enhance the usefulness of an exploit. If other data on the stack or Heap shrink the length of space available for shellcode, optimized shellcode for the attacker s specific task is required. Knowing the way to read, modify, and write custom shellcode is a must for practical vulnerability exploitation. Stack overflows and Heap Corruption, originally two of the biggest issues within software development in terms of potential risk and exposure, are being replaced by the relatively newer and more difficult to identify integer bugs. Integer bugs span a wide range of vulnerabilities, including type mismatching and multiplication errors.
-
Writing Exploits II
Writing Security Tools and Exploits, 2005Co-Authors: James C. Foster, Vincent LiuAbstract:This chapter focus on exploiting overflow-related vulnerabilities, including stack overflows, Heap Corruption, and integer bugs. It covers the functions and system calls that will be used and implemented in programs. A solid understanding of debugging, system architecture, and memory layout is required to successfully exploit a buffer overflow problem. Shellcode design coupled with limitations of the vulnerability can hinder or enhance the usefulness of an exploit. If other data on the stack or Heap shrink the length of space available for shellcode, optimized shellcode for the attacker s specific task is required. Knowing the way to read, modify, and write custom shellcode is a must for practical vulnerability exploitation. Stack overflows and Heap Corruption, originally two of the biggest issues within software development in terms of potential risk and exposure, are being replaced by the relatively newer and more difficult to identify integer bugs. Integer bugs span a wide range of vulnerabilities, including type mismatching and multiplication errors.
