# An In-Depth Survey of Bypassing Buffer Overflow Mitigation Techniques
## 5 Compiler Based Mitigation Techniques
### Stack Canary  
A standard stack-based overflow attack changes the return address and alters the application's flow using some code injection method. Various protection and detection techniques have been proposed to mitigate buffer overflow attacks. One of them is Stack Canary. The idea of stack canary was first implemented by [56] and the proposed technique is known as StackGuard. It is a GCC compiler extension that tries to reduce the probability of stack smashing attacks. StackGuard prevents the return address from being changed by inserting a \"Canary\" next to the return address. When control returns after the function body's execution, it checks whether the canary is not altered by comparing it with its copy saved somewhere else, before jumping to the function's return address. This mechanism assumes that the canary is intact, then the return address is not changed. In standard stack smashing attacks, the only strategy attacker uses is overwriting the bytes linearly, sequentially, and in ascending order. In that way, it is almost impossible to change the return address without overwriting the canary. Figure 28 shows the stack layout of a program compiled with a stack canary. We have already seen that when a program makes a function call, a function stack frame is created on the stack via procedure prolog (Figure 28), and when control returns, it performs procedure epilog (Figure 28). The function prolog of the program compiled with StackGuard is different. First of all, it pushes the canary on the stack and then proceeds with the standard prolog. The epilog checks whether the canary is unchanged; it terminates the process with an error message if the change has occurred. The Figure 29 shows the disassembly of the same copy_buff function whose disassembly was shown in Figure 4, but this time program was compiled with stack canary. In 1997, StackGuard was first implemented as an extension of GCC 2.7 in Intel x86. In Linux, it was maintained from 1998-2003 in Immunix Linux distribution. GCC patches for stack protection were introduced for IBM from 2001 on-wards [57]. Red Hat engineers, after re-implementing stack protector in GCC 4.1, presented -fstack-protector flag to provide protection (but only for specific functions). In GCC version 4.9, Google implemented the -fstack-protector-strong flag to provide more robust security. Since Ubuntu 6.10, most of the packages use -fstack-protector flag. Since May 2014, all Arch Linux packages are compiled with -fstack-protector-strong flag. Since Fedora 20, all Fedora packages come with -fstack-protector-strong compiled. In initial implementations of StackGuard, a 32-bit random number was used to generate canary values randomly. There are other types of canaries, as well. For example, a constant value 0x0000000 was used as a NULL canary in the early StackGuard versions. XOR random canary is generated at run-time, is a random number saved on the stack, \begin{table}
\begin{tabular}{c c c} \hline \hline
**Mitigation Technique** & **Compiler (First** & **Strategy** \\
**SSP (Pro police)** & GCC extension (3.x) & Reordering of local variables \\ StackShield & GCC extension & Return address protection \\ Return Address Defender & & using duplicate address \\ (RAD) & GCC extension (2.95.2) & Return address protection \\ Address Sanitizer & Clang, GCC, Xcode, MSVC & Perform bounds checking \\ Automatic Fortification & GCC extension (4.0) & Perform bounds checking \\ Stackguard / Stack Canary & GCC extension (2.7.2.3) & Return address protection \\ \hline \hline \end{tabular}
\end{table} 
Table 6: Summary of Compiler Mitigation. after XORed with the return address. A constant number 0x000 affold was also used as canary in the StackGaurd version 2.0.1 named Terminator Canary. It was called so because of having null byte (0x00), line feed (0x0a), and EOF (0 xff) characters, that were able to terminate functions like strcpy(), gets() and other libc string copying functions. However, StackGuard also suffers from limitations and has been bypassed.