Editing Buffer overflow (section)

==Exploitation==

The techniques to [[exploit (computer security)|exploit]] a buffer overflow vulnerability vary by [[computer architecture|architecture]], [[operating system]], and memory region. For example, exploitation on the [[heap memory|heap]] (used for dynamically allocated memory), differs markedly from exploitation on the [[call stack]]. In general, heap exploitation depends on the heap manager used on the target system, while stack exploitation depends on the calling convention used by the architecture and compiler.

===Stack-based exploitation===
{{Main|Stack buffer overflow}}

There are several ways in which one can manipulate a program by exploiting stack-based buffer overflows:

* Changing program behavior by overwriting a local variable located near the vulnerable buffer on the stack;
* By overwriting the return address in a [[stack frame]] to point to code selected by the attacker, usually called the [[shellcode]]. Once the function returns, execution will resume at the attacker's shellcode;
* By overwriting a [[function pointer]]<ref>{{cite web |url=http://www.securityfocus.com/archive/1/462728/30/150/threaded |title=CORE-2007-0219: OpenBSD's IPv6 mbufs remote kernel buffer overflow |access-date=2007-05-15}}</ref> or [[exception handler]] to point to the shellcode, which is subsequently executed;
* By overwriting a local variable (or pointer) of a different stack frame, which will later be used by the function that owns that frame.<ref>{{cite web |url=http://packetstormsecurity.com/files/download/121751/ModernOverflowTargets.pdf |archive-url=https://ghostarchive.org/archive/20221009/http://packetstormsecurity.com/files/download/121751/ModernOverflowTargets.pdf |archive-date=2022-10-09 |url-status=live |title=Modern Overflow Targets |access-date=2013-07-05}}</ref>

The attacker designs data to cause one of these exploits, then places this data in a buffer supplied to users by the vulnerable code. If the address of the user-supplied data used to affect the stack buffer overflow is unpredictable, exploiting a stack buffer overflow to cause remote code execution becomes much more difficult. One technique that can be used to exploit such a buffer overflow is called "[[trampolining (computing)|trampolining]]". Here, an attacker will find a pointer to the vulnerable stack buffer and compute the location of their [[shellcode]] relative to that pointer. The attacker will then use the overwrite to jump to an [[Opcode|instruction]] already in memory which will make a second jump, this time relative to the pointer. That second jump will branch execution into the shellcode. Suitable instructions are often present in large code. The [[Metasploit Project]], for example, maintains a database of suitable opcodes, though it lists only those found in the [[Windows]] operating system.<ref>{{cite web|url=http://metasploit.com/users/opcode/msfopcode.cgi |title=The Metasploit Opcode Database |access-date=2007-05-15 |url-status=dead |archive-url=https://web.archive.org/web/20070512195939/http://www.metasploit.com/users/opcode/msfopcode.cgi |archive-date=12 May 2007 }}</ref>

===Heap-based exploitation===
{{Main|Heap overflow}}

A buffer overflow occurring in the heap data area is referred to as a heap overflow and is exploitable in a manner different from that of stack-based overflows. Memory on the heap is dynamically allocated by the application at run-time and typically contains program data. Exploitation is performed by corrupting this data in specific ways to cause the application to overwrite internal structures such as linked list pointers. The canonical heap overflow technique overwrites dynamic memory allocation linkage (such as [[malloc]] meta data) and uses the resulting pointer exchange to overwrite a program function pointer.

[[Microsoft]]'s [[Graphics Device Interface|GDI+]] vulnerability in handling [[JPEG]]s is an example of the danger a heap overflow can present.<ref>{{cite web |url=http://www.microsoft.com/technet/security/bulletin/MS04-028.mspx |title=Microsoft Technet Security Bulletin MS04-028 |website=[[Microsoft]] |access-date=2007-05-15 |archive-url=https://web.archive.org/web/20110804221311/http://www.microsoft.com/technet/security/bulletin/MS04-028.mspx |archive-date=2011-08-04 |url-status=dead }}</ref>

===Barriers to exploitation===

Manipulation of the buffer, which occurs before it is read or executed, may lead to the failure of an exploitation attempt. These manipulations can mitigate the threat of exploitation, but may not make it impossible. Manipulations could include conversion to upper or lower case, removal of [[metacharacter]]s and filtering out of non-[[alphanumeric]] strings. However, techniques exist to bypass these filters and manipulations, such as [[alphanumeric shellcode]], [[polymorphic code]], [[self-modifying code]], and [[return-to-libc attack]]s. The same methods can be used to avoid detection by [[intrusion detection system]]s. In some cases, including where code is converted into [[Unicode]],<ref>{{cite web |url=http://www.net-security.org/dl/articles/unicodebo.pdf |title=Creating Arbitrary Shellcode In Unicode Expanded Strings |access-date=2007-05-15 |url-status=dead |archive-url=https://web.archive.org/web/20060105041036/http://www.net-security.org/dl/articles/unicodebo.pdf |archive-date=2006-01-05 }}</ref> the threat of the vulnerability has been misrepresented by the disclosers as only Denial of Service when in fact the remote execution of arbitrary code is possible.

===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".