The Taming of the Stack: Isolating Stack Data from Memory Errors
Jack HuangProceedings 2022 Network and Distributed System Security Symposium
Sign up for access to the world's latest research
checkGet notified about relevant papers
checkSave papers to use in your research
checkJoin the discussion with peers
checkTrack your impact
Abstract
Despite vast research on defenses to protect stack objects from the exploitation of memory errors, much stack data remains at risk. Historically, stack defenses focus on the protection of code pointers, such as return addresses, but emerging techniques to exploit memory errors motivate the need for practical solutions to protect stack data objects as well. However, recent approaches provide an incomplete view of security by not accounting for memory errors comprehensively and by limiting the set of objects that can be protected unnecessarily. In this paper, we present the DATAGUARD system that identifies which stack objects are safe statically from spatial, type, and temporal memory errors to protect those objects efficiently. DATAGUARD improves security through a more comprehensive and accurate safety analysis that proves a larger number of stack objects are safe from memory errors, while ensuring that no unsafe stack objects are mistakenly classified as safe. DATAGUARD's analysis of server programs and the SPEC CPU2006 benchmark suite shows that DATAGUARD improves security by: (1) ensuring that no memory safety violations are possible for any stack objects classified as safe, removing 6.3% of the stack objects previously classified safe by the Safe Stack method, and (2) blocking exploit of all 118 stack vulnerabilities in the CGC Binaries. DATAGUARD extends the scope of stack protection by validating as safe over 70% of the stack objects classified as unsafe by the Safe Stack method, leading to an average of 91.45% of all stack objects that can only be referenced safely. By identifying more functions with only safe stack objects, DATAGUARD reduces the overhead of using Clang's Safe Stack defense for protection of the SPEC CPU2006 benchmarks from 11.3% to 4.3%. Thus, DATAGUARD shows that a comprehensive and accurate analysis can both increase the scope of stack data protection and reduce overheads.
Related papers
StackGuard: Simple Stack Smash Protection for GCC
2003
Since 1998, StackGuard patches to GCC have been used to protect entire distributions from stack smashing buffer overflows. Performance overhead and software compatibility issues have been minimal. In its history, the parts of GCC that StackGuard has operated in have twice changed enough to require complete overhauls of the StackGuard patch. Since StackGuard is a mature technology, even seeing re-implementations in other compilers, we propose that GCC adopt StackGuard as a standard feature. This paper describes our recent work to bring StackGuard fully up to date with current GCC, introduce architecture independence, and extend the protection of stack data structures, while keeping the StackGuard patch as small, simple, and modular as possible.
Protecting Systems from Stack Smashing Attacks with StackGuard
1999
The StackGuard compiler provides robust automatic protection against the all-too-common problem of stack smashing vulnerabilities. However, this protection is only provided for programs and libraries that are re-compiled with StackGuard. Thus protecting an entire system requires that all potentially vulnerable programs be re-compiled to assure that an attacker cannot exploit a stack smashing vulnerability to gain privilege on the system. This paper describes securing a Linux distribution against stack smashing attacks by re-compiling all of the C software from source code using the StackGuard compiler. We present our experience re-compiling 526 packages from source code, and our experience deploying and using the resultant system.
StackOFFence: a technique for defending against buffer overflow attacks
2005
Software coding practices, in the interest of efficiency, often ignore to enforce strict bound checking on buffers, arrays and pointers. This results in software code that is more vulnerable to security intrusions exploiting buffer overflow vulnerabilities. Unfortunately, such attacks form the most common type of security threats to the computer and information systems, making it imperative to find efficient solutions for the buffer overflow vulnerabilities. Typically, an attacker is able to affect a successful intrusion by causing buffer overflow in the stack frame of a function call, thereby causing the valid return address to get overwritten by a malicious value. This allows the attacker to redirect the return from a function call to a malicious piece of code introduced by the attacker. Depending on the nature of the malicious code, the attacker is able to compromise availability, integrity, or confidentiality of a system. Researchers have suggested transforming the return address or even using an entirely separate stack for managing the return addresses. This paper describes a simple technique that ensures the integrity of the return address by pushing on the stack two copies of the return address, a transformed (or encrypted) return address value along with the original one. Before popping the return address, two return address values are compared to detect any malicious activity, thus preventing the exploitation of the stack based buffer overflow vulnerabilities. The proposed modification may be implemented at the CPU architecture level or by simple modification to the compiler's prologue and epilogue code.
StackGuard: Automatic Adaptive Detection and Prevention of Buffer-Overflow Attacks
1998
This paper presents a systematic solution to the persistent problem of buffer overflow attacks. Buffer overflow attacks gained notoriety in 1988 as part of the Morris Worm incident on the Internet. While it is fairly simple to fix individual buffer overflow vulnerabilities, buffer overflow attacks continue to this day. Hundreds of attacks have been discovered, and while most of the obvious vulnerabilities have now been patched, more sophisticated buffer overflow attacks continue to emerge.
There is Safety in Numbers: Preventing Control-Flow Hijacking by Duplication
Abstract. Despite the large number of proposed countermeasures against control-flow hijacking attacks, these attacks still pose a great threat for today's applications. The problem with existing solutions is that they either provide incomplete probabilistic protection (eg, stack canaries) or impose a high runtime overhead (eg, bounds checking).
Let Me Unwind That For You: Exceptions to Backward-Edge Protection
Proceedings 2023 Network and Distributed System Security Symposium, 2023
Backward-edge control-flow hijacking via stack buffer overflow is the holy grail of software exploitation. The ability to directly control critical stack data and the hijacked target makes this exploitation strategy particularly appealing for attackers. As a result, the community has deployed strong backward-edge protections such as shadow stacks or stack canaries, forcing attackers to resort to less ideal e.g., heap-based exploitation strategies. However, such mitigations commonly rely on one key assumption, namely an attacker relying on return address corruption to directly hijack control flow upon function return. In this paper, we present exceptions to this assumption and show attacks based on backward-edge control-flow hijacking without the direct hijacking are possible. Specifically, we demonstrate that stack corruption can cause exception handling to act as a confused deputy and mount backward-edge controlflow hijacking attacks on the attacker's behalf. This strategy provides overlooked opportunities to divert execution to attackercontrolled catch handlers (a paradigm we term Catch Handler Oriented Programming or CHOP) and craft powerful primitives such as arbitrary code execution or arbitrary memory writes. We find CHOP-style attacks to work across multiple platforms (Linux, Windows, macOS, Android and iOS). To analyze the uncovered attack surface, we survey popular open-source packages and study the applicability of the proposed exploitation techniques. Our analysis shows that suitable exception handling targets are ubiquitous in C++ programs and exploitable exception handlers are common. We conclude by presenting three end-toend exploits on real-world software and proposing changes to deployed mitigations to address CHOP.
There's a Hole in the Bottom of the C: On the Effectiveness of Allocation Protection
2018 IEEE Cybersecurity Development (SecDev), 2018
Memory corruption attacks have been a major vector of compromised computer systems for decades. Memory safety techniques proposed in the literature provide spatial and temporal safety properties to prevent such attacks. Since enforcing full memory safety on legacy languages such as C/C++ often incurs large runtime overhead, recent techniques have created a trade-off between the granularity of enforcement and overhead. By enforcing safety properties at the granularity of allocations instead of objects, these technique incur only a fraction of the overhead. Of particular note, are the recent software-based, socalled low-fat schemes, that encode a pointer's bound information in the pointer value itself, thus avoiding a separate metadata store, and additional lookup overhead. In this paper, we show that trading granularity with overhead is insecure. Specifically, we illustrate a new type of attack, which we call Pointer Stretching, that can bypass the recently proposed low-fat schemes using intraobject spatial corruption. Because of the limitations imposed by the low-fat schemes we devise some tricks that allows us to chain ROP gadgets together before a successful stack pivot. We illustrate a real-world exploit against Nginx that successfully hijacks control even when both stack and heap are protected with the software-based low-fat schemes. Furthermore, we show that the vulnerability is inherent in the design of such techniques, and not easily fixable without significant additional implementation and overhead. In addition, we develop an analysis tool to find such vulnerabilities and analyze many popular applications and servers. We find that the exploitable conditions are abundantly found in real-world code bases. Our findings strongly suggest that effective memory defenses must operate at the granularity of objects (and sub-objects) for them to provide meaningful protection against memory corruption attacks.
Implicit Buffer Overflow Protection Using Memory Segregation
2011 Sixth International Conference on Availability, Reliability and Security, 2011
Computing systems continue to be plagued by ma licious corruption of instructions and data. Buffer overflows, in particular, are often employed to disrupt the control flow of vulnerable processes. Existing methods of protection against these attacks operate by detecting corruption after it has taken place or by ensuring that if corruption has taken place, it cannot be used to hijack a process' control flow. These methods thus still allow the corruption of control data to occur but rather than being subverted, the process may terminate or take some other defined error. Few methods have attempted to prevent the corruption of control data, and those that have only focused on preventing the corruption of the return address. We propose the use of multiple memory segments to support multiple stacks, heaps, .bss, and .data sections per process with the goal of segregating control and non-control data. By segregating these different forms of data, we can prevent the corruption of control data by overflow and address manipulation of memory allocated for non-control data. We show that the creation of these additional data segments per process can be implemented through modifications to the compiler.
SLAyer: Memory Safety for Systems-Level Code
Lecture Notes in Computer Science, 2011
SLAyer is a program analysis tool designed to automatically prove memory safety of industrial systems code. In this paper we describe SLAyer's implementation, and its application to Windows device drivers. This paper accompanies the first release of SLAyer.
Related topics
Related papers
ValueGuard: Protection of native applications against data-only buffer overflows
Code injection attacks that target the control-data of an application have been prevalent amongst exploit writers for over 20 years. Today however, these attacks are getting increasingly harder for attackers to successfully exploit due to numerous countermeasures that are deployed by modern operating systems. We believe that this fact will drive exploit writers away from classic control-data attacks and towards data-only attacks. In data-only attacks, the attacker changes key data structures that are used by the program's logic and thus forces the control flow into existing parts of the program that would be otherwise unreachable, e.g. overflowing into a boolean variable that states whether the current user is an administrator or not and setting it to ``true'' thereby gaining access to the administrative functions of the program. In this paper we present ValueGuard, a canary-based defence mechanism to protect applications against data-only buffer overflow attacks. ValueGuard inserts canary values in front of all variables and verifies their integrity whenever these variables are used. In this way, if a buffer overflow has occurred that changed the contents of a variable, ValueGuard will detect it since the variable's canary will have also been changed. The countermeasure itself can be used either as a testing tool for applications before their final deployment or it can be applied selectively to legacy or high-risk parts of programs that we want to protect at run-time, without incurring extra time-penalties to the rest of the applications.
Instruction-Level Countermeasures Against Stack-Based Buffer Overflow Attacks
Proceedings of the …, 2009
PointGuardTM: Protecting Pointers From Buffer Overflow Vulnerabilities
2003
Despite numerous security technologies crafted to resist buffer overflow vulnerabilities, buffer overflows continue to be the dominant form of software security vulnerability. This is because most buffer overflow defenses provide only partial coverage, and the attacks have adapted to exploit problems that are not well-defended, such as heap overflows. This paper presents PointGuard, a compiler technique to defend against most kinds of buffer overflows by encrypting pointers when stored in memory, and decrypting them only when loaded into CPU registers. We describe the PointGuard implementation, show that PointGuard's overhead is low when protecting real security-sensitive applications such as OpenSSL, and show that PointGuard is effective in defending against buffer overflow vulnerabilities that are not blocked by previous defenses.
Towards a Hybrid Approach to Protect Against Memory Safety Vulnerabilities
Memory corruption bugs continue to plague low-level systems software generally written in unsafe programming languages. In order to detect and protect against such exploits, many pre- and post-deployment techniques exist. In this position paper, we propose and motivate the need for a hybrid approach for the protection against memory safety vulnerabilities, combining techniques that can identify the presence (and absence) of vulnerabilities pre-deployment with those that can detect and mitigate such vulnerabilities post-deployment. Our hybrid approach involves three layers: hardware runtime protection provided by capability hardware, software runtime protection provided by compiler instrumentation, and static analysis provided by bounded model checking and symbolic execution. The key aspect of the proposed hybrid approach is that the protection offered is greater than the sum of its parts -- the expense of post-deployment runtime checks is reduced via information obtained during pre-...
Missing the Point(er): On the Effectiveness of Code Pointer Integrity
2015 IEEE Symposium on Security and Privacy, 2015
Memory corruption attacks continue to be a major vector of attack for compromising modern systems. Numerous defenses have been proposed against memory corruption attacks, but they all have their limitations and weaknesses. Stronger defenses such as complete memory safety for legacy languages (C/C++) incur a large overhead, while weaker ones such as practical control flow integrity have been shown to be ineffective. A recent technique called code pointer integrity (CPI) promises to balance security and performance by focusing memory safety on code pointers thus preventing most control-hijacking attacks while maintaining low overhead. CPI protects access to code pointers by storing them in a safe region that is protected by instruction level isolation. On x86-32, this isolation is enforced by hardware; on x86-64 and ARM, isolation is enforced by information hiding. We show that, for architectures that do not support segmentation in which CPI relies on information hiding, CPI's safe region can be leaked and then maliciously modified by using data pointer overwrites. We implement a proofof-concept exploit against Nginx and successfully bypass CPI implementations that rely on information hiding in 6 seconds with 13 observed crashes. We also present an attack that generates no crashes and is able to bypass CPI in 98 hours. Our attack demonstrates the importance of adequately protecting secrets in security mechanisms and the dangers of relying on difficulty of guessing without guaranteeing the absence of memory leaks.
Architecture support for defending against buffer overflow attacks
Workshop on Evaluating and …, 2002
Buffer overflow attacks are the predominant threat tothe secure operation of network and in particular, Internetbasedapplications. Stack smashing is a common mode ofbuffer overflow attack for hijacking system control. Thispaper evaluates two architecture-based techniques to defendsystems against such attacks: (1) the split control anddata stack, and (2) secure return address stack (SRAS). Thesplit stack approach separates control and data stack
Efficient Countermeasures for Software Vulnerabilities Due to Memory Management Errors
status: published
StackGuard: Automatic Adaptive Detection and Prevention of
This paper presents a systematic solution to the persistent problem of buffer overflow attacks. Buffer overflow attacks gained notoriety in 1988 as part of the Morris Worm incident on the Internet. While it is fairly simple to fix individual buffer overflow vulnerabilities, buffer overflow attacks continue to this day. Hundreds of attacks have been discovered, and while most of the obvious vulnerabilities have now been patched, more sophisticated buffer overflow attacks continue to emerge.
Detection and Prevention of Stack Buffer Overflow
2005
ATTACKS How to mitigate remote attacks that exploit buffer overflow vulnerabilities on the stack and enable attackers to take control of the program. The July 2005 announcement by computer security researcher Michael Lynn at the Black Hat security conference of a software flaw in Cisco Systems routers grabbed media attention worldwide. The flaw was an instance of a buffer overflow , a security vulnerability that has been discussed for 40 years yet remains one of the most frequently reported types of remote attack against computer systems. In 2004, the national cyber-security vulnerability database (nvd.nist.gov) reported 323 buffer overflow vulnerabilities, an average of more than 27 new instances per month. For the first six months of 2005, it reported 331 buffer overflow vulnerabilities. Meanwhile, security researchers have sought to develop techniques to prevent or detect the exploitation of these vulnerabilities. Here, we discuss what buffer overflow attacks are and survey the v...
Loading Preview
Sorry, preview is currently unavailable. You can download the paper by clicking the button above.