Stitching the Gadgets: On the Ineffectiveness of Coarse-Grained Control-Flow Integrity Protection
By Lucas Davi, Ahmad-Reza Sadeghi, Daniel Lehmann, Fabian Monrose. USENIX Security Symposium, 2014
366 citations recorded by the source corpus.
View Paper: https://www.semanticscholar.org/paper/82b3346080783031ddaf73e6df73b5302ca19248
How researchers see this paper
The researchers whose trusted networks rank it highest, strongest advocate first. Every researcher gets a different order.
- Nicholas Carlini
- Felix Schuster
- Lucas Davi
- Ahmad-Reza Sadeghi
- David A. Wagner
- Florian Tramèr
- Tigist Abera
- Thomas Tendyck
Citations in the corpus
- Counterfeit Object-oriented Programming: On the Difficulty of Preventing Code Reuse Attacks in C++ Applications (2015, methodology): “For example, the widely deployed address space layout randomization (ASLR) technique ensures that the stack, the heap, and executable modules of a program are mapped at secret, pseudo-randomly chosen memory locations.”
- Control-Flow Bending: On the Effectiveness of Control-Flow Integrity (2015, background): “This notion of fully-precise static CFI allows us to transcend the recent arms race caused by defenders proposing forms of CFI [9,28] and then attackers defeating them [5, 14, 16].”
- Enforcing Forward-Edge Control-Flow Integrity in GCC & LLVM (2014, methodology): “Even the most recent CFI implementation, SAFEDISPATCH [19], must sacrifice software-engineering practicality and use profile-driven, whole-program optimization to achieve overheads comparable to ours (roughly 2% for all three of their Chromium benchmarks).”
- Control-Flow Integrity (2017, methodology): “A first set of attacks against CFI implementations targeted coarse-grained CFI that only had 1-3 equivalence classes [8, 19, 26].”
- The Cybersecurity Landscape in Industrial Control Systems (2016, unknown): “[98] L.”
- C-FLAT: Control-Flow Attestation for Embedded Systems Software (2016, methodology): “Depending on the desired granularity, the nodes can be (1) entire functions, (2) basic blocks (BBLs) ending in an indirect branch, or (3) BBLs ending in any branch instruction, e.g., direct or indirect jump, call and return.”