Editing Buffer overflow (section)

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

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