Buffer overflow is usually caused by the incorrect use of the data obtained from the outside and memory, in the absence of strict protection of the subsystem software compiler or interpreter and the operating system. As a result, the overflow can be corrupted data arranged behind buffer.
Buffer overflow is the most popular way to break into computer systems, since the majority of high-level languages ​​are mixed in a program memory and data, using the technology stack frame - the placement of data in the system stack, mixing program data with the control data (including the address of the start of stack frame and the return address).
Buffer overflows can cause a crash or hang of the program, leading to a denial of service (denial of service, DoS). Certain types of overflows, such as stack overflow in the frame, allow an attacker to download and execute arbitrary machine code in the name of the program and to the rights of the account under which it is performed.
Next, consider ways to transfer control to the prepared code. The basis of these techniques lies buffer overflows, ie a block of memory allocated for the variable. Overflow occurs when there is no check out the boundaries of the buffer. Thus, distorted the content of other state variables and parameters of the programs that are included in the overflow buffer.
Since the function call is accompanied by entry of the return address on the stack, then the substitution of his attackers, control is transferred to the address given to them. It uses a buffer overflow of local variables of the function, which is also created on the stack. A simple example is the following fragment of a C program.
int namelen (void) {
char name;
gets (name);
return strlen (name);
}
The example shows that when you enter a name larger than 20 characters part of the string will be replaced with the return address of the function. Further, the statement return from the subroutine, control is transferred to the address that form the respective positions of the input string in a normal situation would get an error message of the operating system.
Attacks aimed at buffer overflow lot, so urgent is the development of the script, which provides for vulnerabilities such as "buffer overflow."
Dangling pointer (DAP)
Uses of pointers to freed memory ("dangling pointer errors") are an important class of memory errors responsible for poor reliability of systems written in C/C++ languages.
These errors are often difficult and time consuming to find and diagnose during debugging.
File:Dangling Pointer.pdf
Furthermore, these dangling pointer errors can also be exploited in much the same way as buffer overruns to compromise system security. In fact, many exploits that take advantage of a subclass of these errors (double free vulnerabilities) in server programs have been reported in bugtraq (e.g., CVS server double free exploit, MIT Kerberos 5 double free exploit, MySQL double free vulnerability). Efficient detection of all such errors in servers during deployment (rather than just during development) is crucial for security. Unfortunately, detecting dangling pointer errors in programs has proven to be an extremely difficult problem. Detecting such errors statically in any precise manner is undecidable. Detecting them efficiently at run-time while still allowing safe reuse of memory can be very expensive and we do not know of any practical solution that has overheads low enough for use in production code. A number of approaches have been proposed that use some combination of static and run-time techniques to detect several kinds of memory errors, including buffer overflow errors and some dangling pointer errors. All of these techniques either have prohibitively high run-time overheads (2x - 100x) or memory overheads (or both) or are unsuitable for production software. Purify and Valgrind, two of the most widely used tools for debugging memory access errors, often have overheads in excess of 1000% and can sometimes be too slow even for debugging long-running programs. Moreover, most of these approaches (except FisherPatil, Xu et al and Electric Fence) employ only heuristics to detect dangling pointer errors and do not provide any guarantees about absence of such errors. FisherPatil and Xu et al, detect all dangling pointer errors but perform software run-time checks on all individual loads and stores, incurring overheads up to 300% and also causing substantial increases in virtual and physical memory consumption (1.6x-4x). Electric Fence uses page protection mechanisms to detect all dangling pointer errors but does so at the expense of several fold increase in virtual and physical memory consumption of the applications.
Security holes involving dangling pointers
Like buffer-overflow bugs, dangling/wild pointer bugs frequently become security holes. For example, if the pointer is used to make a virtual function call, a different address (possibly pointing at exploit code) may be called due to the vtable pointer being overwritten. Alternatively, if the pointer is used for writing to memory, some other data structure may be corrupted. Even if the memory is only read once the pointer becomes dangling, it can lead to information leaks (if interesting data is put in the next structure allocated there) or to privilege escalation (if the now-invalid memory is used in security checks).
Format string vulnerability
This type of security vulnerabilities occur because of a lack of control parameters when using the formatted input-output printf, fprintf, scanf, etc. C standard library. These functions take as one of the parameters of the character string that specifies the format of the input or output arguments to follow.
http://www.sans.org/security-resources/malwarefaq/images/LPRng_clip_image004.gif
If a user program can control the format string (for example, the format string is entered into the program by the user), it can generate it in a way that some memory locations (addresses which it can operate) will be recorded user-specified values, which opens up the possibility, for example, overwriting the return address of the function and performance of the code by the user.
Format string vulnerability arises, in fact, due to the fact that the widely used C programs function; interpret fairly powerful language, unlimited use of the opportunities which will lead to undesirable consequences. As a consequence, in a safe program should not be a format string, the contents of which are directly or indirectly dependent on the external to the program data. If this is not possible, when constructing the format string, it must be carefully checked. In the simplest case of a user input to "filter out" dangerous symbols "%" and "$".
