Edit WYSIWYGattachfile Attach PDF Raw View►More Actions▼More Actions

Restore topic to revision: You will be able to review the topic before saving it to a new revision

Copy text and form data to a new topic (no attachments will be copied though).
Name of copy:
You will be able to review the copied topic before saving

Rename/move topic... scans links in all public webs (recommended)
Rename/move topic... scans links in CBI_ComputerSecurity web only
Delete topic... scans links in all public webs (recommended)
Delete topic... scans links in CBI_ComputerSecurity web only

Revision Date Username Comment
505 Mar 2015 - 13:58sever408? 
404 Mar 2015 - 19:00sever408? 
304 Mar 2015 - 15:40ThomasMisa 
204 Mar 2015 - 15:40ThomasMisa 
103 Mar 2015 - 13:06sever408? 

Render style:     Context:

 History: r5 < r4 < r3 < r2 < r1
[X] Hide this message.
Notice: On June 30, 2016, UMWiki service will be decommissioned. If you have information in UMWIki that needs to be preserved, you should make plans to move it before that date. Google Sites is anticipated to be the most popular and appropriate alternative for users because it offers a more modern and user-friendly interface and unlimited capacity. To learn more about the features of Google Sites and other alternatives, and to identify which one best fits your needs, see the University’s Website Solution Selection Guide. If you have concerns or would like help regarding this change and your options, please contact Technology Help at help@umn.edu
You are here: UMWiki>CBI_ComputerSecurity Web>Mechanisms>MechanismCanary (revision 5)

Current Activitieslock Who is Who?lock People Programs Publications CSHW_2014 Systems Events Mechanisms

Canary (buffer overflow)

A canary is a security mechanism designed to prevent buffer overflow attacks. When a buffer overflow attack occurs, it overwrites more memory than the buffer, or space provided to write, should allow. This becomes problematic when other crucial pieces of information are overwritten, notably a return address, which controls where the computer will go looking for further instructions. A canary can prevent this from occurring.


The images below are representations of a computer's memory while it's running a program. The squares labelled buffer refer to a place that a user can place a string of characters.
Figure 1: Intended buffer behavior
Figure 2: Buffer overflow attack
I am sorry for this terrible hack, but if you want to keep the borders nice, PLEASE DO NOT DELETE THIS.
Figure 3: Buffer overflow attack thwarted by a stack canary

Figure 1 shows us how a buffer is supposed to work: the user places an expected number of characters into the buffer, and the program continues to operate as expected. Figure 2 shows us a buffer overflow attack, which allows a hacker to redirect the program to produce behavior that the program wasn't designed to perform, such as give full administrator access to the system.

Figure 3 shows us a program that uses a canary. The canary is checked by the program before the return address is used; if the canary has been altered, the program will abort immediately, preventing an attacker from taking over the program. The value of the canary is either random (and therefore very unlikely to be guessed correctly) or is made of a certain string of characters that, for technical reasons, are not possible to overwrite with a buffer overflow.


The first published implementation of canaries was the StackGuard paper, presented at the USENIX Security Symposium in 1998. The paper coined the term "canary"; the term is "a direct descendent of the Welsh miner’s canary," as Cowan et al. put it. The researchers released their end-product, a patch to the GCC 2.7 compiler, freely to anyone that wished to use it. This first version of the canary was only applied to return addresses, and not other pieces of data vulnerable to buffer overflow attacks, such as function pointers (which can be abused like a return address, but are not strictly the same).

Stack protection was not included in the standard GCC installation until version 4.1, which was released in 2006. (1)(2) This version includes an option to use canary protection for all functions, not just return addresses. Earlier attempts to get a similar patch into GCC by both IBM and the StackGuard? team appear to have been ignored by GNU.(3)


1 : Based on the fact that -fstack-protector (the option to turn on the stack canary) appears in https://gcc.gnu.org/onlinedocs/gcc-4.1.2/gcc/Optimize-Options.html but not the documentation for the prior version, https://gcc.gnu.org/onlinedocs/gcc-4.0.4/gcc/Optimize-Options.html#Optimize-Options. Despite the version numbers, these updates are chronologically adjacent, and 4.1 is the first version to see this option.

2 : https://www.gnu.org/software/gcc/gcc-4.1/changes.html

3 : Based on GCC correspondence pre-dating 2006, and the apparent lack of response in implementation: https://gcc.gnu.org/ml/gcc-patches/2000-10/msg00784.html , http://web.archive.org/web/20040715225038/http://www.linux.org.uk/~ajh/gcc/gccsummit-2003-proceedings.pdf

Topic revision: r5 - 05 Mar 2015 - 13:58:18 - sever408
Signed in as lewi0740 (NicLewis) | Sign out
UMWiki UMWiki
This site is powered by FoswikiCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding UMWiki? Send feedback