栈缓冲区溢出

栈缓冲区溢出（stack buffer overflow或stack buffer overrun）是计算机程序把数据写入调用栈上的内存时超出了数据结构的边界。栈缓冲区溢出是缓冲区溢出的一种。 这会损坏相邻数据的值，引发程序崩溃或者修改了函数返回地址从而导致执行恶意的程序。这种攻击方式称为stack smashing。可被用于注入可执行代码、接管进程的执行。是最为古老的黑客攻击行为之一。

例子

下例可用于覆盖函数返回地址。 通过函数 strcpy() :

#include <string.h>

void foo (char *bar)
{
   char  c[12];

   strcpy(c, bar);  // no bounds checking
}

int main (int argc, char **argv)
{
   foo(argv[1]);

   return 0;
}

当命令行参数少于12个字符时（例子B时）该程序是安全的。

foo()函数的不同输入下的调用栈，下圖展示32位元小端序(little-endian)系統發生棧緩衝區溢出的記憶體狀態:

A. - Before data is copied.

B. - "hello" is the first command line argument.

C. - "A​A​A​A​A​A​A​A​A​A​A​A​A​A​A​A​A​A​A​A​\x08​\x35​\xC0​\x80" is the first command line argument.

例子C中, 命令行参数多于11个字符，导致foo()覆盖了本地调用栈的数据、存储的栈指针（EBP）以及最重要的返回地址。

攻击也可以修改内部变量值：

#include <string.h>
#include <stdio.h>

void foo (char *bar)
{
   float My_Float = 10.5; // Addr = 0x0023FF4C
   char  c[28];           // Addr = 0x0023FF30

   // Will print 10.500000
   printf("My Float value = %f\n", My_Float);

    /* ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
       Memory map:
       @ : c allocated memory
       # : My_Float allocated memory

           *c                      *My_Float
       0x0023FF30                  0x0023FF4C
           |                           |
           @@@@@@@@@@@@@@@@@@@@@@@@@@@@#####
      foo("my string is too long !!!!! XXXXX");

   memcpy will put 0x1010C042 (little endian) in My_Float value.
   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~*/

   memcpy(c, bar, strlen(bar));  // no bounds checking...

   // Will print 96.031372
   printf("My Float value = %f\n", My_Float);
}

int main (int argc, char **argv)
{
   foo("my string is too long !!!!! \x10\x10\xc0\x42");
   return 0;
}

平台相关

已隱藏部分未翻譯内容，歡迎參與翻譯。

A number of platforms have subtle differences in their implementation of the call stack that can affect the way a stack buffer overflow exploit will work. Some machine architectures store the top level return address of the call stack in a register. This means that any overwritten return address will not be used until a later unwinding of the call stack. Another example of a machine specific detail that can affect the choice of exploitation techniques is the fact that most RISC style machine architectures will not allow unaligned access to memory. Combined with a fixed length for machine opcodes this machine limitation can make the jump to ESP technique almost impossible to implement (with the one exception being when the program actually contains the unlikely code to explicitly jump to the stack register).

Stacks that grow up

Within the topic of stack buffer overflows, an often discussed but rarely seen architecture is one in which the stack grows in the opposite direction. This change in architecture is frequently suggested as a solution to the stack buffer overflow problem because any overflow of a stack buffer that occurs within the same stack frame can not overwrite the return pointer. Further investigation of this claimed protection finds it to be a naive solution at best. Any overflow that occurs in a buffer from a previous stack frame will still overwrite a return pointer and allow for malicious exploitation of the bug. For instance, in the example above, the return pointer for foo will not be overwritten because the overflow actually occurs within the stack frame for strcpy. However, because the buffer that overflows during the call to strcpy resides in a previous stack frame, the return pointer for strcpy will have a numerically higher memory address than the buffer. This means that instead of the return pointer for foo being overwritten, the return pointer for strcpy will be overwritten. At most this means that growing the stack in the opposite direction will change some details of how stack buffer overflows are exploitable, but it will not reduce significantly the number of exploitable bugs.

保护方式

常用三种方式来对抗栈缓冲区溢出攻击。

检查栈缓冲区溢出的发生

栈的警惕标志（stack canary），得名于煤矿里的金丝雀，用于探测该灾难的发生。具体办法是在栈的返回地址的存储位置之前放置一个整形值，该值在装入程序时随机确定。栈缓冲区攻击时从低地址向高地址覆盖栈空间，因此会在覆盖返回地址之前就覆盖了警惕标志。返回返回前会检查该警惕标志是否被篡改。

栈数据不可执行

采取了“写异或执行”策略（W^X, "Write XOR Execute"），即内存要么可写，要么可执行，但二者不能兼得。这是最常用的方法，大部分桌面处理器都硬件支持不可执行标志（no-execute flag）。

已隱藏部分未翻譯内容，歡迎參與翻譯。

While this method definitely makes the canonical approach to stack buffer overflow exploitation fail, it is not without its problems. First, it is common to find ways to store shellcode in unprotected memory regions like the heap, and so very little need change in the way of exploitation.

Even if this were not so, there are other ways. The most damning is the so-called return to libc method for shellcode creation. In this attack the malicious payload will load the stack not with shellcode, but with a proper call stack so that execution is vectored to a chain of standard library calls, usually with the effect of disabling memory execute protections and allowing shellcode to run as normal. This works because the execution never actually vectors to the stack itself.

A variant of return-to-libc is return-oriented programming, which sets up a series of return addresses, each of which executes a small sequence of cherry-picked machine instructions within the existing program code or system libraries, sequence which ends with a return. These so-called gadgets each accomplish some simple register manipulation or similar execution before returning, and stringing them together achieves the attacker's ends. It is even possible to use "returnless" return-oriented programming by exploiting instructions or groups of instructions that behave much like a return instruction.

随机化内存空间布局

已隱藏部分未翻譯内容，歡迎參與翻譯。

Instead of separating the code from the data another mitigation technique is to introduce randomization to the memory space of the executing program. Since the attacker needs to determine where executable code that can be used resides, either an executable payload is provided (with an executable stack) or one is constructed using code reuse such as in ret2libc or ROP (Return Oriented Programming) randomizing the memory layout will as a concept prevent the attacker from knowing where any code is. However implementations typically will not randomize everything, usually the executable itself is loaded at a fixed address and hence even when ASLR (Address Space Layout Randomization) is combined with a nonexecutable stack the attacker can use this fixed region of memory. Therefore all programs should be compiled with PIE (position-independent executables) such that even this region of memory is randomized. The entropy of the randomization is different from implementation to implementation and a low enough entropy can in itself be a problem in terms of brute forcing the memory space that is randomized.

随机化内存空间布局(ASLR)會對處理程序的記憶體區段地址進行隨機化，阻止攻擊者進行返回導向編程與跳至Shellcode的攻擊手法，因為攻擊者需要知道可執行區段與 Shellcode 的記憶體地址。執行檔如果不是地址無關代碼(PIE)的格式，會導致執行檔載入成處理程序之後，部分區段地址為固定的(如 .text 區段)，攻擊者在Linux系統上，依然可以 return 到 0x400000 地址。ASLR受到資訊熵的影響，不同的實作會有不同的資訊熵，過低的資訊熵使攻擊者更容易猜測到地址，也因此32位元比起64位元的更容易受到威脅。也因此在2015年發生Stagefright漏洞，在32位元系統下，ASLR僅有8位元的資訊熵，因此每次漏洞利用，只需要從256種組合猜測可能的記憶體地址進行利用。

著名例子

• 莫里斯蠕虫针对Unix finger 服务器.[1] （页面存档备份，存于互联网档案馆）
• Witty worm .[2]
• Slammer worm针对Microsoft SQL Server.[3] （页面存档备份，存于互联网档案馆）
• 衝擊波蠕蟲 针对微软的DCOM 服务.
• Twilight hack针对Wii