Buffer overflow - Revision history

OAbot: Open access bot: url-access updated in citation with #oabot.

2025-05-25T08:55:21Z

Open access bot: url-access updated in citation with #oabot.

← Previous revision		Revision as of 08:55, 25 May 2025
Line 151:		Line 151:
	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.		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}}</ref>		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===		===Pointer protection===

Brandon: Undid revision 1287566111 by Devboilol (talk) - unsourced

2025-04-27T06:40:28Z

Undid revision 1287566111 by Devboilol (talk) - unsourced

@@ Line 200: / Line 200: @@
 === 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==

Devboilol: add consumer level

2025-04-27T02:13:33Z

add consumer level

@@ Line 200: / Line 200: @@
 === 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==

WikiCleanerBot: v2.05b - Bot T18 CW#553 - Fix errors for CW project ( tags)

2025-03-24T14:22:26Z

v2.05b - Bot T18 CW#553 - Fix errors for CW project (<nowiki> tags)

← Previous revision		Revision as of 14:22, 24 March 2025
Line 122:		Line 122:
	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" />		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\|~~DLL~~]]~~<nowiki/>s~~ 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".		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==		==Protective countermeasures==

Cyberkiborg: /* The jump to address stored in a register technique */ I added internal links to other articles.

2025-03-15T16:04:47Z

The jump to address stored in a register technique: I added internal links to other articles.

← Previous revision		Revision as of 16:04, 15 March 2025
Line 122:		Line 122:
	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" />		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 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. ~~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".		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\|DLL]]<nowiki/>s 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==		==Protective countermeasures==
Line 130:		Line 130:
	===Choice of programming language===		===Choice of programming language===

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

NoblySP: Fixed inline link for Smashing the Stack for Fun and Profit

2025-03-06T14:35:31Z

Fixed inline link for Smashing the Stack for Fun and Profit

← Previous revision		Revision as of 14:35, 6 March 2025
Line 205:		Line 205:
	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.		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=~~http~~://~~www.~~phrack.~~com~~/issues/49/14 \|access-date=2025-03-06}}</ref> a step-by-step introduction to exploiting stack-based buffer overflow vulnerabilities.		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>		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>

NoblySP: Updated inline link for Smashing the Stack for Fun and Profit

2025-03-06T14:33:43Z

Updated inline link for Smashing the Stack for Fun and Profit

← Previous revision		Revision as of 14:33, 6 March 2025
Line 205:		Line 205:
	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.		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=http://www.phrack.com/issues~~.html?issue=~~49~~&id=~~14 \|access-date=~~2012~~-09-05}}</ref> a step-by-step introduction to exploiting stack-based buffer overflow vulnerabilities.		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=http://www.phrack.com/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>		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>

GreenC bot: Rescued 1 archive link; reformat 1 link. Wayback Medic 2.5 per WP:USURPURL and JUDI batch #21aa

2025-02-13T19:05:54Z

Rescued 1 archive link; reformat 1 link. Wayback Medic 2.5 per WP:USURPURL and JUDI batch #21aa

← Previous revision		Revision as of 19:05, 13 February 2025
Line 241:		Line 241:
	\| publisher = Enderunix.org		\| publisher = Enderunix.org
	\| url = http://www.enderunix.org/docs/en/bof-eng.txt		\| 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>		\| format = text }}</ref>
	<ref name="Akritidis1">{{cite conference		<ref name="Akritidis1">{{cite conference

Dwmalone: Include a brief description of CHERI and link to the main article.

2025-01-24T16:42:11Z

Include a brief description of CHERI and link to the main article.

← Previous revision		Revision as of 16:42, 24 January 2025
Line 178:		Line 178:

	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.		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===		===Address space layout randomization===

2001:4C4C:2261:2700:9D74:B114:BDE:EDB6: link to canaries

2024-12-20T17:49:37Z

link to canaries

← Previous revision		Revision as of 17:49, 20 December 2024
Line 8:		Line 8:
	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.		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.

	[[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 ("canaries").		[[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]]").

	==Technical description==		==Technical description==

← Previous revision		Revision as of 14:35, 6 March 2025
Line 205:		Line 205:
	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.		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=~~http~~://~~www.~~phrack.~~com~~/issues/49/14 \|access-date=2025-03-06}}</ref> a step-by-step introduction to exploiting stack-based buffer overflow vulnerabilities.		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>		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>

← Previous revision		Revision as of 14:33, 6 March 2025
Line 205:		Line 205:
	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.		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=http://www.phrack.com/issues~~.html?issue=~~49~~&id=~~14 \|access-date=~~2012~~-09-05}}</ref> a step-by-step introduction to exploiting stack-based buffer overflow vulnerabilities.		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=http://www.phrack.com/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>		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>