Buffer overflow protection is any of various techniques used during software development to enhance the security of executable programs by detectingbuffer overflows onstack-allocated variables, and preventing them from causing program misbehavior or from becoming serioussecurity 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 acanary 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 includebounds checking, which checks accesses to each allocated block of memory so they cannot go beyond the actually allocated space, andtagging, 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 theheap 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 theGNU Compiler Collection,LLVM,Microsoft Visual Studio, and other compilers.
A stack buffer overflow occurs when a program writes to a memory address on the program'scall 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 asbuffer 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.[1]
Stack buffer overflow can be caused deliberately as part of an attack known asstack smashing. If the affected program is running with special privileges, or if it accepts data from untrusted network hosts (for example, a publicwebserver), then the bug is a potential security vulnerability that allows anattacker 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.[2]
Typically, buffer overflow protection modifies the organization of data in thestack frame of afunction 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,[3] 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 astructure; 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.
 | This sectiondoes notcite anysources. Please helpimprove this section byadding citations to reliable sources. Unsourced material may be challenged andremoved.(November 2023) (Learn how and when to remove this message) |
Canaries orcanary words orstack cookies 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 asentinel value.
The terminology is a reference to the historic practice of usingcanaries 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 asstack 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, andrandomXOR. Current versions of StackGuard support all three, while ProPolice supportsterminator andrandom 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 ofnull terminators,CR, LF, andFF. As a result, the attacker must write a null character before writing the return address to avoid altering the canary. This prevents attacks usingstrcpy() 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 are randomly generated, usually from anentropy-gatheringdaemon, 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—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.
Random XOR canaries are random canaries that are XOR-scrambled using all or part of the control data. In this way, once the canary or the control data is clobbered, the canary value is wrong.
Random XOR canaries have the same vulnerabilities as random canaries, except that the "read from stack" method of getting the canary is a bit more complicated. The attacker must get the canary, the algorithm, and the control data in order to re-generate the original canary needed to spoof the protection.
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 executeshellcode when called.
Bounds checking is a compiler-based technique that adds run-time bounds information for each allocated block of memory, and checks all pointers against those at run-time. For C and C++, bounds checking can be performed at pointer calculation time[4] or at dereference time.[5][6][7]
Implementations of this approach use either a central repository, which describes each allocated block of memory,[4][5][6] orfat pointers,[7] which contain both the pointer and additional data, describing the region that they point to.
Tagging[8] is a compiler-based or hardware-based (requiring atagged architecture) technique for tagging the type of a piece of data in memory, used mainly for type checking. By marking certain areas of memory as non-executable, it effectively prevents memory allocated to store data from containing executable code. Also, certain areas of memory can be marked as non-allocated, preventing buffer overflows.
Historically, tagging has been used for implementing high-level programming languages;[9] with appropriate support from theoperating system, tagging can also be used to detect buffer overflows.[10] An example is theNX bit hardware feature, supported byIntel,AMD andARM processors.
Stack-smashing protection was first implemented byStackGuard in 1997, and published at the 1998USENIX Security Symposium.[11] StackGuard was introduced as a set of patches to the Intel x86 backend ofGCC 2.7. StackGuard was maintained for theImmunix Linux distribution from 1998 to 2003, and was extended with implementations for terminator, random and random XOR canaries. StackGuard was suggested for inclusion in GCC 3.x at the GCC 2003 Summit Proceedings,[12] but this was never achieved.
From 2001 to 2005,IBM developed GCC patches for stack-smashing protection, known asProPolice.[13] It improved on the idea of StackGuard by placing buffers after local pointers and function arguments in the stack frame. This helped avoid the corruption of pointers, preventing access to arbitrary memory locations.
Red Hat engineers identified problems with ProPolice though, and in 2005 re-implemented stack-smashing protection for inclusion in GCC 4.1.[14][15] This work introduced the-fstack-protector flag, which protects only some vulnerable functions, and the-fstack-protector-all flag, which protects all functions whether they need it or not.[16]
In 2012,Google engineers implemented the-fstack-protector-strong flag to strike a better balance between security and performance.[17] This flag protects more kinds of vulnerable functions than-fstack-protector does, but not every function, providing better performance than-fstack-protector-all. It is available in GCC since its version 4.9.[18]
AllFedora packages are compiled with-fstack-protector since Fedora Core 5, and-fstack-protector-strong since Fedora 20.[19][20] Most packages inUbuntu are compiled with-fstack-protector since 6.10.[21] EveryArch Linux package is compiled with-fstack-protector since 2011.[22] All Arch Linux packages built since 4 May 2014 use-fstack-protector-strong.[23] Stack protection is only used for some packages inDebian,[24] and only for theFreeBSD base system since 8.0.[25] Stack protection is standard in certain operating systems, includingOpenBSD,[26]Hardened Gentoo[27] andDragonFly BSD.[citation needed]
StackGuard and ProPolice cannot protect against overflows in automatically allocated structures that overflow into function pointers. ProPolice at least will rearrange the allocation order to get such structures allocated before function pointers. A separate mechanism forpointer protection was proposed in PointGuard[28] and is available on Microsoft Windows.[29]
The compiler suite from Microsoft implements buffer overflow protection since version 2003 through the/GS command-line switch, which is enabled by default since version 2005.[30] Using/GS- disables the protection.
Stack-smashing protection can be turned on by the compiler flag-qstackprotect.[31]
Clang supports the same-fstack-protector options as GCC[32] and a stronger "safe stack" (-fsanitize=safe-stack) system with similarly low performance impact.[33] Clang also has three buffer overflow detectors, namelyAddressSanitizer (-fsanitize=address),[6] UBSan (-fsanitize=bounds),[34]and the unofficial SafeCode (last updated for LLVM 3.0).[35]
These systems have different tradeoffs in terms of performance penalty, memory overhead, and classes of detected bugs. Stack protection is standard in certain operating systems, includingOpenBSD.[36]
Intel's C and C++ compiler supports stack-smashing protection with options similar to those provided by GCC and Microsoft Visual Studio.[37]
Fail-Safe C[7] is an open-source memory-safe ANSI C compiler that performs bounds checking based on fat pointers and object-oriented memory access.[38]
Invented byMike Frantzen, StackGhost is a simple tweak to the register window spill/fill routines which makes buffer overflows much more difficult to exploit. It uses a unique hardware feature of theSun MicrosystemsSPARC architecture (that being: deferred on-stack in-frame register window spill/fill) to detect modifications of returnpointers (a common way for anexploit to hijack execution paths) transparently, automatically protecting all applications without requiring binary or source modifications. The performance impact is negligible, less than one percent. The resultinggdb issues were resolved byMark Kettenis two years later, allowing enabling of the feature. Following this event, the StackGhost code was integrated (and optimized) intoOpenBSD/SPARC.
{{cite web}}: CS1 maint: bot: original URL status unknown (link)It has made its way into GCC 4.9
gcc comes with theProPolice stack protection extension, which is enabled by default.
The Gentoo hardened GCC switches on the stack protector by default unless explicitly requested not to.
clang comes with stack protection enabled by default, equivalent to the-fstack-protector-strong option on other systems.