A Practical Dynamic Buffer Overflow Detector

By Olatunji Ruwase, Monica S. Lam. Network and Distributed System Security Symposium, 2004

398 citations recorded by the source corpus.

View Paper: https://www.semanticscholar.org/paper/272a1f065adb2fa98b3c4df55787db944028791c

How researchers see this paper

The researchers whose trusted networks rank it highest, strongest advocate first. Every researcher gets a different order.

1. Dawn Song
2. James Newsome
3. Engin Kirda
4. Shuo Chen
5. Nicholas Carlini
6. Benjamin Cox
7. Wei Xu
8. David E. Evans

Citations in the corpus

• Backward-compatible constant-time exception-protected memory (2009, methodology): “[18] by using automatic pool allocation to partition the large table of objects.”
• Securing software by enforcing data-flow integrity (2006, background): “CRED [34] is similar but provides support for some common uses of out-ofbounds pointers in existing C programs.”
• Testing static analysis tools using exploitable buffer overflows from open source code (2004, background): “These examples contain no complex control structures, instances of inter-procedural scope, or di­rect bu.er accesses outside of string functions, and therefore cannot represent complex bu.er access patterns found in In­ternet servers.”
• Dynamic Taint Analysis for Automatic Detection, Analysis, and SignatureGeneration of Exploits on Commodity Software (2005, methodology): “Most of these previous mechanisms require source code or special recompilation of the program, such as StackGuard [15], PointGuard [14], full-bounds check [20, 38], LibsafePlus [5], FormatGuard [13], and CCured [28].”
• SoK: Eternal War in Memory (2013, methodology): “A more generic solution to this problem was later provided by CRED [53].”
• Non-Control-Data Attacks Are Realistic Threats (2005, background): “CRED [53] is a buffer overflow detector that uses the notion of referent objects to add bounds checking to C without restricting safe pointer.”
• Efficient Techniques for Comprehensive Protection from Memory Error Exploits (2005, methodology): “Unfortunately, existing techniques such as backwards-compatible bounds checking [18] and its descendant CRED [28] are associated with high overheads, sometimes exceeding 1000%.”
• Secure program execution via dynamic information flow tracking (2004, background): “Unfortunately, the performance overhead of this perfect protection while preserving code compatibility is prohibitively high; checking all buffers incurs 10- 30x slowdown in the Jones & Kelly scheme [10], and checking only string buffer incurs up to 2.3x slowdown [ 18 ].”
• LAVA: Large-Scale Automated Vulnerability Addition (2016, background): “In the case of buffer overflows in C, this could mean compiling in finegrained bounds checking [16].”
• An efficient and backwards-compatible transformation to ensure memory safety of C programs (2004, methodology): “Another security-targeted approach is CRED, developed by Ruwase and Lam [31].”
• Aegis: A Single-Chip Secure Processor (2007, unknown): “3x slowdown [114].”
• N-Variant Systems: A Secretless Framework for Security through Diversity (2006, background): “Buffer overflows have been widely studied and numerous defenses have been developed including static analysis to detect and eliminate the vulnerabilities [66, 67, 39, 23], program transformation and dynamic detection techniques [19, 5, 30, 45, 49, 57] and hardware modifications [38, 40, 41, 64].”
• Preventing Memory Error Exploits with WIT (2008, methodology): “CRED [ 37 ] is similar but provides support for some common uses of out-of-boundspointers in existing C programs.”
• SGXBOUNDS: Memory Safety for Shielded Execution (2017, background): “The only exceptions are Software Fault Isolation (SFI) [39, 79], Data Space Randomization (DSR) [24, 28] and memory-safety techniques [17, 20, 35, 56, 58, 59, 67, 82].”