Efficient Techniques for Comprehensive Protection from Memory Error Exploits

By Sandeep Bhatkar, Daniel C. DuVarney. USENIX Security Symposium, 2005

360 citations recorded by the source corpus.

View Paper: https://www.semanticscholar.org/paper/fef591b7564b7957ea0a0563b55bbbca89f502d4

How researchers see this paper

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

Citations in the corpus

Just-In-Time Code Reuse: On the Effectiveness of Fine-Grained Address Space Layout Randomization (2013, methodology): “Fine-grained randomization ([7, 23, 29, 45, 62]) has been recently introduced as a method of tackling the deficiencies of ASLR (e.”
Preventing Memory Error Exploits with WIT (2008, background): “that we know [11] has an overhead of 17% on gzip and WIT has an overhead of 7%.”
Binary stirring: self-randomizing instruction addresses of legacy x86 binary code (2012, methodology): “As a result, address space layout randomization (ASLR) [10, 45] was invented to frustrate attacks that bypass W ⊕ X. ASLR has signiﬁcantly raised the bar for standard library-based shell code because attackers cannot predict the addresses of dangerous instructions to which they wish to transfer…”
SGX-Shield: Enabling Address Space Layout Randomization for SGX Programs (2017, methodology): “many fine-grained ASLR techniques [13, 23, 24, 32, 45, 59] claim that randomizing the code in various fine-grained units (e.”
The Cybersecurity Landscape in Industrial Control Systems (2016, unknown): “[119] S.”
Jump-oriented programming: a new class of code-reuse attack (2011, unknown): “In particular, address-space layout randomization (ASLR) [2, 7, 8] randomizes the memory layout of a running program, making it difficult to determine the addresses in libc and other legitimate code on which”
Smashing the Gadgets: Hindering Return-Oriented Programming Using In-place Code Randomization (2012, background): “Attackers are able to a priori pick the right code pieces because parts of the code image of the vulnerable application remain static across different installations.”
DieHard: probabilistic memory safety for unsafe languages (2006, background): “Security vulnerabilities: Previous efforts to reduce vulnerability to heap-based security attacks randomize the base address of the heap [7, 29] or randomly pad allocation requests [8].”
SoK: Automated Software Diversity (2014, background): “Several approaches defer diversification by making programs self-randomizing [6], [8], [29], [64], [27].”
ILR: Where'd My Gadgets Go? (2012, methodology): “use source-to-source transformation techniques to produce self-randomizing programs (SRP) to combat memory error exploits [42].”
Code-pointer integrity (2014, methodology): “Our safe stack layout is similar to double stack approaches in ASR [6] and XFI [18], which maintain a separate stack for arrays and variables whose addresses are taken.”