Buffer overflow: Difference between revisions

Revision as of 09:25, 27 February 2005

Latest revision as of 21:21, 8 August 2025

Line 1:

{{short description|Anomaly in computer security and programming}}

In [[computer programming]], a '''buffer overflow''' is an anomalous condition where a program somehow writes [[data]] beyond the allocated end of a [[buffer]] in [[computer storage|memory]]. Buffer overflows usually arise as a consequence of a [[computer bug|bug]] and the use of c or c++. One ramification of the overflow is that valid data can be overwritten as a result. Buffer overflows are also a commonly exploited [[computer security]] risk—since program control data often sits in the memory areas adjacent to data buffers, by means of a buffer overflow condition the computer can be made to execute arbitrary (and potentially malicious) code that is fed to the buggy program as data.

[[File:Buffer overflow basicexample.svg|thumb|Visualization of a software buffer overflow. Data is written into A, but is too large to fit within A, so it ''overflows'' into B.]]

In [[computer programming|programming]] and [[information security]], a '''buffer overflow''' or '''buffer overrun''' is an [[anomaly in software|anomaly]] whereby a [[computer program|program]] writes [[Data (computing)|data]] to a [[Data buffer|buffer]] beyond the buffer's [[Memory allocation|allocated memory]], overwriting adjacent [[Main memory|memory]] locations.

==Security ramifications==

A program which takes advantage of a vulnerability to subvert another program's security is called an [[exploit (computer science)|exploit]] and is usually intended to gain access to [[superuser]] or otherwise escalated privileges. A buffer overflow exploit works by feeding the program specially crafted input content which is designed to overflow the allocated data storage buffer and change the data that follows the buffer in [[computer storage|memory]].

Buffers are areas of memory set aside to hold data, often while moving it from one section of a program to another, or between programs. Buffer overflows can often be triggered by malformed inputs; if one assumes all inputs will be smaller than a certain size and the buffer is created to be that size, then an anomalous transaction that produces more data could cause it to write past the end of the buffer. If this overwrites adjacent data or executable code, this may result in erratic program behavior, including [[Memory fault|memory access errors]], incorrect results, and [[crash (computing)|crashes]].

For example, imagine a hypothetical program that executes with superuser privileges in order to perform some system administrative function such as changing a user password. If the program fails to ensure that the length of the new password entered is equal to or smaller than the data buffer allocated for its storage, then any overflow data will simply be written over whatever happens to be after the data buffer. If this post-buffer area is executable code, a malicious user can insert machine language instructions that can perform any function normally requiring root privileges — add users, delete users, change passwords, alter or delete any file, etc.

Exploiting the behavior of a buffer overflow is a well-known [[security exploit]]. On many systems, the memory layout of a program, or the system as a whole, is well defined. By sending in data designed to cause a buffer overflow, it is possible to write into areas known to hold [[execution (computing)|executable code]] and replace it with [[malicious code]], or to selectively overwrite data pertaining to the program's state, therefore causing behavior that was not intended by the original programmer. Buffers are widespread in [[operating system]] (OS) code, so it is possible to make attacks that perform [[privilege escalation]] and gain unlimited access to the computer's resources. The famed [[Morris worm]] in 1988 used this as one of its attack techniques.

Properly written programs ought to check the length of input data, to ensure that it is not larger than the allocated data buffer, but this is frequently overlooked, especially by novice programmers. Buffer overflows are most easily exploited when the data buffer is in the program [[Stack (computing)|stack]], since this can lead directly to an alteration of the program's execution path.

[[Programming language]]s commonly associated with buffer overflows include [[C (programming language)|C]] and [[C++]], which provide no built-in protection against accessing or overwriting data in any part of memory and do not automatically check that data written to an [[Array data structure|array]] (the built-in buffer type) is within the boundaries of that array. [[Bounds checking]] can prevent buffer overflows, but requires additional code and processing time. Modern operating systems use a variety of techniques to combat malicious buffer overflows, notably by [[Address space layout randomization|randomizing the layout of memory]], or deliberately leaving space between buffers and looking for actions that write into those areas ("[[Buffer overflow protection#Canaries|canaries]]").

Determining the [[exploitability]] of a buffer overflow vulnerability can be difficult even for experienced [[computer programmer|programmers]], since it involves a lot of high and low level knowledge of the [[computer architecture|architecture]] internals and the target program. Overflows of as little as a single byte beyond the end of a buffer have proved to be exploitable.

==Technical description==

Generally, the buffer overflow problem is caused by careless programming. Avoiding them is still a manual process as most [[formal verification]] systems have yet proven unattainable in modern programming languages. Buffer overflows are common only in programs written in relatively low-level programming languages, such as [[assembly language]], [[C programming language|C]], and [[C Plus Plus|C++]] which require the programmer to manually manage the size of allocated memory. Many programming languages such as [[Java programming language|Java]] and [[Lisp programming language|Lisp]] manage memory allocation automatically, and use a combination of [[run time checking]] and [[static analysis]] to make it difficult or impossible to code a buffer overflow bug. [[Perl]] provides for automatic resizing of the [[array]]s to avoid buffer overflows. However, runtime systems and libraries for such languages may still occasionally have buffer overflows due to internal implementation errors in these checking systems.

A buffer overflow occurs when [[data]] written to a buffer also corrupts data values in [[memory address]]es adjacent to the destination buffer due to insufficient [[bounds checking]].{{Ref RFC|4949|notes=no|rp=41}} This can occur when copying data from one buffer to another without first checking that the data fits within the destination buffer.

===Example===

==Technical rundown==

{{further|topic=stack-based overflows|Stack buffer overflow}}

===Description===

A more technical view of this would be best explained by using C or C++ as an example. This is based around [[x86]] architectures, but works for many others.

In the following example expressed in [[C (programming language)|C]], a program has two variables which are adjacent in memory: an 8-byte-long string buffer, A, and a two-byte [[big-endian]] integer, B.

Basically, when a dynamic buffer or '''automatic array''' is allocated in a function, it is allocated at function call time on the stack. Writing data to the buffer can write beyond it on the stack. Also, the stack grows from bottom up (or from right to left, depending on perspective). Here, (DATA) (DATA) (...) represents the existing stack, and (NEWDATA) is some new value the CPU has pushed onto the stack:

<syntaxhighlight lang="c">

(NEWDATA)(DATA)(DATA)(...)

char A[8] = "";

unsigned short B = 1979;

</syntaxhighlight>

Initially, A contains nothing but zero bytes, and B contains the number 1979.

When a C program executes a subroutine, it pushes the return address onto the stack, so the subroutine knows where to return control to when it has finished:

{| class="wikitable" style="width:32em; text-align:center;"

(ADDR)(DATA)(DATA)(...)

! style="white-space:nowrap;" | variable name

! colspan=8 style="background:#ddf;" | A

! colspan=2 style="background:#fdd;" | B

|- style="background:#ddf;"

! value

| colspan=8 | [<nowiki/>[[null string]]<nowiki/>]

| colspan=2 style="background:#fdd;" | 1979

|- style="background:#ddf;"

! hex value

| <kbd>00</kbd> || <kbd>00</kbd> || <kbd>00</kbd> || <kbd>00</kbd> || <kbd>00</kbd> || <kbd>00</kbd> || <kbd>00</kbd> || <kbd>00</kbd>

| style="background:#fdd;" | <kbd>07</kbd> || style="background:#fdd;" | <kbd>BB</kbd>

|}

Now, the program attempts to store the [[null-terminated string]] {{code|"excessive"}} with [[ASCII]] encoding in the A buffer.

When a dynamic buffer is allocated, the stack grows left by however big the buffer is. So, if a function starts with a 'char a[10]' declaration, the result is:

<syntaxhighlight lang="c">

strcpy(A, "excessive");

</syntaxhighlight>

{{code|"excessive"}} is 9 characters long and encodes to 10 bytes including the null terminator, but A can take only 8 bytes. By failing to check the length of the string, it also overwrites the value of B:

{| class="wikitable" style="width:32em; text-align:center;"

(a.........)(ADDR)(DATA)(DATA)(...)

! style="white-space:nowrap;" | variable name

! colspan=8 style="background:#ddf;" | A

! colspan=2 style="background:#fdd;" | B

|- style="background:#ddf;"

! value

| <kbd>'e'</kbd> || <kbd>'x'</kbd> || <kbd>'c'</kbd> || <kbd>'e'</kbd> || <kbd>'s'</kbd> || <kbd>'s'</kbd> || <kbd>'i'</kbd> || <kbd>'v'</kbd>

| colspan=2 style="background:#dbd;" | <kbd>25856</kbd>

|- style="background:#ddf;"

! hex

| <kbd>65</kbd> || <kbd>78</kbd> || <kbd>63</kbd> || <kbd>65</kbd> || <kbd>73</kbd> || <kbd>73</kbd> || <kbd>69</kbd> || <kbd>76</kbd>

| style="background:#dbd;" | <kbd>65</kbd> || style="background:#dbd;" | <kbd>00</kbd>

|}

B's value has now been inadvertently replaced by a number formed from part of the character string. In this example "e" followed by a zero byte would become 25856.

At the end of the function, the buffers are deallocated, everything pushed is popped, and a RET operation is called. This pops the return address off the stack and jumps there, shifting program control back to wherever the subroutine was called from.

Writing data past the end of allocated memory can sometimes be detected by the operating system to generate a [[segmentation fault]] error that terminates the process.

Suppose that 10 byte buffer is intended to hold user input (a new password, for example.) If the program fails to specifically check the number of characters the user has entered, and writes 14 bytes to the buffer, the extra data will clobber the return address, overwriting part of it with the extra data. This changes where program control will go to continue execution when the subroutine has finished.

To prevent the buffer overflow from happening in this example, the call to <kbd>[[strcpy]]</kbd> could be replaced with <kbd>[[strlcpy]]</kbd>, which takes the maximum capacity of A (including a null-termination character) as an additional parameter and ensures that no more than this amount of data is written to A:

If the user is not malicious and enters more than 10 characters, the extra data will effectively be random, and will probably end up making the return address point to an area in memory which is not under the control of the currently executing program, causing a [[segmentation fault]] on [[Unix]] architectures (or an analogous error on other operating systems) when the RET instruction attempts to jump control there.

<syntaxhighlight lang="c">

If a technically inclined user is malicious, they can ensure that the extra data does indeed point to a valid memory address, causing program control to be shifted to this ___location of their choosing, and potentially executing whatever arbitrary code the user has caused to be in that ___location with whatever privileges the currently executing program has.

strlcpy(A, "excessive", sizeof(A));

</syntaxhighlight>

When available, the <kbd>[[strlcpy]]</kbd> library function is preferred over <kbd>[[strncpy]]</kbd> which does not null-terminate the destination buffer if the source string's length is greater than or equal to the size of the buffer (the third argument passed to the function). Therefore <kbd>A</kbd> may not be null-terminated and cannot be treated as a valid C-style string.

===Example===

A practical example of a buffer overflow written in [[C programming language|C]] is:

==Exploitation==

#-------overflow.c

# Reads data from the command line and stores

# them in buffer

#

#include <stdio.h>

int main(int argc, char **argv)

{

char buffer[10];

if(argc<2)

{

printf("Usage: %s <characters>.\n", argv[0]);

exit(1);

}

strcpy(buffer,argv[1]);

printf("Characters typed: %s", buffer);

return(0);

}

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.

By executing that example in a [[Unix]]-compatible system, with an argument of 10 or less bytes, we have the following result:

===Stack-based exploitation===

poli@etacarinae:/tmp$ ./overflow Hello_World!

{{Main|Stack buffer overflow}}

Characters typed: Hello_World!

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

Now if the line contained more than 10 characters as the first argument, the following would result:

* Changing program behavior by overwriting a local variable located near the vulnerable buffer on the stack;

poli@etacarinae:/tmp$ ./overflow 12345678910111213141516171819

* 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;

Characters typed: 12345678910111213141516171819

* 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;

Segmentation fault

* 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>

The correction for the overflow in the previous example could be achieved by not using the [[strcpy]] function, but [[strncpy]] instead. The latter copies a fixed number of characters (in this example), avoiding the extra characters typed.

===Heap-based exploitation===

==Prevention==

{{Main|Heap overflow}}

Various techniques have been used to make buffer overflows less likely.

===Intrusion-detection software===

The use of [[Intrusion-detection system|Intrusion Detection Software]] can detect remote attempts to use buffer overflows. Since most buffer overflows contain a long [[array]] of [[instruction|instructions]] that have No OPeration ([[NOP|NOP's]]) or ([[NOOP|NOOP's]]), the IDS just has to block all incoming packets containing a large number of consecutive NOP's. Recently, crackers have begun to use [[alphanumeric code|alphanumeric]], [[polymorphic code|polymorphic]], and [[self-modifying code|self-modifying]] [[shellcode]]s to slip through these IDS systems.

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.

===Stack-smashing protection===

[[Stack-smashing protection]] is used to detect the most common buffer overflows by checking that the [[stack (computing)|stack]] has not been altered when a function returns. If it has been altered, the program exits with a [[segmentation fault]].

[[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>

Two such systems are [[StackGuard]] and [[ProPolice]], both of which are extensions to [[gcc]]. As of gcc-3.3.3, neither patch seems to have been incorporated into the mainline distribution. [[Gentoo Linux|Gentoo]] [[Linux]] and [[OpenBSD]] supply ProPolice by default with [[gcc]].

===Barriers to exploitation===

Putting the ''return address'' on the data stack makes it easy for a buffer overflow to lead to executing arbitrary code. In theory, gcc could be patched to place the return address on a ''return stack'' completely separate from the data stack, reminiscent of the [[Forth programming language]].

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.

See:

* [[Stack-Smashing Protector]] / [[Stack-smashing protection]]

* [http://research.avayalabs.com/project/libsafe/ Libsafe - Protecting Critical Elements of Stacks]

===ExecutablePracticalities spaceof protectionexploitation===

Protecting the executable space may soften the blow of buffer overflow exploits by making most of their operations impossible. This is done by randomizing the address space ([[ASLR]]) and making sure memory is not writable and executable. A non-executable stack will stave off most [[shellcode]] exploits.

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.

Two patches for the [[Linux kernel]] that accomplish this are [[PaX (Linux)|PaX]] and [[exec-shield]]. Neither of these are yet included in the mainstream kernel. [[OpenBSD]] since 3.3 has included a system called [[W xor X|W^X]], which provides executable space control as well.

====NOP sled technique====

Note that this manner of protection will ''not'' prevent stack smashing; however, it will often prevent the payload from being successfully delivered. The program will not be able to inject shellcode into non-writable memory, such as the existing code segments. It also will not be able to execute non-executable memory, such as the stack or the heap.

{{Main|NOP slide}}

[[ASLR]] will make [[ret2libc]] type attacks a very difficult guessing game. They are still possible in a controlled environment, or if the attacker guesses correctly.

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

Some CPUs such as Sun's Sparc, Transmeta's Efficeon, and newer 64-bit Intel and AMD x86 processors prevent code from being executed on areas of memory flagged with a special [[NX bit]].

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" />

===Use of safe libraries===

The problem of buffer overflows is commonly manifest in the [[C programming language|C]] and [[C Plus Plus|C++]] languages because they expose low level representational details of buffers as containers for datatypes. Buffer overflows are thus avoided by maintaining a high degree of correctness in code which performs buffer management. Well written and tested abstract data type libraries which centralize and automatically perform buffer management and include overflow testing is one engineering approach to mitigating the effect of buffer overflows. The two main building block data types in these languages in which buffer overflows are commonly manifest are strings and arrays, thus use of string and list-like data structure libraries which have been architected to avoid and/or detect buffer overflows provide the vast majority of the necessary coverage.

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

==Protective countermeasures==

Various techniques have been used to detect or prevent buffer overflows, with various tradeoffs. The following sections describe the choices and implementations available.

===Choice of programming language===

The choice of programming language can have a profound effect on the existence of buffer overflows. [[As of 2004]], the most popular languages generally are [[C programming language|C]] and its derivative, [[C Plus Plus|C++]]. Languages such as these do not check that data, when written to an array (the implementation of a buffer), is within the assumed boundaries of the array. Other programming languages differ in this regard, sending a warning or raising an [[exception]] when such a data assignment is made. Examples of such languages are [[Java programming language|Java]] and [[Pascal programming language|Pascal]] and its descendants such as [[Modula-2]], [[Oberon programming language|Oberon]], and [[Ada programming language|Ada]]; there are many other such languages. Part of the original rationale for choosing C is that it is "fast," in part because it does not take processor time to do such boundary checking; however, tests have shown that the amount of time added in checking array boundaries does not usually represent a burdensome overhead. In an era of fast processors (relative to the most common tasks, c. 2004), that original tradeoff of speed versus safety might be reconsidered. Such language features remain an ongoing debate among some within the software design community.

[[Assembly language|Assembly]], [[C (programming language)|C]], and [[C++]] are popular programming languages that are vulnerable to buffer overflow in part because they allow direct access to memory and are not [[strongly typed]].<ref name="OWASP">https://www.owasp.org/index.php/Buffer_OverflowsBuffer Overflows article on OWASP {{Webarchive|url=https://web.archive.org/web/20160829122543/https://www.owasp.org/index.php/Buffer_Overflows |date=2016-08-29 }}</ref> C provides no built-in protection against accessing or overwriting data in any part of memory. More specifically, it does not check that data written to a buffer is within the boundaries of that buffer. The standard C++ libraries provide many ways of safely buffering data, and C++'s [[Standard Template Library]] (STL) provides containers that can optionally perform bounds checking if the programmer explicitly calls for checks while accessing data. For example, a <code>vector</code>'s member function <code>at()</code> performs a bounds check and throws an <code>out_of_range</code> [[Exception handling|exception]] if the bounds check fails.<ref>{{cite web|url=http://www.cplusplus.com/reference/vector/vector/at/ |title=vector::at - C++ Reference |publisher=Cplusplus.com |access-date=2014-03-27}}</ref> However, C++ behaves just like C if the bounds check is not explicitly called. Techniques to avoid buffer overflows also exist for C.

Languages that are strongly typed and do not allow direct memory access, such as COBOL, Java, Eiffel, Python, and others, prevent buffer overflow in most cases.<ref name="OWASP"/> Many programming languages other than C or C++ provide runtime checking and in some cases even compile-time checking which might send a warning or raise an exception, while C or C++ would overwrite data and continue to execute instructions until erroneous results are obtained, potentially causing the program to crash. Examples of such languages include [[Ada (programming language)|Ada]], [[Eiffel (programming language)|Eiffel]], [[Lisp (programming language)|Lisp]], [[Modula-2]], [[Smalltalk]], [[OCaml]] and such C-derivatives as [[Cyclone (programming language)|Cyclone]], [[Rust (programming language)|Rust]] and [[D (programming language)|D]]. The [[Java (software platform)|Java]] and [[.NET Framework]] bytecode environments also require bounds checking on all arrays. Nearly every [[interpreted language]] will protect against buffer overflow, signaling a well-defined error condition. Languages that provide enough type information to do bounds checking often provide an option to enable or disable it. [[Static code analysis]] can remove many dynamic bound and type checks, but poor implementations and awkward cases can significantly decrease performance. Software engineers should carefully consider the tradeoffs of safety versus performance costs when deciding which language and compiler setting to use.

===Use of safe libraries===

The problem of buffer overflows is common in the C and C++ languages because they expose low level representational details of buffers as containers for data types. Buffer overflows can be avoided by maintaining a high degree of correctness in code that performs buffer management. It has also long been recommended to avoid standard library functions that are not bounds checked, such as <code>[[gets()|gets]]</code>, <code>[[scanf]]</code> and <code>[[strcpy]]</code>. The [[Morris worm]] exploited a <code>gets</code> call in [[fingerd]].<ref>{{cite web |url=http://wiretap.area.com/Gopher/Library/Techdoc/Virus/inetvir.823 |title=Archived copy |website=wiretap.area.com |access-date=6 June 2022 |archive-url=https://web.archive.org/web/20010505080457/http://wiretap.area.com/Gopher/Library/Techdoc/Virus/inetvir.823 |archive-date=5 May 2001 |url-status=dead}}</ref>

Well-written and tested abstract data type libraries that centralize and automatically perform buffer management, including bounds checking, can reduce the occurrence and impact of buffer overflows. The primary data types in languages in which buffer overflows are common are strings and arrays. Thus, libraries preventing buffer overflows in these data types can provide the vast majority of the necessary coverage. However, failure to use these safe libraries correctly can result in buffer overflows and other vulnerabilities, and naturally any [[Software bug|bug]] in the library is also a potential vulnerability. "Safe" library implementations include "The Better String Library",<ref>{{cite web |url=http://bstring.sf.net/ |title=The Better String Library}}</ref> Vstr<ref>{{cite web |url=http://www.and.org/vstr/ |title=The Vstr Homepage |access-date=2007-05-15 |archive-url=https://web.archive.org/web/20170305020810/http://www.and.org/vstr/ |archive-date=2017-03-05 |url-status=dead }}</ref> and Erwin.<ref>{{cite web |url=http://www.theiling.de/projects/erwin.html |title=The Erwin Homepage |access-date=2007-05-15}}</ref> The [[OpenBSD]] operating system's [[C library]] provides the [[strlcpy]] and [[strlcat]] functions, but these are more limited than full safe library implementations.

In September 2007, Technical Report 24731, prepared by the C standards committee, was published.<ref>{{Cite web|url=https://www.iso.org/obp/ui/#iso:std:iso-iec:tr:24731:-1:ed-2:v1:en:sec:4|title=Information technology – Programming languages, their environments and system software interfaces – Extensions to the C library – Part 1: Bounds-checking interfaces|last=International Organization for Standardization|date=2007|website=ISO Online Browsing Platform}}</ref> It specifies a set of functions that are based on the standard C library's string and IO functions, with additional buffer-size parameters. However, the efficacy of these functions for reducing buffer overflows is disputable. They require programmer intervention on a per function call basis that is equivalent to intervention that could make the analogous older standard library functions buffer overflow safe.<ref>{{cite web |url=https://www.securecoding.cert.org/confluence/x/QwY |archive-url=https://archive.today/20121228031633/https://www.securecoding.cert.org/confluence/x/QwY |url-status=dead |archive-date=December 28, 2012 |title=CERT Secure Coding Initiative |access-date=2007-07-30 }}</ref>

===Buffer overflow protection===

{{Main|Buffer overflow protection}}

Buffer overflow protection is used to detect the most common buffer overflows by checking that the [[call stack|stack]] has not been altered when a function returns. If it has been altered, the program exits with a [[segmentation fault]]. Three such systems are Libsafe,<ref>{{cite web |url=http://directory.fsf.org/libsafe.html |title=Libsafe at FSF.org |access-date=2007-05-20}}</ref> and the ''[[StackGuard]]''<ref>{{cite web |url=https://www.usenix.org/publications/library/proceedings/sec98/full_papers/cowan/cowan.pdf |archive-url=https://ghostarchive.org/archive/20221009/https://www.usenix.org/publications/library/proceedings/sec98/full_papers/cowan/cowan.pdf |archive-date=2022-10-09 |url-status=live |title=StackGuard: Automatic Adaptive Detection and Prevention of Buffer-Overflow Attacks by Cowan et al. |access-date=2007-05-20}}</ref> and ''[[ProPolice]]''<ref>{{cite web|url=http://wiki.x.org/wiki/ProPolice |title=ProPolice at X.ORG |access-date=2007-05-20 |url-status=dead |archive-url=https://web.archive.org/web/20070212032750/http://wiki.x.org/wiki/ProPolice |archive-date=12 February 2007 }}</ref> [[GNU Compiler Collection|gcc]] patches.

Microsoft's implementation of [[Data Execution Prevention]] (DEP) mode explicitly protects the pointer to the [[Structured Exception Handler]] (SEH) from being overwritten.<ref>{{cite web |url=http://www.uninformed.org/?v=2&a=4&t=txt |title=Bypassing Windows Hardware-enforced Data Execution Prevention |access-date=2007-05-20 |archive-url=https://web.archive.org/web/20070430040534/http://www.uninformed.org/?v=2&a=4&t=txt |archive-date=2007-04-30 |url-status=dead }}</ref>

Stronger stack protection is possible by splitting the stack in two: one for data and one for function returns. This split is present in the [[Forth language]], though it was not a security-based design decision. Regardless, this is not a complete solution to buffer overflows, as sensitive data other than the return address may still be overwritten.

This type of protection is also not entirely accurate because it does not detect all attacks. Systems like StackGuard are more centered around the behavior of the attacks, which makes them efficient and faster in comparison to range-check systems.<ref>{{Cite journal |last1=Lhee |first1=Kyung-Suk |last2=Chapin |first2=Steve J. |date=2003-04-25 |title=Buffer overflow and format string overflow vulnerabilities |url=https://onlinelibrary.wiley.com/doi/10.1002/spe.515 |journal=Software: Practice and Experience |language=en |volume=33 |issue=5 |pages=423–460 |doi=10.1002/spe.515 |issn=0038-0644|url-access=subscription }}</ref>

===Pointer protection===

Buffer overflows work by manipulating [[Pointer (computer programming)|pointers]], including stored addresses. PointGuard was proposed as a compiler-extension to prevent attackers from reliably manipulating pointers and addresses.<ref>{{cite web|url=http://www.usenix.org/events/sec03/tech/full_papers/cowan/cowan_html/index.html|title=12th USENIX Security Symposium – Technical Paper|website=www.usenix.org|access-date=3 April 2018}}</ref> The approach works by having the compiler add code to automatically XOR-encode pointers before and after they are used. Theoretically, because the attacker does not know what value will be used to encode and decode the pointer, one cannot predict what the pointer will point to if it is overwritten with a new value. PointGuard was never released, but Microsoft implemented a similar approach beginning in [[Windows XP]] SP2 and [[Windows Server 2003]] SP1.<ref>{{cite web|url=http://blogs.msdn.com/michael_howard/archive/2006/01/30/520200.aspx|title=Protecting against Pointer Subterfuge (Kinda!)|website=msdn.com|access-date=3 April 2018|archive-url=https://web.archive.org/web/20100502021754/http://blogs.msdn.com/michael_howard/archive/2006/01/30/520200.aspx|archive-date=2010-05-02|url-status=dead}}</ref> Rather than implement pointer protection as an automatic feature, Microsoft added an API routine that can be called. This allows for better performance (because it is not used all of the time), but places the burden on the programmer to know when its use is necessary.

Because XOR is linear, an attacker may be able to manipulate an encoded pointer by overwriting only the lower bytes of an address. This can allow an attack to succeed if the attacker can attempt the exploit multiple times or complete an attack by causing a pointer to point to one of several locations (such as any ___location within a NOP sled).<ref>{{cite web|url=http://www.usenix.org/publications/login/2005-06/pdfs/alexander0506.pdf |archive-url=https://ghostarchive.org/archive/20221009/http://www.usenix.org/publications/login/2005-06/pdfs/alexander0506.pdf |archive-date=2022-10-09 |url-status=live|title=USENIX - The Advanced Computing Systems Association|website=www.usenix.org|access-date=3 April 2018}}</ref> Microsoft added a random rotation to their encoding scheme to address this weakness to partial overwrites.<ref>{{cite web|url=http://blogs.msdn.com/michael_howard/archive/2006/08/16/702707.aspx|title=Protecting against Pointer Subterfuge (Redux)|website=msdn.com|access-date=3 April 2018|archive-url=https://web.archive.org/web/20091219202748/http://blogs.msdn.com/michael_howard/archive/2006/08/16/702707.aspx|archive-date=2009-12-19|url-status=dead}}</ref>

===Executable space protection===

{{Main|Executable space protection}}

Executable space protection is an approach to buffer overflow protection that prevents execution of code on the stack or the heap. An attacker may use buffer overflows to insert arbitrary code into the memory of a program, but with executable space protection, any attempt to execute that code will cause an exception.

Some CPUs support a feature called [[NX bit|NX]] ("No eXecute") or [[XD bit|XD]] ("eXecute Disabled") bit, which in conjunction with software, can be used to mark [[paging|pages of data]] (such as those containing the stack and the heap) as readable and writable but not executable.

Some Unix operating systems (e.g. [[OpenBSD]], [[macOS]]) ship with executable space protection (e.g. [[W^X]]). Some optional packages include:

* [[PaX]]<ref>{{cite web |title=PaX: Homepage of the PaX team |url=http://pax.grsecurity.net |access-date=2007-06-03}}</ref>

* [[Exec Shield]]<ref>{{cite web |title=KernelTrap.Org |url=http://kerneltrap.org/node/644 |access-date=2007-06-03 |url-status=dead |archive-url=https://archive.today/20120529183334/http://kerneltrap.org/node/644 |archive-date=2012-05-29 }}</ref>

* [[Openwall]]<ref>{{cite web |title=Openwall Linux kernel patch 2.4.34-ow1 |url=http://linux.softpedia.com/get/System/Operating-Systems/Kernels/Openwall-Linux-kernel-patch-16454.shtml |access-date=2007-06-03 |url-status=dead |archive-url=https://web.archive.org/web/20120219111512/http://linux.softpedia.com/get/System/Operating-Systems/Kernels/Openwall-Linux-kernel-patch-16454.shtml |archive-date=2012-02-19 }}</ref>

Newer variants of Microsoft Windows also support executable space protection, called [[Data Execution Prevention]].<ref>{{cite web |title=Microsoft Technet: Data Execution Prevention |url=http://technet2.microsoft.com/WindowsServer/en/Library/b0de1052-4101-44c3-a294-4da1bd1ef2271033.mspx?mfr=true |access-date=2006-06-30 |archive-url=https://web.archive.org/web/20060622140239/http://technet2.microsoft.com/WindowsServer/en/Library/b0de1052-4101-44c3-a294-4da1bd1ef2271033.mspx?mfr=true |archive-date=2006-06-22 |url-status=dead }}</ref> [[proprietary software|Proprietary]] add-ons include:

* BufferShield<ref>{{cite web |title=BufferShield: Prevention of Buffer Overflow Exploitation for Windows |url=http://www.sys-manage.com/english/products/products_BufferShield.html |access-date=2007-06-03}}</ref>

* StackDefender<ref>{{cite web |title=NGSec Stack Defender |url=http://www.ngsec.com/ngproducts/stackdefender/ |access-date=2007-06-03 |archive-url = https://web.archive.org/web/20070513235539/http://www.ngsec.com/ngproducts/stackdefender/ <!-- Bot retrieved archive --> |archive-date = 2007-05-13}}</ref>

Executable space protection does not generally protect against [[return-to-libc attack]]s, or any other attack that does not rely on the execution of the attackers code. However, on [[64-bit]] systems using [[ASLR]], as described below, executable space protection makes it far more difficult to execute such attacks.

===Capability Hardware Enhanced RISC Instructions===

{{Main|Capability Hardware Enhanced RISC Instructions}}

CHERI (Capability Hardware Enhanced RISC Instructions) is a computer processor technology designed to improve security. It operates at a hardware level by providing a hardware-enforced type (a CHERI capability) that authorises access to memory. Traditional pointers are replaced by addresses accompanied by metadata that limit what can be accessed through any given pointer.

===Address space layout randomization===

{{Main|Address space layout randomization}}

Address space layout randomization (ASLR) is a computer security feature that involves arranging the positions of key data areas, usually including the base of the executable and position of libraries, heap, and stack, randomly in a process' address space.

Randomization of the [[virtual memory]] addresses at which functions and variables can be found can make exploitation of a buffer overflow more difficult, but not impossible. It also forces the attacker to tailor the exploitation attempt to the individual system, which foils the attempts of [[internet worm]]s.<ref>{{cite web |title=PaX at GRSecurity.net |url=http://pax.grsecurity.net/docs/aslr.txt |access-date=2007-06-03}}</ref> A similar but less effective method is to [[rebasing|rebase]] processes and libraries in the virtual address space.

===Deep packet inspection===

{{Main|Deep packet inspection}}

The use of deep packet inspection (DPI) can detect, at the network perimeter, very basic remote attempts to exploit buffer overflows by use of attack signatures and [[heuristic (computer science)|heuristics]]. This technique can block packets that have the signature of a known attack. It was formerly used in situations in which a long series of No-Operation instructions (known as a NOP-sled) was detected and the ___location of the exploit's [[payload (software)|payload]] was slightly variable.

Packet scanning is not an effective method since it can only prevent known attacks and there are many ways that a NOP-sled can be encoded. [[Shellcode]] used by attackers can be made [[alphanumeric]], [[metamorphic code|metamorphic]], or [[self-modifying code|self-modifying]] to evade detection by heuristic packet scanners and [[intrusion detection system]]s.

=== Testing ===

Checking for buffer overflows and patching the bugs that cause them helps prevent buffer overflows. One common automated technique for discovering them is [[fuzzing]].<ref>{{cite web|url=http://raykoid666.wordpress.com|title=The Exploitant - Security info and tutorials|access-date=2009-11-29}}</ref> Edge case testing can also uncover buffer overflows, as can static analysis.<ref>{{Cite journal|last1=Larochelle|first1=David|last2=Evans|first2=David|date=13 August 2001|title=Statically Detecting Likely Buffer Overflow Vulnerabilities|url=https://www.usenix.org/legacy/events/sec01/full_papers/larochelle/larochelle_html/|journal=USENIX Security Symposium|volume=32}}</ref> Once a potential buffer overflow is detected it should be patched. This makes the testing approach useful for software that is in development, but less useful for legacy software that is no longer maintained or supported.

==History==

In [[1988]], the [[Morris worm]] used a buffer overflow in a [[Unix]] program called [[finger protocol|finger]] to propagate itself over the [[Internet]]. Even after this incident, buffer overflows were virtually ignored as security issue. Later, in [[1995]], [[Thomas Lopatic]] independently reinvented the buffer overflow and published his findings on the [[Bugtraq]] security mailing list, which caused a wave of new security relevant buffer overflows to be found. In [[1996]], [[Elias Levy]] (aka Aleph One) published in ''[[Phrack]]'' magazine the paper "Smashing the Stack for Fun and Profit", a step-by-step introduction to exploiting stack-based buffer overflow vulnerabilities, which caused a wave of new buffer overflow exploits to be written.

Buffer overflows were understood and partially publicly documented as early as 1972, when the Computer Security Technology Planning Study laid out the technique: "The code performing this function does not check the source and destination addresses properly, permitting portions of the monitor to be overlaid by the user. This can be used to inject code into the monitor that will permit the user to seize control of the machine."<ref>{{cite web |title=Computer Security Technology Planning Study |page=61 |url=http://csrc.nist.gov/publications/history/ande72.pdf |access-date=2007-11-02 |archive-url=https://web.archive.org/web/20110721060319/http://csrc.nist.gov/publications/history/ande72.pdf |archive-date=2011-07-21 |url-status=dead}}</ref> Today, the monitor would be referred to as the kernel.

The earliest documented hostile exploitation of a buffer overflow was in 1988. It was one of several exploits used by the [[Morris worm]] to propagate itself over the Internet. The program exploited was a [[Service (systems architecture)|service]] on [[Unix]] called [[Finger protocol|finger]].<ref>{{cite web |title="A Tour of The Worm" by Donn Seeley, University of Utah |url=http://world.std.com/~franl/worm.html |access-date=2007-06-03 |archive-url=https://web.archive.org/web/20070520233435/http://world.std.com/~franl/worm.html <!-- Bot retrieved archive --> |archive-date=2007-05-20}}</ref> Later, in 1995, Thomas Lopatic independently rediscovered the buffer overflow and published his findings on the [[Bugtraq]] security mailing list.<ref>{{cite web |title=Bugtraq security mailing list archive |url=http://www.security-express.com/archives/bugtraq/1995_1/0403.html |access-date=2007-06-03 |archive-url=https://web.archive.org/web/20070901222723/http://www.security-express.com/archives/bugtraq/1995_1/0403.html <!-- Bot retrieved archive --> |archive-date=2007-09-01}}</ref> A year later, in 1996, [[Elias Levy]] (also known as Aleph One) published in ''[[Phrack]]'' magazine the paper "Smashing the Stack for Fun and Profit",<ref>{{cite web |title="Smashing the Stack for Fun and Profit" by Aleph One |url=https://phrack.org/issues/49/14 |access-date=2025-03-06}}</ref> a step-by-step introduction to exploiting stack-based buffer overflow vulnerabilities.

Since then, at least two major internet worms have exploited buffer overflows to compromise a large number of systems. In 2001, the [[Code Red worm]] exploited a buffer overflow in Microsoft's [[Internet Information Services]] (IIS) 5.0<ref>{{cite web |title=eEye Digital Security |url=http://research.eeye.com/html/advisories/published/AL20010717.html |access-date=2007-06-03 |archive-date=2009-06-20 |archive-url=https://web.archive.org/web/20090620085700/http://research.eeye.com/html/advisories/published/AL20010717.html |url-status=dead }}</ref> and in 2003 the [[SQL Slammer]] worm compromised machines running [[Microsoft SQL Server 2000]].<ref>{{cite web |title=Microsoft Technet Security Bulletin MS02-039 |website=[[Microsoft]] |url=http://www.microsoft.com/technet/security/bulletin/ms02-039.mspx |access-date=2007-06-03 |archive-url=https://web.archive.org/web/20080307052903/http://www.microsoft.com/technet/security/bulletin/ms02-039.mspx |archive-date=2008-03-07 |url-status=dead}}</ref>

In 2003, buffer overflows present in licensed [[Xbox (console)|Xbox]] games have been exploited to allow unlicensed software, including [[homebrew (video games)|homebrew games]], to run on the console without the need for hardware modifications, known as [[modchip]]s.<ref>{{cite web |url=http://www.gamesindustry.biz/content_page.php?aid=1461 |archive-url=https://web.archive.org/web/20070927210513/http://www.gamesindustry.biz/content_page.php?aid=1461 |archive-date=2007-09-27 |title=Hacker breaks Xbox protection without mod-chip |access-date=2007-06-03}}</ref> The [[PS2 Independence Exploit]] also used a buffer overflow to achieve the same for the [[PlayStation 2]]. The Twilight hack accomplished the same with the [[Wii]], using a buffer overflow in ''[[The Legend of Zelda: Twilight Princess]]''.

==See also==

*[[Buffer management]]

{{colbegin|colwidth=20em}}

*[[computer security]]

* [[heapBillion overflowlaughs]]

* [[MemoryBuffer debuggerover-read]]

* [[PointerCoding swizzlingconventions]]

* [[Computer security]]

*[[Secure operating systems]]

* [[End-of-file]]

*[[Security focused operating systems]]

* [[shellcodeHeap overflow]]s

* [[SoftwarePing of testingdeath]]

* [[SPlintPort scanner]]

* [[Static codeReturn-to-libc analysisattack]]

* [[Safety-critical system]]

*[[strcpy]]

* [[Security-focused operating system]]

*[[strcat]]

* [[Self-modifying code]]

* [[Software quality]]

* [[Shellcode]]

* [[Stack buffer overflow]]

* [[Uncontrolled format string]]

{{colend}}

==References==

{{Reflist|30em|refs=

<ref name="neworder">{{cite journal|author=Vangelis |title=Stack-based Overflow Exploit: Introduction to Classical and Advanced Overflow Technique |publisher=Wowhacker via Neworder |date=2004-12-08 |url=http://www.neworder.box.sk/newsread.php?newsid=12476 |format=text |url-status=dead |archive-url=https://web.archive.org/web/20070818115455/http://www.neworder.box.sk/newsread.php?newsid=12476 |archive-date=August 18, 2007 }}</ref>

<ref name="enderunix">{{cite journal

| last = Balaban

| first = Murat

| title = Buffer Overflows Demystified

| publisher = Enderunix.org

| url = http://www.enderunix.org/docs/en/bof-eng.txt

| archive-url = https://web.archive.org/web/20040812221752/http://enderunix.org/docs/en/bof-eng.txt

| url-status = usurped

| archive-date = August 12, 2004

| format = text }}</ref>

<ref name="Akritidis1">{{cite conference

|first = P.

|last = Akritidis

|author2 = Evangelos P. Markatos

|author3 = M. Polychronakis

|author4 = Kostas D. Anagnostakis

|title = STRIDE: Polymorphic Sled Detection through Instruction Sequence Analysis.

|book-title = Proceedings of the 20th IFIP International Information Security Conference (IFIP/SEC 2005)

|publisher = IFIP International Information Security Conference

|year = 2005

|url = http://dcs.ics.forth.gr/Activities/papers/stride-IFIP-SEC05.pdf

|access-date = 2012-03-04

|archive-url = https://web.archive.org/web/20120901034404/http://dcs.ics.forth.gr/Activities/papers/stride-IFIP-SEC05.pdf

|archive-date = 2012-09-01

|url-status = dead

}}</ref>

<ref name="klein1">{{cite journal

|last = Klein

|first = Christian

|title = Buffer Overflow

|date = September 2004

|url = http://c0re.23.nu/~chris/presentations/overflow2005.pdf

|url-status = dead

|archive-url = https://web.archive.org/web/20070928011639/http://c0re.23.nu/~chris/presentations/overflow2005.pdf

|archive-date = 2007-09-28

}}</ref>

<ref name="shah">{{cite conference

| first = Saumil

| last = Shah

| title = Writing Metasploit Plugins: from vulnerability to exploit

| book-title = Hack In The Box

| year = 2006

| ___location = Kuala Lumpur

| url = http://conference.hitb.org/hitbsecconf2006kl/materials/DAY%201%20-%20Saumil%20Shah%20-%20Writing%20Metasploit%20Plugins.pdf

| access-date = 2012-03-04 }}</ref>

<ref name="intel1">{{cite book

| title = Intel 64 and IA-32 Architectures Software Developer's Manual Volume 2A: Instruction Set Reference, A-M

| publisher = Intel Corporation

| date = May 2007

| archive-date = 2007-11-29

| pages = 3–508

| url = http://developer.intel.com/design/processor/manuals/253666.pdf

| archive-url = https://web.archive.org/web/20071129123212/http://developer.intel.com/design/processor/manuals/253666.pdf }}</ref>

<ref name="packetstorm1">{{cite journal

| last = Alvarez

| first = Sergio

| title = Win32 Stack BufferOverFlow Real Life Vuln-Dev Process

| publisher = IT Security Consulting

| date = 2004-09-05

| url = http://packetstormsecurity.org/papers/Win2000/Intro_to_Win32_Exploits.pdf

| access-date = 2012-03-04

}}</ref>

<ref name="Yuji1">

{{cite conference

| first = Yuji

| last = Ukai |author2=Soeder, Derek |author3=Permeh, Ryan

| title = Environment Dependencies in Windows Exploitation

| book-title = BlackHat Japan

| publisher = eEye Digital Security

| year = 2004

| ___location = Japan

| url = https://www.blackhat.com/presentations/bh-asia-04/bh-jp-04-ukai-eng.ppt

| access-date = 2012-03-04 }}</ref>}}

==External links==

* [https://raykoid666.wordpress.com/2009/11/28/remote-buffer-overflow-from-vulnerability-to-exploit-part-1/ "Discovering and exploiting a remote buffer overflow vulnerability in an FTP server"] by Raykoid666

*[http://www.sans.org/rr/paper.php?id=386 SANS: inside the buffer overflow attack]

* [https://www.phrack.org/issues/49/14.html#article "Smashing the Stack for Fun and Profit"] by Aleph One

*[http://www.dwheeler.com/secure-programs/Secure-Programs-HOWTO/buffer-overflow.html Secure Programming for Linux and Unix HOWTO: Avoid Buffer Overflow] by [[David A. Wheeler]]

* {{cite journal | url=https://iac.dtic.mil/iatac/download/Vol7_No4.pdf | date=2005-05-02 | archive-url=https://web.archive.org/web/20060927225105/https://iac.dtic.mil/iatac/download/Vol7_No4.pdf | archive-date=2006-09-27 | url-status=dead | title=An Overview and Example of the Buffer-Overflow Exploit | pages=16–21 | volume=7 | issue=4 | journal=IAnewsletter | publisher=[[Information Assurance Technology Analysis Center]] | access-date=2019-03-17 | first=Isaac | last=Gerg }}

*[http://www-106.ibm.com/developerworks/linux/library/l-sp4.html Secure programmer: Countering buffer overflows]

* [https://www.securecoding.cert.org/ CERT Secure Coding Standards]

*[http://www.phrack.org/phrack/49/P49-14 Smashing The Stack For Fun And Profit] by Aleph One

* [https://www.cert.org/secure-coding CERT Secure Coding Initiative]

*[http://www.cse.ogi.edu/~crispin "Buffer Overflows: Attacks and Defenses for the Vulnerability of the Decade"] by Crispin Cowan, Perry Wagle, Calton Pu, Steve Beattie, and Jonathan Walpole discusses the Stackguard approach to countering stack-smashing attacks.

* [https://www.cert.org/books/secure-coding Secure Coding in C and C++]

* [https://www.sans.org/reading_room/whitepapers/securecode/386.php SANS: inside the buffer overflow attack]

* [https://web.archive.org/web/20130126024851/https://www.awarenetwork.org/etc/alpha/?x=5 "Advances in adjacent memory overflows"] by Nomenumbra

* [https://www.blackhat.com/presentations/bh-usa-04/bh-us-04-silberman/bh-us-04-silberman-paper.pdf A Comparison of Buffer Overflow Prevention Implementations and Weaknesses]

* [https://web.archive.org/web/20090817230359/https://doc.bughunter.net/buffer-overflow/ More Security Whitepapers about Buffer Overflows]

* [https://web.archive.org/web/20071129123212/https://www.syngress.com/book_catalog/327_SSPC/sample.pdf Chapter 12: Writing Exploits III] from ''Sockets, Shellcode, Porting & Coding: Reverse Engineering Exploits and Tool Coding for Security Professionals'' by James C. Foster ({{ISBN|1-59749-005-9}}). Detailed explanation of how to use Metasploit to develop a buffer overflow exploit from scratch.

* [https://web.archive.org/web/20110721060319/https://csrc.nist.gov/publications/history/ande72.pdf Computer Security Technology Planning Study], James P. Anderson, ESD-TR-73-51, ESD/AFSC, Hanscom AFB, Bedford, MA 01731 (October 1972) [NTIS AD-758 206]

* [https://web.archive.org/web/20170905183149/https://www.exploit-db.com/docs/18346.pdf "Buffer Overflows: Anatomy of an Exploit"] by Nevermore

* [https://www.cansecwest.com/csw08/csw08-holtmann.pdf Secure Programming with GCC and GLibc] {{Webarchive|url=https://web.archive.org/web/20081121103054/https://cansecwest.com/csw08/csw08-holtmann.pdf |date=2008-11-21 }} (2008), by Marcel Holtmann

* [https://www.helviojunior.com.br/it/security/criacao-de-exploits/criacao-de-exploits-parte-0-um-pouco-de-teoria/ "Criação de Exploits com Buffer Overflor – Parte 0 – Um pouco de teoria "] (2018), by Helvio Junior (M4v3r1ck)

{{Memory management navbox}}

{{Authority control}}

[[Category:Programming]]

[[Category:Software]]

[[Category:Security exploits]]

{{DEFAULTSORT:Buffer Overflow}}

[[de:Pufferüberlauf]]

[[Category:Software bugs]]

[[es:Buffer overflow]]

[[Category:Computer memory]]

[[fr:Dépassement de tampon]]

[[Category:Computer security exploits]]

[[it:Buffer overflow]]

[[Category:Articles with example C code]]

[[ja:&#12496;&#12483;&#12501;&#12449;&#12458;&#12540;&#12496;&#12540;&#12521;&#12531;]]

[[pl:Buffer overflow]]

[[fi:Puskurin ylivuoto]]