SigFree: A Signature-free Buffer Overflow Attack Blocker



This project propose SigFree, a realtime, signature-free, out-ofthe-box, application layer blocker for preventing buffer overflow attacks, one of the most serious cyber security threats. SigFree can filter out 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. SigFree first blindly dissembles and extracts instruction sequences from a request. It then applies a novel technique called code abstraction, which uses data flow anomaly to prune useless instructions in an instruction sequence. Finally it compares the number of useful instructions to a threshold to determine if this instruction sequence contains code. 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 transparent 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 showed that SigFree could block all types of codeinjection attack packets (above 250) tested in our experiments. Moreover, SigFree causes negligible throughput degradation to normal client requests

Existence System:-

Detection of Data Flow Anomalies There are static or dynamic  methods to detect data flow anomalies in the software reliability and testing field. Static methods are not suitable in our case due to its slow speed; dynamic methods are not suitable either due to the need for real execution of a program with some inputs.

Proposed System:-

Their scheme is rule-based, whereas SigFree is a generic approach which does not require any pre-known patterns. Then, it uses the found patterns and a data flow analysis technique called program slicing to analyze the packet’s payload to see if the packet really contains code Four rules (or cases) are discussed  in their project: Case 1 not only assumes the occurrence of the call/jmp instructions, but also expects the push instruction appears before the branch; Case 2 relies on the interrupt instruction; Case 3 relies on instruction ret; Case 4 exploits hidden branch instructions. Besides, they used a special rule to detect polymorphic exploit code which contains a loop. Although they mentioned that the above rules are initial sets and may require updating with time, it is always possible for attackers to bypass those pre-known rules. Moreover, more rules mean more overhead and longer latency in filtering packets. In contrast, SigFree exploits a different data flow analysis technique, which is much harder for exploit code to evade.

We proposed SigFree, a realtime, signature free, out of- the-box blocker that can filter code-injection buffer overflow attack messages, one of the most serious cyber security threats, to various Internet services. SigFree does not require any signatures, thus it can block new, unknown attacks


1.Prevention/Detection of Buffer Overflows

Throughout the history of cyber security, buffer overflow is one of the most serious vulnerabilities in computer systems. Buffer overflow vulnerability is a root cause for most of the cyber attacks such as server

breaking-in, worms, zombies, and botnets. Buffer overflow attacks are the most popular choice in these attacks, as they provide substantial control over a victim.

Class 1A: Finding bugs in source code. Buffer overflows are fundamentally due to programming bugs. Accordingly, various bug-finding tools have been developed. The bug-finding techniques used in

these tools, which in general belong to static analysis, include but not limited to model checking and bugs-asdeviant- behavior.

Compiler extensions. “If the source code is available, a developer can add buffer overflow detection automatically to a program by using a modified compiler.”

Class 1C: OS modifications. Modifying some aspects of the operating system may prevent buffer overflows such as Pax , LibSafe  and e-NeXsh .

Class 1C techniques need to modify the OS. In contrast, SigFree does not need any modification of the OS.

Class 1D: Hardware modifications. A main idea of hardware modification is to store all return addresses on the processor [41]. In this way, no input can change any return address.

Class 1E: Defense-side obfuscation. Address Space Layout Randomization (ASLR) is a main component of PaX . Bhatkar and Sekar  proposed a comprehensive address space randomization scheme. Addressspace randomization, in its general form , can detect exploitation of all memory errors.

Class 1F: Capturing code running symptoms of buffer overflow attacks. Fundamentally, buffer overflows area code running symptom. If such unique symptoms can be precisely captured, all buffer overflows can be detected.

2.Worm Detection and Signature Generation

The implementation of their approach is resilient to a number of code transformation techniques. Although their techniques also handle binary code, they perform offline analysis. In contrast, SigFree is an online attack blocker. As such, their techniques and SigFree are complementary to each other with different purposes. Moreover, unlike

SigFree, their techniques  may not be suitable to block the code contained in every attack packet, because some buffer overflow code is so simple that very little control flow information can be exploited

3. SigFree Attack Model

An attacker exploits a buffer overflow vulnerability of a web server by sending a crafted request, which contains a malicious payload. Figure 3 shows the format of a HTTP request. There are several HTTP request methods among which GET and POST are most often used by attackers. Although HTTP 1.1 does not allow GET to have a request body, some web servers such as Microsoft IIS still dutifully read the request-body according to the request-header’s instructions (the CodeRed worm exploited this very problem). The position of a malicious payload is determined by the exploited vulnerability. A malicious payload may be embedded in the Request-URI field as a query parameter. However, as the maximum length of Request-URI is limited, the size of a malicious payload, hence the behavior of such a buffer overflow attack, is constrained. It is more common that a buffer overflow attack payload is embedded in Request-Body of a POST method request. Technically, a malicious payload may also be embedded

in Request-Header, although this kind of attacks have not been observed yet. In this work, we assume an attacker can use any request method and embed the malicious code in any field.

4. URI decoder.

The specification for URLs limits the allowed characters in a Request-URI to only a subset of the ASCII character set. This means that the query parameters of a request-URI beyond this subset should

be encoded . Because a malicious payload may be embedded in the request-URI as a request parameter, the first step of SigFree is to decode the request-URI.

5. ASCII Filter.

Malicious executable code are normally binary strings. In order to guarantee the throughput and response time of the protected web system, if the query parameters of the request-URI and request-body of a request

are both printable ASCII ranging from 20-7E in hex, SigFree allows the request to pass  we will discuss a special type of executable codes called

alphanumeric shellcodes  that actually use printable ASCII) .

6. Instruction sequences distiller (ISD).

This module distills all possible instruction sequences from the query parameters of Request-URI and Request-Body (if the request

has one). Instruction sequences analyzer (ISA). Using all the instruction sequences distilled from the instruction sequences distiller as the inputs, thismodule analyzes these instruction sequences to determine whether one of them is (a fragment of) a program.

Hardware Requirements:

•         System                 : Pentium IV 2.4 GHz.

•         Hard Disk               : 40 GB.

•         Floppy Drive       : 1.44 Mb.

•         Monitor                 : 15 VGA Colour.

•         Mouse                  : Logitech.

•         Ram                        : 512 Mb.

Software Requirements:-

  •        Language:  Java / Dot Net
  •        OS: Windows XP

_Click Here To Download

Leave a Reply

Please Login to comment
Notify of