Buffer overflow protection: Difference between revisions

Revision as of 13:59, 27 April 2025

Latest revision as of 09:39, 10 August 2025

(2 intermediate revisions by one other user not shown)

Line 1:

{{Short description|Software security techniques}}

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

Line 33:

''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—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 [[Padding (cryptography)|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===

''Random XOR canaries'' are random canaries that are [[Exclusive or|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 (computer programming)|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.

Line 47:

{{Main|Bounds checking}}

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<ref name="joneskelly">{{cite web |url=http://www.doc.ic.ac.uk/~phjk/BoundsChecking.html |title=Bounds Checking for C |publisher=Doc.ic.ac.uk |access-date=2014-04-27 |archive-url=https://web.archive.org/web/20160326081542/https://www.doc.ic.ac.uk/~phjk/BoundsChecking.html |archive-date=2016-03-26 |url-status=dead }}</ref> or at [[Dereferencing|dereference]] time.<ref name="safecodesva">{{cite web|url=http://sva.cs.illinois.edu/sva.html |title=SAFECode: Secure Virtual Architecture |publisher=Sva.cs.illinois.edu |date=2009-08-12 |access-date=2014-04-27}}</ref><ref name="asan">{{cite web|url=https://code.google.com/p/address-sanitizer/|title=google/sanitizers|date=19 June 2021}}</ref><ref name="failsafec">{{cite web |url=http://staff.aist.go.jp/y.oiwa/FailSafeC/index-en.html |title=Fail-Safe C: Top Page |publisher=Staff.aist.go.jp |date=2013-05-07 |access-date=2014-04-27 |archive-url=https://web.archive.org/web/20160707163127/https://staff.aist.go.jp/y.oiwa/FailSafeC/index-en.html |archive-date=2016-07-07 |url-status=dead }}</ref>

Implementations of this approach use either a central repository, which describes each allocated block of memory,<ref name="joneskelly"/><ref name="safecodesva"/><ref name="asan"/> or [[fat pointer]]s,<ref name="failsafec"/> which contain both the pointer and additional data, describing the region that they point to.

Line 68:

All [[Fedora (operating system)|Fedora]] packages are compiled with <kbd>-fstack-protector</kbd> since Fedora Core 5, and <kbd>-fstack-protector-strong</kbd> since Fedora 20.<ref>{{cite web|url=https://fedoraproject.org/wiki/Security_Features#Stack_Smash_Protection.2C_Buffer_Overflow_Detection.2C_and_Variable_Reordering |title=Security Features |publisher=FedoraProject |date=2013-12-11 |access-date=2014-04-27}}</ref><ref>{{cite web|url=https://fedorahosted.org/fesco/ticket/1128 |title=#1128 (switching from "-fstack-protector" to "-fstack-protector-strong" in Fedora 20) – FESCo |publisher=Fedorahosted.org |access-date=2014-04-27}}</ref> Most packages in [[Ubuntu]] are compiled with <kbd>-fstack-protector</kbd> since 6.10.<ref>{{cite web|url=https://wiki.ubuntu.com/Security/Features#stack-protector |title=Security/Features - Ubuntu Wiki |publisher=Wiki.ubuntu.com |access-date=2014-04-27}}</ref> Every [[Arch Linux]] package is compiled with <kbd>-fstack-protector</kbd> since 2011.<ref>{{cite web|url=https://bugs.archlinux.org/task/18864 |title=FS#18864 : Consider enabling GCC's stack-smashing protection (ProPolice, SSP) for all packages |publisher=Bugs.archlinux.org |access-date=2014-04-27}}</ref> All Arch Linux packages built since 4 May 2014 use <kbd>-fstack-protector-strong</kbd>.<ref>{{cite web |url=https://projects.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/pacman&id=695ca25d4c24f3bd3b8c350d64f2697c733d5169 |archive-url=https://archive.today/20140718035407/https://projects.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/pacman&id=695ca25d4c24f3bd3b8c350d64f2697c733d5169 |url-status=dead |archive-date=July 18, 2014 |title=svntogit/packages.git - Git clone of the 'packages' repository }}</ref> Stack protection is only used for some packages in [[Debian]],<ref>{{cite web |url=http://outflux.net/debian/hardening/ |title=Debian Security Hardening Statistics |publisher=Outflux.net |access-date=2014-04-27 |archive-date=2014-04-28 |archive-url=https://web.archive.org/web/20140428012424/http://outflux.net/debian/hardening/ |url-status=dead }}</ref> and only for the [[FreeBSD]] base system since 8.0.<ref>{{cite web|url=http://www.freebsd.org/releases/8.0R/relnotes.html |title=FreeBSD 8.0-RELEASE Release Notes |publisher=Freebsd.org |date=2013-11-13 |access-date=2014-04-27}}</ref> Stack protection is standard in certain operating systems, including [[OpenBSD]],<ref>{{cite web| url = https://man.openbsd.org/gcc-local.1| title = OpenBSD's gcc-local(1) manual page| quote = gcc comes with the ''ProPolice'' stack protection extension, which is enabled by default.}}</ref> [[Hardened Gentoo]]<ref>{{cite web|url=https://wiki.gentoo.org/wiki/Hardened/Toolchain#Default_addition_of_the_Stack_Smashing_Protector_.28SSP.29|title=Hardened/Toolchain - Gentoo Wiki|quote=The Gentoo hardened GCC switches on the stack protector by default unless explicitly requested not to.|date=2016-07-31}}</ref> and [[DragonFly BSD]].{{Citation needed|date=September 2013}}

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 for [[pointer protection]] was proposed in PointGuard<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}}</ref> and is available on [[Microsoft Windows]].<ref>{{cite web|url=http://blogs.msdn.com/michael_howard/archive/2006/08/16/702707.aspx|title=MSDN Blogs – Get the latest information, insights, announcements, and news from Microsoft experts and developers in the MSDN blogs.|date=6 August 2021 }}</ref>

===Microsoft Visual Studio===