DIRA: Automatic Detection, Identification, and Repair of Control-Hijacking Attacks
Buffer overflow attacks are the easiest and thus the most widely used method to hijack control of a remote system. Many researchers have proposed methods of buffer overflow attack detection in the past. We present a taxonomy of attack detection methods in the next section. Typically, once an attack is detected the compromised application is terminated and then restarted. Meanwhile, all the dynamic state information is lost (such as the client connections). Later the same attack can reoccur until a proper signature is created and supplied to the IDS. The repeated restarts of the program will prevent it from providing any useful services.
A comprehensive defense strategy against buffer overflow attacks should include the following components:
- Attack detection that can detect an attack before the control is hijacked;
- Attack identification that can generate attack's signature automatically and pass it to an IDS;
- Attack repair that can repair the memory state of the compromised program so that the program will think it has never received any attack packets.
We have developed a tool called DIRA that can instrument a source code of a program in such a way that the resulting binary will posses all the three qualities described above: it will be able to detect an attack, identify the attack packets, and repair itself after an attack. The current version of DIRA is based on GCC 3.4.1 compiler.
During the past decade a lot of research has been vested into all kinds attack detection methods. We have categorized them into several broad groups depending on the components that they change in order to provide protection:
- Extending OS/hardware
- Extending the applications
- Program analysis approaches: lint, Flawfinder, commercial tools
- Run-time approaches: Libsafe, Libverify, Dynamo, BIRD
- Hybrid approaches: program transformation + run-time monitoring
The main idea behind DIRA is to log all changes to program's memory state that occur during its execution. For this purposes DIRA maintains a circular memory updates log which records correspond to single memory updates performed as a result of an assignment operation (such as X=Y) or a standard library call (such as strcpy()) executed by the program.
The attack-detection mechanism used by DIRA is borrowed from RAD project. Each control data structure being protected (such as a return address) is copied to a well-protected buffer at the time of its creation. Before this data structure is used in the program it is compared with the value stored in the buffer. If the values are different then an attack took place.
Each record of the memory updates log includes the following four fields: the read address (which is the source address of the data being written), the write address (the address the data will be written to), the length of the data, and the pre-image of the data being written. The pre-image allows to undo all memory updates at the repair time. The read and write addresses allow one to trace back the data that has changed a control pointer to the point where it first appeared in the program.
The post-attack repair procedure consists of the following two steps. First, the memory state of the program is restored to a pre-attack state. Second, a proper restart point is chosen and the control is transferred to that point. The restart points are implemented by inserting setjmp() calls in the beginning of each function. At the end of repair the control is transferred to the chosen restart point by a longjmp() call.
We have used a number of popular network daemons (named, drcatd, ghttpd, qpopper, proftpd) to evaluate DIRA's performance overhead and its repair capabilities. The results showed that the run-time overhead is between 20% and 50%. We used exploits from public exploit databases to attack three instrumented programs from our test suite. In all cases, attacks were detected and the attack packets were identified. In the two out of three cases, programs were able to repair themselves and continue normal execution. In the remaining case, the program needed to be restarted.
DIRA has become available for download. You need to install the GEM framework first. Then you can download:
DIRA compiler extension;
DIRA run-time code;
ghttpd (includes DIRA's run-time code) --- a web server with a buffer overflow vulnerability. Its Makefile was modified to support DIRA. Once compiled, the application can identify the attack packet and repair itself after the attack. The exploit code is available at Securiteam.
Exploit test suite available upon request. Description of vulnerabilities is available here.
David Brumley, Tzi-cker Chiueh, Robert Johnson, Huijia Lin, Dawn Song, Accurate and Efficient Detection of Integer-based Attacks, in Proceedings of Network and Distributed Systems Security (NDSS 2007) , San Diego, California, USA, February 2007.
Alexey Smirnov, Tzi-cker Chiueh, DIRA: Automatic Detection, Identification, and Repair of Control-Hijacking Attacks, in Proceedings of NDSS'05, San Diego, CA, February 2005.
Alexey Smirnov, Tzi-cker Chiueh, DIRA: Automatic Detection, Identification, and Repair of Control-Hijacking Attacks, DEFCON-13, Las Vegas, NV, July 2005.
This project is supported by an NSF award CT-0627672.
Exploit Databases: Insecure, SecuriTeam, SecurityFocus, deadbeef, Metasploit, xfocus.
Compilers: GCC, GCC Summit (2003, 2004, 2005), Introduction to GCC Internals, GEM.
Attack identification: Buttercup, Autograph, Nemean, Polygraph, Arbor, Covers, Xu et al..
Attack repair: Flashback, ReVirt.