Results 11 - 20
of
148
SigFree: A Signature-Free Buffer Overflow Attack Blocker
- Ieee Transactions On Dependable And Secure Computing
, 2010
"... Abstract—We propose SigFree, an online signature-free out-of-the-box application-layer method for blocking code-injection buffer overflow attack messages targeting at various Internet services such as web service. Motivated by the observation that buffer overflow attacks typically contain executable ..."
Abstract
-
Cited by 50 (8 self)
- Add to MetaCart
(Show Context)
Abstract—We propose SigFree, an online signature-free out-of-the-box application-layer method for blocking code-injection buffer overflow attack messages targeting at various Internet services such as web service. Motivated by the observation that buffer overflow attacks typically contain executables whereas legitimate client requests never contain executables in most Internet services, SigFree blocks attacks by detecting the presence of code. Unlike the previous code detection algorithms, SigFree uses a new data-flow analysis technique called code abstraction that is generic, fast, and hard for exploit code to evade. SigFree is signature free, thus it can block new and unknown buffer overflow attacks; SigFree is also immunized from most attack-side code obfuscation methods. Since SigFree is a transparent deployment to the servers being protected, it is good for economical Internet-wide deployment with very low deployment and maintenance cost. We implemented and tested SigFree; our experimental study shows that the dependency-degree-based SigFree could block all types of code-injection attack packets (above 750) tested in our experiments with very few false positives. Moreover, SigFree causes very small extra latency to normal client requests when some requests contain exploit code. Index Terms—Intrusion detection, buffer overflow attacks, code-injection attacks. Ç 1
Just-intime code reuse: On the effectiveness of fine-grained address space layout randomization
- In Proceedings of the 34th IEEE Symposium on Security & Privacy (S&P
, 2013
"... Abstract—Fine-grained address space layout randomization (ASLR) has recently been proposed as a method of efficiently mitigating runtime attacks. In this paper, we introduce the design and implementation of a framework based on a novel attack strategy, dubbed just-in-time code reuse, that undermines ..."
Abstract
-
Cited by 49 (2 self)
- Add to MetaCart
(Show Context)
Abstract—Fine-grained address space layout randomization (ASLR) has recently been proposed as a method of efficiently mitigating runtime attacks. In this paper, we introduce the design and implementation of a framework based on a novel attack strategy, dubbed just-in-time code reuse, that undermines the benefits of fine-grained ASLR. Specifically, we derail the assumptions embodied in fine-grained ASLR by exploiting the ability to repeatedly abuse a memory disclosure to map an application’s memory layout on-the-fly, dynamically discover API functions and gadgets, and JIT-compile a target program using those gadgets—all within a script environment at the time an exploit is launched. We demonstrate the power of our framework by using it in conjunction with a real-world exploit against Internet Explorer, and also provide extensive evaluations that demonstrate the practicality of just-in-time code reuse attacks. Our findings suggest that fine-grained ASLR may not be as promising as first thought. I.
Digging for data structures
- In Proceeding of 8th Symposium on Operating System Design and Implementation (OSDI’08
, 2008
"... Because writing computer programs is hard, computer programmers are taught to use encapsulation and mod-ularity to hide complexity and reduce the potential for errors. Their programs will have a high-level, hierar-chical structure that reflects their choice of internal ab-stractions. We designed and ..."
Abstract
-
Cited by 49 (0 self)
- Add to MetaCart
(Show Context)
Because writing computer programs is hard, computer programmers are taught to use encapsulation and mod-ularity to hide complexity and reduce the potential for errors. Their programs will have a high-level, hierar-chical structure that reflects their choice of internal ab-stractions. We designed and forged a system, Laika, that detects this structure in memory using Bayesian unsu-pervised learning. Because almost all programs use data structures, their memory images consist of many copies of a relatively small number of templates. Given a mem-ory image, Laika can find both the data structures and their instantiations. We then used Laika to detect three common polymor-phic botnets by comparing their data structures. Because it avoids their code polymorphism entirely, Laika is ex-tremely accurate. Finally, we argue that writing a data structure polymorphic virus is likely to be considerably harder than writing a code polymorphic virus. 1
Address space layout permutation (ASLP): Towards fine-grained randomization of commodity software
- In Proceedings of the 22st Annual Computer Security Applications Conference (ACSAC ’06
, 2006
"... Address space randomization is an emerging and promising method for stopping a broad range of memory corruption attacks. By randomly shifting critical memory regions at process initialization time, address space randomization converts an otherwise successful malicious attack into a benign process cr ..."
Abstract
-
Cited by 48 (1 self)
- Add to MetaCart
(Show Context)
Address space randomization is an emerging and promising method for stopping a broad range of memory corruption attacks. By randomly shifting critical memory regions at process initialization time, address space randomization converts an otherwise successful malicious attack into a benign process crash. However, existing approaches either introduce insufficient randomness, or require source code modification. While insufficient randomness allows successful brute-force attacks, as shown in recent studies, the required source code modification prevents this effective method from being used for commodity software, which is the major source of exploited vulnerabilities on the Internet. We propose Address Space Layout Permutation (ASLP) that introduces high degree of randomness (or high entropy) with minimal performance overhead. Essential to ASLP is a novel binary rewriting tool that can place the static code and data segments of a compiled executable to a randomly specified location and performs finegrained permutation of procedure bodies in the code segment as well as static data objects in the data segment. We have also modified the Linux operating system kernel to permute stack, heap, and memory mapped regions. Together, ASLP completely permutes memory regions in an application. Our security and performance evaluation shows minimal performance overhead with orders of magnitude improvement in randomness (e.g., up to 29 bits of randomness on a 32-bit architecture). 1
Efficient and extensible security enforcement using dynamic data flow analysis
- In Computer and Communications Security (CCS
, 2008
"... Current taint tracking systems suffer from high overhead and a lack of generality. In this paper, we solve both of these issues with an extensible system that is an order of magnitude more efficient than previous software taint tracking systems and is fully general to dynamic data flow tracking prob ..."
Abstract
-
Cited by 46 (2 self)
- Add to MetaCart
(Show Context)
Current taint tracking systems suffer from high overhead and a lack of generality. In this paper, we solve both of these issues with an extensible system that is an order of magnitude more efficient than previous software taint tracking systems and is fully general to dynamic data flow tracking problems. Our system uses a compiler to transform untrusted programs into policy-enforcing programs, and our system can be easily reconfigured to support new analyses and policies without modifying the compiler or runtime system. Our system uses a sound and sophisticated static analysis that can dramatically reduce the amount of data that must be dynamically tracked. For server programs, our system’s average overhead is 0.65% for taint tracking, which is comparable to the best hardware-based solutions. For a set of compute-bound benchmarks, our system produces no runtime overhead because our compiler can prove the absence of vulnerabilities, eliminating the need to dynamically track taint. After modifying these benchmarks to contain format string vulnerabilities, our system’s overhead is less than 13%, which is over 6 × lower than the previous best solutions. We demonstrate the flexibility and power of our system by applying it to file disclosure vulnerabilities, a problem that taint tracking cannot handle. To prevent such vulnerabilities, our system introduces an average runtime overhead of 0.25 % for three open source server programs.
Data space randomization
- In Proc. Int. Conf. on Detection of Intrusions and Malware, and Vulnerability Assessment
, 2008
"... Abstract. Over the past several years, US-CERT advisories, as well as most critical updates from software vendors, have been due to memory corruption vulnerabilities such as buffer overflows, heap overflows, etc. Several techniques have been developed to defend against the exploitation of these vuln ..."
Abstract
-
Cited by 41 (2 self)
- Add to MetaCart
(Show Context)
Abstract. Over the past several years, US-CERT advisories, as well as most critical updates from software vendors, have been due to memory corruption vulnerabilities such as buffer overflows, heap overflows, etc. Several techniques have been developed to defend against the exploitation of these vulnerabilities, with the most promising defenses being based on randomization. Two randomization techniques have been explored so far: address space randomization (ASR) that randomizes the location of objects in virtual memory, and instruction set randomization (ISR) that randomizes the representation of code. We explore a third form of randomization called data space randomization (DSR) that randomizes the representation of data stored in program memory. Unlike ISR, DSR is effective against non-control data attacks as well as code injection attacks. Unlike ASR, it can protect against corruption of nonpointer data as well as pointer-valued data. Moreover, DSR provides a much higher range of randomization (typically 2 32 for 32-bit data) as compared to ASR. Other interesting aspects of DSR include (a) it does not share a weakness common to randomization-based defenses, namely, susceptibility to information leakage attacks, and (b) it is capable of detecting some exploits that are missed by full bounds-checking techniques, e.g., some of the overflows from one field of a structure to the next field. Our implementation results show that with appropriate design choices, DSR can achieve a performance overhead in the range of 5 % to 30 % for a range of programs.
Enhanced operating system security through efficient and fine-grained address space randomization
- In Proceedings of the 21st USENIX Security Symposium
, 2012
"... In recent years, the deployment of many application-level countermeasures against memory errors and the in-creasing number of vulnerabilities discovered in the ker-nel has fostered a renewed interest in kernel-level ex-ploitation. Unfortunately, no comprehensive and well-established mechanism exists ..."
Abstract
-
Cited by 40 (3 self)
- Add to MetaCart
(Show Context)
In recent years, the deployment of many application-level countermeasures against memory errors and the in-creasing number of vulnerabilities discovered in the ker-nel has fostered a renewed interest in kernel-level ex-ploitation. Unfortunately, no comprehensive and well-established mechanism exists to protect the operating system from arbitrary attacks, due to the relatively new development of the area and the challenges involved. In this paper, we propose the first design for fine-grained address space randomization (ASR) inside the operating system (OS), providing an efficient and com-prehensive countermeasure against classic and emerg-ing attacks, such as return-oriented programming. To motivate our design, we investigate the differences with application-level ASR and find that some of the well-established assumptions in existing solutions are no longer valid inside the OS; above all, perhaps, that infor-mation leakage becomes a major concern in the new con-text. We show that our ASR strategy outperforms state-of-the-art solutions in terms of both performance and se-curity without affecting the software distribution model. Finally, we present the first comprehensive live reran-domization strategy, which we found to be particularly important inside the OS. Experimental results demon-strate that our techniques yield low run-time perfor-mance overhead (less than 5 % on average on both SPEC and syscall-intensive benchmarks) and limited run-time memory footprint increase (around 15 % during the exe-cution of our benchmarks). We believe our techniques can greatly enhance the level of OS security without compromising the performance and reliability of the OS. 1
Orchestra: Intrusion detection using parallel execution and monitoring of program variants in userspace
- In Proceedings of the European Conference on Computer Systems
, 2009
"... In a Multi-Variant Execution Environment (MVEE), several slightly different versions of the same program are executed in lockstep. While this is done, a monitor compares the behavior of the versions at certain synchronization points with the aim of detecting discrepancies which may indicate attacks. ..."
Abstract
-
Cited by 39 (4 self)
- Add to MetaCart
In a Multi-Variant Execution Environment (MVEE), several slightly different versions of the same program are executed in lockstep. While this is done, a monitor compares the behavior of the versions at certain synchronization points with the aim of detecting discrepancies which may indicate attacks. As we show, the monitor can be implemented entirely in user space, eliminating the need for kernel modifications. As a result, the monitor is not a part of the trusted code base. We have built a fully functioning MVEE, named Orchestra, and evaluated its effectiveness. We obtained benchmark results on a quad-core system, using two variants which grow the stack in opposite directions. The results show that the overall penalty of simultaneous execution and monitoring of two variants on a multi-core system averages about 15 % relative to unprotected conventional execution.
Sweeper: A lightweight endto-end system for defending against fast worms
- InProceedings of 2007 EuroSys Conference
"... The vulnerabilities that plague computers cause endless grief to users. Slammer compromised millions of hosts in minutes; a hit-list worm would take under a second. Recently proposed techniques respond better than manual approaches, but require expensive instrumentation, which limits deployment. Alt ..."
Abstract
-
Cited by 36 (3 self)
- Add to MetaCart
(Show Context)
The vulnerabilities that plague computers cause endless grief to users. Slammer compromised millions of hosts in minutes; a hit-list worm would take under a second. Recently proposed techniques respond better than manual approaches, but require expensive instrumentation, which limits deployment. Although spreading “antibodies ” (e.g. signatures) ameliorates this limitation, hosts depending on antibodies are defenseless until inoculation; to the fastest hit-list worms this delay is crucial. Additionally, most recently proposed techniques cannot provide recovery to provide continuous service after an attack. We propose a novel solution called Sweeper that provides both fast and accurate post-attack analysis and efficient recovery with low normal execution overhead. Sweeper innovatively combines several techniques: (1) Sweeper uses lightweight monitoring techniques to detect a wide array of suspicious requests, providing a first level of defense. (2) By cleverly leveraging lightweight checkpointing, Sweeper postpones heavyweight monitoring until absolutely necessary — after an attack is detected. Sweeper rolls back and re-executes multiple times to dynamically apply heavyweight analysis techniques via dynamic binary instrumentation. Since only the execution involved in the attack is analyzed, the analysis is efficient, yet thorough. (3) Based on the analysis results, Sweeper automatically generates lowoverhead antibodies to prevent future attacks of the same vulnerability. (4) Finally, Sweeper again re-executes to perform fast recovery for continuous service. We implement Sweeper in a real system. Our experimental results with three real-world servers and four real security vulnerabilities show that Sweeper can detect an attack and generate antibodies in under 60 milliseconds. Our results also show that Sweeper imposes under 1 % overhead during normal execution, clearly suitable for widespread production deployment (especially since Sweeper also allows partial deployment). Finally, we analytically show that, for a
DieHarder: Securing the Heap
"... Heap-based attacks depend on a combination of memory management errors and an exploitable memory allocator. Many allocators include ad hoc countermeasures against particular exploits, but their effectiveness against future exploits has been uncertain. This paper presents the first formal treatment o ..."
Abstract
-
Cited by 36 (3 self)
- Add to MetaCart
(Show Context)
Heap-based attacks depend on a combination of memory management errors and an exploitable memory allocator. Many allocators include ad hoc countermeasures against particular exploits, but their effectiveness against future exploits has been uncertain. This paper presents the first formal treatment of the impact of allocator design on security. It analyzes a range of widely-deployed memory allocators, including those used by Windows, Linux, Free-BSD, and OpenBSD, and shows that they remain vulnerable to attack. It then presents DieHarder, a new allocator whose design was guided by this analysis. DieHarder provides the highest degree of security from heap-based attacks of any practical allocator of which we are aware, while imposing modest performance overhead. In particular, the Firefox web browser runs as fast with DieHarder as with the Linux allocator.
