GCC编译器局部变量地址分配为什么总是从低地址向高地址增加？

如题，使用GCC编译器时发现，局部变量的地址总是从低地址向高地址分配，而dev c中局部变量却是从高地址向低地址分配的？

“栈分配的方向是从高地址向低地址分配，但在变量内部地址是从低地址向高地址增长。”一直都是这样理解的，以为所有编译器都是按照这种方式来分配变量地址的。但是gcc却不是，我用的版本是4.8.4.

原因：GCC的堆栈保护技术—— canary的使用。

使用的原因是为了防止某些溢出的攻击。但是只是溢出时方向发生了改变，并没有起到太大的作用，可能对于传统的一些攻击方法有用。

下面是一篇canary方法的讲解：

转载地址：http://www.ibm.com/developerworks/cn/linux/l-cn-gccstack/

以堆栈溢出为代表的缓冲区溢出已成为最为普遍的安全漏洞。由此引发的安全问题比比皆是。早在 1988 年，美国康奈尔大学的计算机科学系研究生莫里斯 (Morris) 利用 UNIX fingered 程序的溢出漏洞，写了一段恶意程序并传播到其他机器上，结果造成 6000 台 Internet 上的服务器瘫痪，占当时总数的 10%。各种操作系统上出现的溢出漏洞也数不胜数。为了尽可能避免缓冲区溢出漏洞被攻击者利用，现今的编译器设计者已经开始在编译器层面上对堆栈进行保护。现在已经有了好几种编译器堆栈保护的实现，其中最著名的是 StackGuard 和 Stack-smashing Protection (SSP，又名 ProPolice）。

编译器堆栈保护原理

我们知道攻击者利用堆栈溢出漏洞时，通常会破坏当前的函数栈。例如，攻击者利用清单 1 中的函数的堆栈溢出漏洞时，典型的情况是攻击者会试图让程序往 name 数组中写超过数组长度的数据，直到函数栈中的返回地址被覆盖，使该函数返回时跳转至攻击者注入的恶意代码或 shellcode 处执行（关于溢出攻击的原理参见《Linux 下缓冲区溢出攻击的原理及对策》）。溢出攻击后，函数栈变成了图 2 所示的情形，与溢出前（图 1）比较可以看出原本堆栈中的 EBP，返回地址已经被溢出字符串覆盖，即函数栈已经被破坏。

清单 1. 可能存在溢出漏洞的代码

int vulFunc() {
    char name[10];
    //…
    return 0;
}

图 1. 溢出前的函数栈

图 2. 溢出后的函数栈

如果能在运行时检测出这种破坏，就有可能对函数栈进行保护。目前的堆栈保护实现大多使用基于 “Canaries” 的探测技术来完成对这种破坏的检测。

“Canaries” 探测：

要检测对函数栈的破坏，需要修改函数栈的组织，在缓冲区和控制信息（如 EBP 等）间插入一个 canary word。这样，当缓冲区被溢出时，在返回地址被覆盖之前 canary word 会首先被覆盖。通过检查 canary word 的值是否被修改，就可以判断是否发生了溢出攻击。

常见的 canary word：

• Terminator canaries

• 由于绝大多数的溢出漏洞都是由那些不做数组越界检查的 C 字符串处理函数引起的，而这些字符串都是以 NULL 作为终结字符的。选择 NULL, CR, LF 这样的字符作为 canary word 就成了很自然的事情。例如，若 canary word 为 0x000aff0d，为了使溢出不被检测到，攻击者需要在溢出字符串中包含 0x000aff0d 并精确计算 canaries 的位置，使 canaries 看上去没有被改变。然而，0x000aff0d 中的 0x00 会使 strcpy() 结束复制从而防止返回地址被覆盖。而 0x0a 会使 gets() 结束读取。插入的 terminator canaries 给攻击者制造了很大的麻烦。

• Random canaries

• 这种 canaries 是随机产生的。并且这样的随机数通常不能被攻击者读取。这种随机数在程序初始化时产生，然后保存在一个未被隐射到虚拟地址空间的内存页中。这样当攻击者试图通过指针访问保存随机数的内存时就会引发 segment fault。但是由于这个随机数的副本最终会作为 canary word 被保存在函数栈中，攻击者仍有可能通过函数栈获得 canary word 的值。

• Random XOR canaries