A. Baratloo, N. Singh, and T. Tsai. Transparent run-time defense against stack smashing attacks. In USENIX Annual Technical Conference, pages 251--262, Berkeley, CA, June 2000. Home/Search Document Details and Download
Summary Related Articles Check |
This paper is cited in the following contexts:
First 50 documents Next 50
FormatGuard: Automatic Protection From printf.. - Cowan, Barringer, .. (2001) (35 citations) (Correct)
....[19] is a library that aborts programs if they call printf like functions with a format string that is writable and contains a n directive. This technique is often effective, but because both writable format strings and n directives are legal, it can be subject to false positives. libsafe [2] is a library approach to defending against buffer overflow attacks. In version 2.0, libsafe has added protection against format bugs by applying their technique of the library inspecting the call stack for plausible arguments, in this instance rejecting n directives that try to write to the ....
Arash Baratloo, Navjot Singh, and Timothy Tsai. Transparent Run-Time Defense Against Stack Smashing Attacks. In 2000.
HEALERS: A Toolkit for Enhancing the Robustness and Security.. - Fetzer, Xiao (2003) (1 citation) (Correct)
....of wrappers to satisfy their needs. This is illustrated in Figure 1. For example, a process with root privilege may use a security wrapper that can prevent buffer overflow attacks [3] Previous studies indicate that such kind of attacks are a major cause of security breaches in operating systems [1]. A user application that desires high availability can use a robustness wrapper that prevents a large class of software failures (e.g. crashes, hangs, or aborts) Some application may want to log the errors that occurred during its operation for later failure diagnosis. In this case, they can use ....
Arash Baratloo, Navjot Singh, and Timothy Tsai. Transparent run-time defense against stack smashing attacks. In Proceedings of USENIX Annual Technical Conference, June 2000.
Detecting Heap Smashing Attacks Through Fault Containment.. - Fetzer, Xiao (2001) (4 citations) (Correct)
....corruption or a memory fault of the program. However, it can also be exploited maliciously to alter the control flow of a program in order to break the security of the system. Depending on whether a buffer is allocated on the heap or on the stack one distinguishes between stack smashing attacks [5, 2] and heap smashing attacks. A stack smashing attack overwrites a return address stored on the stack to change the control flow of a program. For example, if the return address of a function is stored after a buffer on the stack, a malicious user could overwrite the return address of a ....
....to the location pointed to by the return address. Consequently, an attacker cannot invoke its code by changing the control flow of the program. This approach, however, requires recompilation of the source code and the attacker has to be prevented from reading or guessing the canary word. Libsafe [2] is a dynamically loadable C library which intercepts all unsafe function calls and transparently protects processes against stack smashing attacks. This approach does not eliminate stack buffer overflows. Rather, it confines the scope of any potential buffer overflow to be within the current ....
[Article contains additional citation context not shown here]
Arash Baratloo, Navjot Singh, and Timothy Tsai. Transparent run-time defense against stack smashing attacks. In USENIX Annual Technical Conference, San Diego, California, June 2000.
An Automated Approach to Increasing the Robustness of C Libraries - Fetzer, Xiao (2002) (4 citations) (Correct)
....is called stateful checking because the wrapper needs to perform state keeping for allocated blocks. In [4] we have shown that this technique can detect and prevent heap buffer overflows successfully. 7 Moreover, our wrapper can prevent stack smashing attacks using the same mechanism as Libsafe [1]. If a buffer is neither on the heap nor on the stack, the wrapper sets up a signal handler and tests the accessibility of the memory. For large buffers that spread across multiple memory pages, only one byte per page needs to be tested. This approach was previously used in [2] to harden I O ....
....detect buffer overflows that occur within the same memory page. Such overflows typically do not generate memory access fault and hence cannot be detected using a signal handler. Nevertheless, they may overwrite other data structures after the buffer and may impose security risks in some systems [4, 1]. 9. Conclusion and Future Work Software robustness is essential to critical applications. This paper presents an automated approach to increase the robustness of C libraries through adaptive fault injection experiments. Our system extracts function prototypes in a shared library through header ....
Arash Baratloo, Navjot Singh, and Timothy Tsai. Transparent run-time defense against stack smashing attacks. In Proceedings of USENIX Annual Technical Conference, June 2000.
Architecture Support for Defending Against Buffer.. - Xu, Kalbarczyk, Patel.. (2002) (5 citations) (Correct)
....is then decremented by one word. When the ret instruction is executed, it uses the return address saved on the control stack. Effectiveness of the compiler based split stack approach. The effectiveness of this approach is evaluated using actual buffer overflow exploits provided by the LibSafe [3] team saved frame ptr return address B parameters saved frame ptr return address C 0000000000000 0000000000000 0000000000000 0000000000000 0000000000000 1111111111111 1111111111111 1111111111111 1111111111111 1111111111111 1111111111111 parameters saved frame ptr return address ....
....the return address and transfers execution control to the heap or shared libraries. C Library Patches. Since many buffer overflow vulnerabilities are caused by unsafe C library functions such as gets and strcpy, this class of solutions patch the standard C library for detections. Libsafe [3] intercepts function calls to shared C Library and conducts frame pointer based boundary checking. These approaches can fail in two cases: 1) if a program chooses not to enable frame pointer at compile time (many programs do so for performance optimization) and (2) if the buffer overflow ....
A. Baratloo, T. Tsai, and N. Singh. Transparent Run-Time Defense Against Stack Smashing Attacks. In Proceedings. of the USENIX Annual Technical Conference, June 2000.
Analyzing String Buffers in C - Simon, King (2002) (Correct)
....the rst null (if it exists) must occur to the right of the O . Likewise after the second write the analysis infers s n 2. The write to the 4 character bu er t is safe if s n 3. However s n 2 does not imply s n 3 and therefore the call to strcpy generates a spurious warning. Inserting s[2]= a ; s[3] y ; in front of the call to strcpy will yield a de nite error since s n 4 implies that s n 3 cannot be satis ed. On the other hand, writing the same four characters to the same positions in reverse order only leads to a warning: s n = 0 holds valid until s[0] is written which ....
....as to minimize the number of variables considered in the analysis of each function. 5 Related work Apart from those static analyses already discussed [8, 12, 13, 23] most of proposals for detecting overruns are either based on lexical analysis [22] testing [11] or stack protection mechanisms [2, 10]. ITS4 [22] is a lexical analysis tool that searches for security problems using a database of potentially dangerous constructs. Lexical analysis is fast and calls to problematic library functions can be agged. Such a limited approach, however, will fail to nd problematic string bu er ....
[Article contains additional citation context not shown here]
A. Baratloo, N. Singh, and T. Tsai. Transparent Run-Time Defense Against StackSmashing Attacks. In Ninth USENIX Security Symposium, 2000.
A Comparison of Publicly Available Tools for Dynamic Buffer.. - Wilander, Kamkar (2003) (6 citations) (Correct)
....intrusion prevention. Statically it patches library functions in C that constitute potential buffer overflow vulnerabilities. A range check is made before the actual function call which ensures that the return address and the base pointer cannot be overwritten. Further protection has been provided [2] with Libverify using a similar dynamic approach to StackGuard (see Section 3.3) 3.6.1 Libsafe The key idea behind Libsafe is to estimate a safe boundary for buffers on the stack at run time and then check this boundary before any vulnerable function is allowed to write to the buffer. ....
....injected into each function by overwriting the first instruction with a call to wrapper entry and all return instructions with a call to wrapper exit. The need for copying the code to the heap is due to the Intel CPU architecture. On other platforms this could be solved without copying the code [2]. Libverify is needed to give a more complete protection of the return address since Libsafe only addresses standard C library functions (as pointed out by Istvan Simon [32] With Libsafe vulnerabilities could still occur where the programmer has implemented his her own memory handling. Libsafe ....
A. Baratloo, N. Singh, and T. Tsai. Transparent run-time defense against stack smashing attacks. In Proceedings of the 2000.
Cyclone: A safe dialect of C - Jim, Morrisett, Grossman, Hicks.. (2002) (80 citations) (Correct)
....[13, 14] SLAM [3, 2] PRE x [5] and cqual [32] 2. Inserting run time checks. C s assert statements, the Safe C system [1] and debugging versions of libraries, like Electric Fence, cause programs to perform sanity checks as they run. This technique has been used to combat bu er over ows [9, 4, 19] and printf format string attacks [8] 3. Combining static analysis and run time checks. Systems like CCured [31] perform static analyses to check source code for safety, and automatically insert run time checks where safety cannot be guaranteed statically. These are good techniques Cyclone ....
Arash Baratloo, Navjot Singh, and Timothy Tsai. Transparent run-time defense against stack-smashing attacks. In USENIX Annual 2000.
Low-Overhead Software Dynamic Translation - Scott, Davidson, Skadron (2001) (Correct)
....our tool, yet 1. Locating and keeping track of stack and heap boundaries during program execution is a simple matter on many systems. 16 averages slowdowns of anywhere from 54x to 1743x on synthetic microbenchmarks [9] Our safety checker compares favorably to Baratloo, Singh, et al. s libverify [5]. They report slowdowns of 1.15x. However, their technique is substantially more complex than our simple extensions to Strata. 4.2 Preventing unauthorized system calls The second Strata based safety checker that we implemented prevents unauthorized system calls in untrusted binaries. Such safety ....
....In contrast, our safety checker has significantly lower overhead with the same preventive power. The libverify library of Baratloo, et al. prevents stack smashing attacks by dynamically maintaining a stack of so called canary words in parallel with the normal procedure activation stack [5]. When a procedure returns, the canary word on the parallel stack is compared with the canary word on the activation stack. If the two are different, the system concludes that a buffer overflow has occurred. The libverify library employs dynamic translation to insert the code to implement the ....
Arash Baratloo, Navjot Singh, and Timothy Tsai. Transparent run-time defense against stack smashing attacks. In Proceedings of the USENIX Annual Technical Conference, June 2000.
Global Computing Systems - Germain, Fedak, Neri, Cappello (2001) (1 citation) (Correct)
....overrun attacks. In the run time approach, the key idea is to monitor the execution of a process and allowing only safe operations. A safety mechanism is interposed between the process and the operating system. This interposition mechanism can be sited either at the C library calls level (libsafe [11]) or at the system calls level (Janus [27] Consh [2] MAPbox [1] The owner of machine expresses in a safety policy the resources the application is allowed to use, mainly network and file usage. Extending this principle of interposition, the User Mode Linux [22] project offers a complete ....
A. Baratloo, T. Tsai, and N. Singh. Transparent run-time defense against stack smashing attacks. In USENIX Ann. Technical Conf., 2000.
A Secure Access Control Mechanism against Internet Crackers - Kourai, Chiba (2001) (Correct)
....Gateway Interface (CGI) program, which can maliciously hijack a server [2] Once a server is hijacked, the cracker can use the server for performing malicious operations. To protect the servers from these attacks with negligible cost, several techniques such as StackGuard [8] has been developed [9, 3, 14]. These techniques are for detecting the bu#er overflow attack and invalidating it. Since those technique cannot detect all types of bu#er overflow attack, imposing access restrictions on a server is still necessary. Access restrictions minimize damages by the attack in cases where the server is ....
A. Baratloo, T. Tsai, and N. Singh. Transparent Run-Time Defense Against Stack Smashing Attacks. In Proceedings of the USENIX Annual Technical Conference, June 2000.
Libsafe: Protecting Critical Elements of Stacks - Tsai, Singh (2001) (2 citations) Self-citation (Tsai Singh) (Correct)
....Linux as a dynamically loadable library called libsafe. Libsafe has been shown to detect several known attacks and can potentially prevent yet unknown attacks. Experiments indicate that the performance overhead of libsafe is negligible. The initial version of libsafe was released in April 2000. [3] Recently, another widespread vulnerability has received a great deal of attention: the format string vulnerability. The latest version of libsafe, version 2.0, implements a solution for detecting and handling the most dangerous format string vulnerability exploits, while preserving the low ....
Arash Baratloo, Timothy Tsai, and Navjot Singh. Transparent run-time defense against stack smashing attacks. In Proceedings of the USENIX Annual Technical Conference, June 2000.
Libsafe 2.0: Detection of Format String Vulnerability Exploits - Tsai, Singh (2001) Self-citation (Tsai Singh) (Correct)
....exploits. NOTE: This paper only describes one particular feature of libsafe version 2.0: the ability to detect and handle format string vulnerability exploits. Other features include support for code compiled without frame pointer instructions, extra debugging facilities, and bug xes. See [1] for details of the original version of libsafe. 1 Introduction Bu er over ow exploits constitute perhaps the most common form of computer security attack [4, 5, 6] Such exploits take advantage of programming errors to over ow bu ers, thus writing unintended data to the part of memory that ....
....the part of memory that immediately follows the targeted bu ers. If the targeted bu er exists on the process stack, then the exploit often attempts to overwrite a return address on the stack, which often results in obtaining root access to that machine. The original version of libsafe, version 1. 3 [1], presented a signi cant advance in the detection and handling of bu er over ow attacks by o ering a solution that detects a large number of exploits with low overhead and tremendous ease of use 1 . Recently, another widespread vulnerability has received a great deal of attention: the format ....
Arash Baratloo, Timothy Tsai, and Navjot Singh. Transparent run-time defense against stack smashing attacks. In Proceedings of the USENIX Annual Technical Conference, June 2000.
An Efficient and Backwards-Compatible Transformation to.. - Xu, DuVarney, Sekar (2004) (Correct)
No context found.
A. Baratloo, N. Singh, and T. Tsai. Transparent run-time defense against stack smashing attacks. In USENIX Annual Technical Conference, pages 251--262, Berkeley, CA, June 2000.
A Methodology for Designing Countermeasures Against.. - Younan, Joosen, Piessens (2004) (Correct)
No context found.
A. Baratloo, N. Singh, and T. Tsai. Transparent run-time defense against stack smashing attacks. In USENIX 2000.
Vulnerability-Specific Execution Filtering for Exploit.. - Newsome, Brumley, Song (2005) (Correct)
No context found.
Arash Baratloo, Navjot Singh, and Timothy Tsai. Transparent run-time defense against stack smashing attacks. In USENIX Annual Technical Conference 2000.
Policy and Implementation Assurance for Software Security - Wilander (2005) (Correct)
No context found.
Arash Baratloo, Navjot Singh, and Timothy Tsai. Transparent runtime defense against stack smashing attacks. In Proceedings of the 2000.
Using DISE to Protect Return Addresses from Attack - Marc Corliss Christopher (2004) (Correct)
No context found.
A. Baratloo, N. Singh, and T. Tsai. Transparent run-time defense against stack smashing attacks. In Proc. of the USENIX Annual Technical Conference, Jun. 2000.
Efficient Techniques for Comprehensive Protection from.. - Bhatkar, Sekar, DuVarney (2005) (2 citations) (Correct)
No context found.
A. Baratloo, N. Singh, and T. Tsai. Transparent run-time defense against stack smashing attacks. In USENIX Annual Technical Conference, pages 251-- 262, Berkeley, CA, June 2000.
Buffer Overflow and Format String Overflow Vulnerabilities - Lhee, Chapin (2002) (Correct)
No context found.
Baratloo A, Singh N, Tsai T. Transparent Run-Time Defense Against Stack Smashing Attacks. Proceedings of the 2000 USENIX Annual Technical Conference USENIX: San Jose, CA, June 2000; 251--262.
An Efficient and Backwards-Compatible Transformation to.. - Xu, DuVarney, Sekar (2004) (Correct)
No context found.
A. Baratloo, N. Singh, and T. Tsai. Transparent run-time defense against stack smashing attacks. In USENIX Annual Technical Conference, pages 251--262, Berkeley, CA, June 2000.
Fast and Automated Generation of Attack Signatures: A Basis.. - Liang, Sekar (2005) (1 citation) (Correct)
No context found.
A. Baratloo, N. Singh, and T. Tsai. Transparent run-time defense against stack smashing attacks. In USENIX Annual Technical Conference, 2000.
Type-Assisted Dynamic Buffer Overflow Detection - Lhee, Chapin (2002) (11 citations) (Correct)
No context found.
A. Baratloo, N. Singh, and T. Tsai. Transparent runtime defense against stack smashing attacks. In Proceedings of the 2000.
Hardware and Binary Modification Support for Code Pointer .. - Tuck, Calder, Varghese (2004) (2 citations) (Correct)
No context found.
Arash Baratloo, Timothy Tsai, and Navjot Singh. Transparent run-time defense against stack smashing attacks. In Proceedings of the USENIX Annual Technical Conference, June 2000.
Code Inection in C and CPP: A Survey of Vulnerabilities.. - Younan, Joosen, Piessens (2004) (Correct)
No context found.
Arash Baratloo, Navjot Singh, and Timothy Tsai. Transparent RunTime Defense Against Stack Smashing Attacks. In USENIX 2000.
A Methodology for Designing Countermeasures Against.. - Younan, Joosen, Piessens (2005) (Correct)
No context found.
A. Baratloo, N. Singh, and T. Tsai. Transparent run-time defense against stack smashing attacks. In USENIX 2000.
Building a Reactive Immune System for Software Services - Sidiroglou, Locasto.. (2005) (5 citations) (Correct)
No context found.
A. Baratloo, N. Singh, and T. Tsai. Transparent Run-Time Defense Against Stack Smashing Attacks. In Proceedings of the USENIX Annual Technical Conference, June 2000.
Building a Reactive Immune System for Software Services - Sidiroglou, Locasto.. (2005) (5 citations) (Correct)
No context found.
A. Baratloo, N. Singh, and T. Tsai. Transparent Run-Time Defense Against Stack Smashing Attacks. In Proceedings of the USENIX Annual Technical Conference, June 2000.
Building a Reactive Immune System for Software Services - Sidiroglou, Locasto.. (2004) (5 citations) (Correct)
No context found.
A. Baratloo, N. Singh, and T. Tsai. Transparent Run-Time Defense Against Stack Smashing Attacks. In Proceedings of the USENIX Annual Technical Conference, June 2000.
Building a Reactive Immune System for Software Services - Sidiroglou, Locasto.. (2004) (5 citations) (Correct)
No context found.
A. Baratloo, N. Singh, and T. Tsai. Transparent Run-Time Defense Against Stack Smashing Attacks. In Proceedings of the USENIX Annual Technical Conference, June 2000.
Countering Network Worms through Automatic Patch Generation - Sidiroglou, Keromytis (2003) (12 citations) (Correct)
No context found.
A. Baratloo, N. Singh, and T. Tsai. Transparent Run-Time Defense Against Stack Smashing Attacks. In Proceedings of the USENIX Annual Technical Conference, June 2000.
Using Execution Transactions To Recover From Buffer.. - Stelios Sidiroglou.. (2004) (1 citation) (Correct)
No context found.
A. Baratloo, N. Singh, and T. Tsai. Transparent Run-Time Defense Against Stack Smashing Attacks. In Proceedings of the USENIX Annual Technical Conference, June 2000.
A Processor Architecture Defense against Buffer Overflow.. - McGregor, Karig, Shi, Lee (2003) (2 citations) (Correct)
No context found.
A. Baratloo, N. Singh, and T. Tsai, "Transparent Run-time Defense Against Stack Smashing Attacks," Proceedings of 9 USENIX Security Symposium, June 2000.
Hardware Support for High Performance, Intrusion-.. - Saggese, Basile.. (2004) (Correct)
No context found.
A. Baratloo, N. Singh, and T. Tsai, "Transparent run-time defense against stack smashing attacks," in Proc. of USENIX Annual Technical Conference, 2000.
Enlisting Hardware Architecture - To Thwart Malicious (Correct)
No context found.
A. Baratloo, N. Singh, and T. Tsai, "Transparent Run-time Defense against Stack Smashing Attacks," Proc. of the 9th USENIX Security Symposium, June 2000.
Secure Isolation and Migration of Untrusted Legacy Applications - Jason (2004) (1 citation) (Correct)
No context found.
A. Baratloo, N. Singh, and T. Tsai. Transparent Run-Time Defense Against Stack Smashing Attacks. In Proceedings of the USENIX Annual Technical Conference, 2000.
Countering Network Worms through Automatic Patch Generation - Sidiroglou, Keromytis (2003) (12 citations) (Correct)
No context found.
A. Baratloo, N. Singh, and T. Tsai. Transparent Run-Time Defense Against Stack Smashing Attacks. In Proceedings of the USENIX Annual Technical Conference, June 2000.
A Network Worm Vaccine Architecture - Stelios Sidiroglou Stelios (2003) (4 citations) (Correct)
No context found.
A. Baratloo, N. Singh, and T. Tsai. Transparent Run-Time Defense Against Stack Smashing Attacks. In Proceedings of the USENIX Annual Technical Conference, June 2000.
Countering Network Worms through Automatic Patch Generation - Sidiroglou, Keromytis (2003) (12 citations) (Correct)
No context found.
A. Baratloo, N. Singh, and T. Tsai. Transparent Run-Time Defense Against Stack Smashing Attacks. In Proceedings of the USENIX Annual Technical Conference, June 2000.
PointGuard™: Protecting Pointers from Buffer.. - Cowan, Beattie.. (2003) (Correct)
No context found.
Arash Baratloo, Navjot Singh, and Timothy Tsai. Transparent Run-Time Defense Against Stack Smashing Attacks. In 2000.
A Practical Dynamic Buffer Overflow Detector - Olatunji Ruwase Transmeta (2004) (10 citations) (Correct)
No context found.
A. Baratloo, N. Singh, and T. Tsai. Transparent runtime defense against stack smashing attacks. In Proceedings of the USENIX Annual Technical Conference, pages 251-- 262, June 2000.
Cyclone: A safe dialect of C - Jim, Morrisett, Grossman, Hicks.. (2002) (80 citations) (Correct)
No context found.
Arash Baratloo, Navjot Singh, and Timothy Tsai. Transparent run-time defense against stack-smashing attacks. In USENIX Annual 2000.
Lightweight Wrappers for Interfacing with Binary Code in CCured - Matthew Harren May (Correct)
No context found.
Baratloo, A., Singh, N., Tsai, T.: Transparent run-time defense against stack smashing attacks. In: Proceedings of the USENIX Annual Technical Conference. (2000)
An Overview of Common Programming Security Vulnerabilities and.. - Younan (2003) (Correct)
No context found.
Arash Baratloo, Navjot Singh, and Timothy Tsai. Transparent run-time defense against stack smashing attacks. [USE00].
Finding Security Vulnerabilities Before Evil Doers Do - David Evans Evans (Correct)
No context found.
Arash Baratloo, Navjot Singh and Timothy Tsai. Transparent Run-Time Defense Against Stack-Smashing Attacks. 9 August 2000.
Guarded Memory Move (GMM) - Detection (Correct)
No context found.
Arash Baratloo, Timothy Tsai, and Navjot Singh. Transparent run-time defense against stack smashing attacks. In Proceedings of the USENIX Annual Technical Conference, June 2000.
Lightweight Wrappers for Interfacing with Binary Code in CCured - Harren, Necula (Correct)
No context found.
Baratloo, A., Singh, N., Tsai, T.: Transparent run-time defense against stack smashing attacks. In: Proceedings of the USENIX Annual Technical Conference. (2000)
CASPER: Compiler-Assisted Securing of Programs at Runtime - Kc, Edwards, Kaiser.. (2002) (Correct)
No context found.
A. Baratloo, N. Singh, and T. Tsai. Transparent run-time defense against stack smashing attacks. In Proceedings of the 2000.
Adaptive Security Policies Enforced By Software Dynamic Translation - Lamanna (2002) (Correct)
No context found.
Arash Baratloo, Navjot Singh, and Timothy Tsai. Transparent run-time defense against stack smashing attacks. In Proceedings of the USENIX Annual Technical Conference, June 2000.
Software Security for Open-Source Systems - Cowan (2003) (2 citations) (Correct)
No context found.
A. Baratloo, N. Singh, and T. Tsai, "Transparent RunTime Defense Against Stack Smashing Attacks," 2000 Usenix Ann. Technical Conf., Usenix Assoc., 2000, pp. 257--262.
First 50 documents Next 50
Online articles have much greater impact More about CiteSeer.IST Add search form to your site Submit documents Feedback
CiteSeer.IST - Copyright Penn State and NEC