解讀Linux安全機制之棧溢出保護
一、概述
棧溢出保護是一種緩沖區溢出攻擊緩解手段，當函數存在緩沖區溢出攻擊漏洞時，攻擊者可以覆蓋棧上的返回地址來讓shellcode能夠得到執行。當啟用棧保護后，函數開始執行的時候會先往棧里插入cookie信息，當函數真正返回的時候會驗證cookie信息是否合法，如果不合法就停止程序運行。攻擊者在覆蓋返回地址的時候往往也會將cookie信息給覆蓋掉，導致棧保護檢查失敗而阻止shellcode的執行。在Linux中我們將cookie信息稱為canary(以下統一使用canary)。
gcc在4.2版本中添加了-fstack-protector和-fstack-protector-all編譯參數以支持棧保護功能，4.9新增了-fstack-protector-strong編譯參數讓保護的范圍更廣。以下是-fstack-protector和-fstack-protector-strong的區別：
Linux系統中存在著三種類型的棧：
- 應用程序棧：工作在Ring3,由應用程序來維護;
- 內核進程上下文棧：工作在Ring0，由內核在創建線程的時候創建;
- 內核中斷上下文棧：工作在Ring0，在內核初始化的時候給每個CPU核心創建一個。
二、 應用程序棧保護
1. 棧保護工作原理
下面是一個包含棧溢出的例子：
- /* test.c */
- #include <stdio.h>
- #include <string.h>
- int main(int argc, char **argv)
- {
- char buf[16];
- scanf("%s", buf);
- printf("%s\n", buf);
- return 0;
- }
我們先禁用棧保護功能看看執行的結果
- [root@localhost stackp]# gcc -o test test.c -fno-stack-protector
- [root@localhost stackp]# python -c "print 'A'*24" | ./test
- AAAAAAAAAAAAAAAAAAAAAAAA
- Segmentation fault <- RIP腐敗，導致異常
當返回地址被覆蓋后產生了一個段錯誤，因為現在的返回地址已經無效了，所以現在執行的是CPU的異常處理流程。我們打開棧保護后再看看結果：
- [root@localhost stackp]# gcc -o test test.c -fstack-protector
- [root@localhost stackp]# python -c "print 'A'*25" | ./test
- AAAAAAAAAAAAAAAAAAAAAAAAA
- *** stack smashing detected ***: ./test terminated
這時觸發的就不是段錯誤了，而是棧保護的處理流程，我們反匯編看看做了哪些事情：
- 0000000000400610 <main>:
- 400610: 55 push %rbp
- 400611: 48 89 e5 mov %rsp,%rbp
- 400614: 48 83 ec 30 sub $0x30,%rsp
- 400618: 89 7d dc mov %edi,-0x24(%rbp)
- 40061b: 48 89 75 d0 mov %rsi,-0x30(%rbp)
- 40061f: 64 48 8b 04 25 28 00 mov %fs:0x28,%rax <- 插入canary值
- 400626: 00 00
- 400628: 48 89 45 f8 mov %rax,-0x8(%rbp)
- 40062c: 31 c0 xor %eax,%eax
- 40062e: 48 8d 45 e0 lea -0x20(%rbp),%rax
- 400632: 48 89 c6 mov %rax,%rsi
- 400635: bf 00 07 40 00 mov $0x400700,%edi
- 40063a: b8 00 00 00 00 mov $0x0,%eax
- 40063f: e8 cc fe ff ff callq 400510 <__isoc99_scanf@plt>
- 400644: 48 8d 45 e0 lea -0x20(%rbp),%rax
- 400648: 48 89 c7 mov %rax,%rdi
- 40064b: e8 80 fe ff ff callq 4004d0 <puts@plt>
- 400650: b8 00 00 00 00 mov $0x0,%eax
- 400655: 48 8b 55 f8 mov -0x8(%rbp),%rdx <- 檢查canary值
- 400659: 64 48 33 14 25 28 00 xor %fs:0x28,%rdx
- 400660: 00 00
- 400662: 74 05 je 400669 <main+0x59> # 0x400669
- 400664: e8 77 fe ff ff callq 4004e0 <__stack_chk_fail@plt>
- 400669: c9 leaveq
- 40066a: c3 retq
我們看到函數開頭(地址：0x40061f)處gcc編譯時在棧幀的返回地址和臨時變量之間插入了一個canary值，該值是從%fs:0x28里取的，棧幀的布局如下： 在函數即將返回時(地址：0x400655)檢查棧中的值是否和原來的相等，如果不相等就調用glibc的_stackchk_fail函數，并終止進程。 2. canary值的產生 這里以x64平臺為例，canary是從%fs:0x28偏移位置獲取的，%fs寄存器被glibc定義為存放tls信息的，我們需要查看glibc的源代碼： 結構體tcbheadt就是用來描述tls的也就是%fs寄存器指向的位置，其中+0x28偏移位置的成員變量stackguard就是canary值。另外通過strace ./test看到在進程加載的過程中會調用arch_prctl系統調用來設置%fs的值， 產生canary值的代碼在glibc的dlmain和_libcstart_main函數中： dlrandom是一個隨機數，它由dlsysdepstart函數從內核獲取的。dlsetupstackchkguard函數負責生成canary值，THREADSETSTACK_GUARD宏將canary設置到%fs:0x28位置。 在應用程序棧保護中，進程的%fs寄存器是由glibc來管理的，并不涉及到內核提供的功能。 3. x32應用程序棧保護 解讀完了x64的實現，我們來看看x32下面的情況，我們還是使用上面例子的代碼在x32的機器上編譯，得到下面的代碼：
