Editing Buffer overflow (section)

===Practicalities of exploitation===

In real-world exploits there are a variety of challenges which need to be overcome for exploits to operate reliably. These factors include null bytes in addresses, variability in the location of shellcode, differences between environments, and various counter-measures in operation.

====NOP sled technique====

{{Main|NOP slide}}

[[File:nopsled.svg|right|thumb|200px|Illustration of a NOP-sled payload on the stack.]]

A NOP-sled is the oldest and most widely known technique for exploiting stack buffer overflows.<ref name="neworder" /> It solves the problem of finding the exact address of the buffer by effectively increasing the size of the target area. To do this, much larger sections of the stack are corrupted with the [[no-op]] machine instruction. At the end of the attacker-supplied data, after the no-op instructions, the attacker places an instruction to perform a relative jump to the top of the buffer where the [[shellcode]] is located. This collection of no-ops is referred to as the "NOP-sled" because if the return address is overwritten with any address within the no-op region of the buffer, the execution will "slide" down the no-ops until it is redirected to the actual malicious code by the jump at the end. This technique requires the attacker to guess where on the stack the NOP-sled is instead of the comparatively small shellcode.<ref name="enderunix" />

Because of the popularity of this technique, many vendors of [[intrusion prevention system]]s will search for this pattern of no-op machine instructions in an attempt to detect shellcode in use. A NOP-sled does not necessarily contain only traditional no-op machine instructions. Any instruction that does not corrupt the machine state to a point where the shellcode will not run can be used in place of the hardware assisted no-op. As a result, it has become common practice for exploit writers to compose the no-op sled with randomly chosen instructions which will have no real effect on the shellcode execution.<ref name="Akritidis1" />

While this method greatly improves the chances that an attack will be successful, it is not without problems. Exploits using this technique still must rely on some amount of luck that they will guess offsets on the stack that are within the NOP-sled region.<ref name="klein1" /> An incorrect guess will usually result in the target program crashing and could alert the [[system administrator]] to the attacker's activities. Another problem is that the NOP-sled requires a much larger amount of memory in which to hold a NOP-sled large enough to be of any use. This can be a problem when the allocated size of the affected buffer is too small and the current depth of the stack is shallow (i.e., there is not much space from the end of the current stack frame to the start of the stack). Despite its problems, the NOP-sled is often the only method that will work for a given platform, environment, or situation, and as such it is still an important technique.

====The jump to address stored in a register technique====

The "jump to register" technique allows for reliable exploitation of stack buffer overflows without the need for extra room for a NOP-sled and without having to guess stack offsets. The strategy is to overwrite the return pointer with something that will cause the program to jump to a known pointer stored within a register which points to the controlled buffer and thus the shellcode. For example, if register A contains a pointer to the start of a buffer then any jump or call taking that register as an operand can be used to gain control of the flow of execution.<ref name="shah" /> [[File:jumpToEsp.png|left|thumb|300px|An instruction from ntdll.dll to call the <code>DbgPrint()</code> routine contains the [[i386]] machine opcode for <code>jmp esp</code>.]]

In practice a program may not intentionally contain instructions to jump to a particular register. The traditional solution is to find an unintentional instance of a suitable [[opcode]] at a fixed location somewhere within the program memory. Figure [[:Image:JumpToEsp.png|E]] on the left contains an example of such an unintentional instance of the i386 <code>jmp esp</code> instruction. The opcode for this instruction is <code>FF E4</code>.<ref name="intel1" /> This two-byte sequence can be found at a one-byte offset from the start of the instruction <code>call DbgPrint</code> at address <code>0x7C941EED</code>. If an attacker overwrites the program return address with this address the program will first jump to <code>0x7C941EED</code>, interpret the opcode <code>FF E4</code> as the <code>jmp esp</code> instruction, and will then jump to the top of the stack and execute the attacker's code.<ref name="packetstorm1" />

When this technique is possible the severity of the vulnerability increases considerably. This is because exploitation will work reliably enough to automate an attack with a virtual guarantee of success when it is run. For this reason, this is the technique most commonly used in [[Internet worm]]s that exploit stack buffer overflow vulnerabilities.<ref name="Yuji1" />

This method also allows shellcode to be placed after the overwritten return address on the [[Microsoft Windows|Windows]] platform. Since executables are mostly based at address <code>0x00400000</code> and x86 is a [[little endian]] architecture, the last byte of the return address must be a null, which terminates the buffer copy and nothing is written beyond that. This limits the size of the shellcode to the size of the buffer, which may be overly restrictive. [[Dynamic-link library|DLLs]] are located in high memory (above <code>0x01000000</code>) and so have addresses containing no null bytes, so this method can remove null bytes (or other disallowed characters) from the overwritten return address. Used in this way, the method is often referred to as "DLL trampolining".