Best fashion Buffer Overflow target (1)

Best fashion Buffer Overflow target (1)

Original article: Modern Overflow Targets By Eric Wimberley, Nathan Harrison

In today's operating systems, memory defect vulnerabilities have become increasingly difficult to mine, and stack protection measures have made the original Buffer Overflow exploitation method (writing NOP blocks and shellcode into the buffer zone, overwrite the IP address pointed to by the EIP with the address in the buffer zone. Without some degree of information leakage, under the dual protection of address space distribution randomization (ASLR) and stack cookies, in fact, it is difficult to execute effective overflow attacks on remote systems using traditional methods.

However, there is still a stack input/output vulnerability that can be exploited. This article describes some common Buffer Overflow technologies that do not trigger the _ stack_chk_fail protection of stacks, or are at least valid so far. In this article, we will not use the new technology to modify the execution process of the program by modifying the EIP, but concentrate on a series of new goals. At the same time, this article will also discuss the function safety mode (function safety model) not found in GCC 4.6 and earlier versions in any document ).

Exceptions recorded by GCC ProPolice

According to the ProPolice document of the function security model, the following situations are not protected:

◆ Structures that cannot be re-sorted and pointers in functions are insecure.

◆ It is unsafe to use pointer variables as parameters.

◆ It is insecure to dynamically allocate string space.

◆ The function that calls the trampoline code is insecure.

In addition, we also find that the following situations are insecure:

◆ If more than one cache is defined in the function and is not correctly sorted, at least one cache may be modified and disturbed before reference.

◆ The pointer or primitive in the parameter list may be modified but referenced before canary detection.

◆ Any struct primitive or cache may be modified before reference (including stack objects in C ++ ).

◆ The pointer to the variable in the lower address of the stack frame is insecure, because the data may be overwritten before being referenced. Here we are no longer limited to local variables, pointers (such as function pointers), and caches in the current stack frame.

In IBM's document on function security models, it is assumed that the attack types are traditional stack overflow methods. It is declared in the document that the data after the canary stack is safe after the function is returned, and this is true. However, the problem is that the data may not be safe before the function returns. Even in different stack frames, the pointer to the stack's high address is easily rewritten.