Buffer overflow protection: Difference between revisions

Revision as of 09:52, 29 November 2019

Revision as of 09:53, 29 November 2019

Line 1:

'''Buffer overflow protection''' is any of various techniques used during software development to enhance the security of executable programs by detecting [[buffer overflow]]s on [[call stack|stack]]-allocated variables, and preventing them from causing program misbehavior or from becoming serious [[computer security|security]] vulnerabilities. A stack buffer overflow occurs when a program writes to a memory address on the program's call stack outside of the intended data structure, which is usually a fixed-length buffer. Stack buffer overflow bugs are caused when a program writes more data to a buffer located on the stack than what is actually allocated for that buffer. This almost always results in corruption of adjacent data on the stack, which could lead to program crashes, incorrect operation, or security issues.

Typically, buffer overflow protection modifies the organization of stack-allocated data so it includes a ''[[stack canary|canary]]'' value that, when destroyed by a stack buffer overflow, shows that a buffer preceding it in memory has been overflowed. By verifying the canary value, execution of the affected program can be terminated, preventing it from misbehaving or from allowing an attacker to take control over it. Other buffer overflow protection techniques include ''[[bounds checking]]'', which checks accesses to each allocated block of memory so they cannot go beyond the actually allocated space, and ''tagging'', which ensures that memory allocated for storing data cannot contain executable code.

Overfilling a buffer allocated on the stack is more likely to influence program execution than overfilling a buffer on the [[dynamic memory allocation|heap]] because the stack contains the return addresses for all active function calls. However, similar implementation-specific protections also exist against heap-based overflows.

There are several implementations of buffer overflow protection, including those for the [[GNU Compiler Collection]], [[LLVM]], [[Microsoft Visual Studio]], and other compilers.

==Overview==

{{Main|Stack buffer overflow}}

A stack buffer overflow occurs when a program writes to a memory address on the program's [[call stack]] outside of the intended data structure, which is usually a fixed-length buffer. Stack buffer overflow bugs are caused when a program writes more data to a buffer located on the stack than what is actually allocated for that buffer. This almost always results in corruption of adjacent data on the stack, and in cases where the overflow was triggered by mistake, will often cause the program to crash or operate incorrectly. Stack buffer overflow is a type of the more general programming malfunction known as [[buffer overflow]] (or buffer overrun). Overfilling a buffer on the stack is more likely to derail program execution than overfilling a buffer on the heap because the stack contains the return addresses for all active function calls.<ref>{{cite web |last=Fithen |first=William L. |last2=Seacord |first2=Robert |publisher=[[US CERT]] |title=VT-MB. Violation of Memory Bounds |url=https://www.securecoding.cert.org/confluence/display/sci/VT-MB.+Violation+of+Memory+Bounds |date=2007-03-27 }}</ref>

Stack buffer overflow can be caused deliberately as part of an attack known as [[stack smashing]]. If the affected program is running with special privileges, or if it accepts data from untrusted network hosts (for example, a public [[webserver]]), then the bug is a potential security vulnerability that allows an [[hacker (computer security)|attacker]] to inject executable code into the running program and take control of the process. This is one of the oldest and more reliable methods for attackers to gain unauthorized access to a computer.<ref>{{cite journal |last=Levy |first=Elias |authorlink=Elias Levy |title=Smashing The Stack for Fun and Profit |journal=[[Phrack]] |volume=7 |issue=49 |page=14 |date=1996-11-08 |url=http://www.phrack.org/issues/49/14.html#article }}</ref>

Typically, buffer overflow protection modifies the organization of data in the [[stack frame]] of a [[function call]] to include a "canary" value that, when destroyed, shows that a buffer preceding it in memory has been overflowed. This provides the benefit of preventing an entire class of attacks. According to some researchers,<ref>{{cite web|url=http://tmp-www.cpe.ku.ac.th/~mcs/courses/2005_02/214573/papers/buffer_overflows.pdf |title=Buffer Overflows: Attacks and Defenses for the Vulnerability of the Decade* |url-status=dead |archiveurl=https://web.archive.org/web/20130309083252/http://tmp-www.cpe.ku.ac.th/~mcs/courses/2005_02/214573/papers/buffer_overflows.pdf |archivedate=2013-03-09 }}</ref> the performance impact of these techniques is negligible.

Stack-smashing protection is unable to protect against certain forms of attack. For example, it cannot protect against buffer overflows in the heap. There is no sane way to alter the layout of data within a [[Data structure|structure]]; structures are expected to be the same between modules, especially with shared libraries. Any data in a structure after a buffer is impossible to protect with canaries; thus, programmers must be very careful about how they organize their variables and use their structures.

==Canaries==

''Canaries'' or ''canary words'' are known values that are placed between a buffer and control data on the stack to monitor buffer overflows. When the buffer overflows, the first data to be corrupted will usually be the canary, and a failed verification of the canary data will therefore alert of an overflow, which can then be handled, for example, by invalidating the corrupted data. A [[canary value]] should not be confused with a [[sentinel value]].

The terminology is a reference to the historic practice of using [[animal sentinel#Toxic gases|canaries in coal mines]], since they would be affected by toxic gases earlier than the miners, thus providing a biological warning system. Canaries are alternately known as ''cookies'', which is meant to evoke the image of a "broken cookie" when the value is corrupted.

There are three types of canaries in use: ''terminator'', ''random'', and ''random [[XOR]]'' . Current versions of StackGuard support all three, while ProPolice supports ''terminator'' and ''random'' canaries.

===Terminator canaries===

''Terminator canaries'' use the observation that most buffer overflow attacks are based on certain string operations which end at string terminators. The reaction to this observation is that the canaries are built of [[null character|null]] terminators, [[Carriage return|CR]], LF, and -1. As a result, the attacker must write a null character before writing the return address to avoid altering the canary. This prevents attacks using <code>strcpy()</code> and other methods that return upon copying a null character, while the undesirable result is that the canary is known. Even with the protection, an attacker could potentially overwrite the canary with its known value and control information with mismatched values, thus passing the canary check code, which is executed soon before the specific processor's return-from-call instruction.

===Random canaries===

''Random canaries'' are randomly generated, usually from an [[entropy (computing)|entropy]]-gathering [[daemon (computer software)|daemon]], in order to prevent an attacker from knowing their value. Usually, it is not logically possible or plausible to read the canary for exploiting; the canary is a secure value known only by those who need to know it&mdash;the buffer overflow protection code in this case.

Normally, a random canary is generated at program initialization, and stored in a global variable. This variable is usually padded by unmapped pages, so that attempting to read it using any kinds of tricks that exploit bugs to read off RAM cause a segmentation fault, terminating the program. It may still be possible to read the canary, if the attacker knows where it is, or can get the program to read from the stack.

Line 38 ⟶ 39:

In addition, random XOR canaries can protect against a certain type of attack involving overflowing a buffer in a structure into a pointer to change the pointer to point at a piece of control data. Because of the XOR encoding, the canary will be wrong if the control data or return value is changed. Because of the pointer, the control data or return value can be changed without overflowing over the canary.

Although these canaries protect the control data from being altered by clobbered pointers, they do not protect any other data or the pointers themselves. Function pointers especially are a problem here, as they can be overflowed into and can execute [[shellcode]] when called.

==Bounds checking==