EditWYSIWYGAttach 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
1104 Oct 2015 - 14:02ThomasMisa 
1004 Oct 2015 - 14:01ThomasMisa 
904 Oct 2015 - 14:00ThomasMisa 
804 Oct 2015 - 14:00ThomasMisa 
703 Mar 2015 - 13:00sever408? 
626 Feb 2015 - 16:22ThomasMisa 
526 Feb 2015 - 14:03sever408? 
425 Feb 2015 - 01:45sever408?Attached file Buffer_Overflow___Canary_copy.png

Attached file Buffer_Overflow___Canary.png

Attached file Buffer_Overflow___Canary-3.png 
324 Feb 2015 - 23:59sever408? 
224 Feb 2015 - 11:52ThomasMisa 
earlier first

Render style:     Context:

 History: r11 | r8 < r7 < r6 < r5
[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>WebPreferences>DraftCanaries (revision 6)

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

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.
Buffer_Overflow___Canary_copy.png Buffer_Overflow___Canary.png Buffer_Overflow___Canary-3.png
Figure 1: Intended buffer behaviour Figure 2: Buffer overflow attack 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 behaviour 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.


Earlier work on solving problem

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) Further evolution (placed on all pointers)


1 : Based on the fact that -fstack-protector 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.

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

Edit | WYSIWYG | Attach |  PDF |  History: r11 | r8 < r7 < r6 < r5 |  Backlinks |  Raw View | More topic actions...
Topic revision: r6 - 26 Feb 2015 - 16:22:15 - ThomasMisa
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