緩沖區溢出攻擊
緩沖區溢出（Buffer Overflow）是計算機安全領域內既經典而又古老的話題。隨着計算機系統安全性的加強，傳統的緩沖區溢出攻擊方式可能變得不再奏效，相應的介紹緩沖區溢出原理的資料也變得“大眾化”起來。其中看雪的《0day安全：軟件漏洞分析技術》一書將緩沖區溢出攻擊的原理闡述得簡潔明了。本文參考該書對緩沖區溢出原理的講解，並結合實際的代碼實例進行驗證。不過即便如此，完成一個簡單的溢出代碼也需要解決很多書中無法涉及的問題，尤其是面對較新的具有安全特性的編譯器——比如MS的Visual Studio2010。接下來，我們結合具體代碼，按照對緩沖區溢出原理的循序漸進地理解方式去挖掘緩沖區溢出背后的底層機制。
一、代碼 <=> 數據
顧名思義，緩沖區溢出的含義是為緩沖區提供了多於其存儲容量的數據，就像往杯子里倒入了過量的水一樣。通常情況下，緩沖區溢出的數據只會破壞程序數據，造成意外終止。但是如果有人精心構造溢出數據的內容，那么就有可能獲得系統的控制權！如果說用戶（也可能是黑客）提供了水——緩沖區溢出攻擊的數據，那么系統提供了溢出的容器——緩沖區。
緩沖區在系統中的表現形式是多樣的，高級語言定義的變量、數組、結構體等在運行時可以說都是保存在緩沖區內的，因此所謂緩沖區可以更抽象地理解為一段可讀寫的內存區域，緩沖區攻擊的最終目的就是希望系統能執行這塊可讀寫內存中已經被蓄意設定好的惡意代碼。按照馮·諾依曼存儲程序原理，程序代碼是作為二進制數據存儲在內存的，同樣程序的數據也在內存中，因此直接從內存的二進制形式上是無法區分哪些是數據哪些是代碼的，這也為緩沖區溢出攻擊提供了可能。
圖1 進程地址空間分布
圖1是進程地址空間分布的簡單表示。代碼存儲了用戶程序的所有可執行代碼，在程序正常執行的情況下，程序計數器（PC指針）只會在代碼段和操作系統地址空間（內核態）內尋址。數據段內存儲了用戶程序的全局變量，文字池等。棧空間存儲了用戶程序的函數棧幀（包括參數、局部數據等），實現函數調用機制，它的數據增長方向是低地址方向。堆空間存儲了程序運行時動態申請的內存數據等，數據增長方向是高地址方向。除了代碼段和受操作系統保護的數據區域，其他的內存區域都可能作為緩沖區，因此緩沖區溢出的位置可能在數據段，也可能在堆、棧段。如果程序的代碼有軟件漏洞，惡意程序會“教唆”程序計數器從上述緩沖區內取指，執行惡意程序提供的數據代碼！本文分析並實現棧溢出攻擊方式。
二、函數棧幀
棧的主要功能是實現函數的調用。因此在介紹棧溢出原理之前，需要弄清函數調用時棧空間發生了怎樣的變化。每次函數調用時，系統會把函數的返回地址（函數調用指令后緊跟指令的地址），一些關鍵的寄存器值保存在棧內，函數的實際參數和局部變量（包括數據、結構體、對象等）也會保存在棧內。這些數據統稱為函數調用的棧幀，而且是每次函數調用都會有個獨立的棧幀，這也為遞歸函數的實現提供了可能。
圖2 函數棧幀
如圖所示，我們定義了一個簡單的函數function，它接受一個整形參數，做一次乘法操作並返回。當調用function(0)時，arg參數記錄了值0入棧，並將call function指令下一條指令的地址0x00bd
sub esp,44h指令為局部變量開辟了棧空間，比如ret變量的位置。理論上，function只需要再開辟4字節空間保存ret即可，但是編譯器開辟了更多的空間（這個問題很詭異，你覺得呢？）。函數調用結束返回后，函數棧幀恢復到保存參數0時的狀態，為了保持棧幀平衡，需要恢復esp的內容，使用add esp,4將壓入的參數彈出。
之所以會有緩沖區溢出的可能，主要是因為棧空間內保存了函數的返回地址。該地址保存了函數調用結束后后續執行的指令的位置，對於計算機安全來說，該信息是很敏感的。如果有人惡意修改了這個返回地址，並使該返回地址指向了一個新的代碼位置，程序便能從其它位置繼續執行。
三、棧溢出基本原理
上邊給出的代碼是無法進行溢出操作的，因為用戶沒有“插足”的機會。但是實際上很多程序都會接受用戶的外界輸入，尤其是當函數內的一個數組緩沖區接受用戶輸入的時候，一旦程序代碼未對輸入的長度進行合法性檢查的話，緩沖區溢出便有可能觸發！比如下邊的一個簡單的函數。
{
unsigned char buffer[BUF_LEN];
strcpy(( char*)buffer,( char*)data); // 溢出點
}
這個函數沒有做什么有“意義”的事情（這里主要是為了簡化問題），但是它是一個典型的棧溢出代碼。在使用不安全的strcpy庫函數時，系統會盲目地將data的全部數據拷貝到buffer指向的內存區域。buffer的長度是有限的，一旦data的數據長度超過BUF_LEN，便會產生緩沖區溢出。
圖3 緩沖區溢出
由於棧是低地址方向增長的，因此局部數組buffer的指針在緩沖區的下方。當把data的數據拷貝到buffer內時，超過緩沖區區域的高地址部分數據會“淹沒”原本的其他棧幀數據，根據淹沒數據的內容不同，可能會有產生以下情況：
1、淹沒了其他的局部變量。如果被淹沒的局部變量是條件變量，那么可能會改變函數原本的執行流程。這種方式可以用於破解簡單的軟件驗證。
2、淹沒了ebp的值。修改了函數執行結束后要恢復的棧指針，將會導致棧幀失去平衡。
3、淹沒了返回地址。這是棧溢出原理的核心所在，通過淹沒的方式修改函數的返回地址，使程序代碼執行“意外”的流程！
4、淹沒參數變量。修改函數的參數變量也可能改變當前函數的執行結果和流程。
5、淹沒上級函數的棧幀，情況與上述4點類似，只不過影響的是上級函數的執行。當然這里的前提是保證函數能正常返回，即函數地址不能被隨意修改（這可能很麻煩！）。
如果在data本身的數據內就保存了一系列的指令的二進制代碼，一旦棧溢出修改了函數的返回地址，並將該地址指向這段二進制代碼的其實位置，那么就完成了基本的溢出攻擊行為。
圖4 基本棧溢出攻擊
通過計算返回地址內存區域相對於buffer的偏移，並在對應位置構造新的地址指向buffer內部二進制代碼的其實位置，便能執行用戶的自定義代碼！這段既是代碼又是數據的二進制數據被稱為shellcode，因為攻擊者希望通過這段代碼打開系統的shell，以執行任意的操作系統命令——比如下載病毒，安裝木馬，開放端口，格式化磁盤等惡意操作。
四、棧溢出攻擊
上述過程雖然理論上能完成棧溢出攻擊行為，但是實際上很難實現。操作系統每次加載可執行文件到進程空間的位置都是無法預測的，因此棧的位置實際是不固定的，通過硬編碼覆蓋新返回地址的方式並不可靠。為了能准確定位shellcode的地址，需要借助一些額外的操作，其中最經典的是借助跳板的棧溢出方式。
根據前邊所述，函數執行后，棧指針esp會恢復到壓入參數時的狀態，在圖4中即data參數的地址。如果我們在函數的返回地址填入一個地址，該地址指向的內存保存了一條特殊的指令jmp esp——跳板。那么函數返回后，會執行該指令並跳轉到esp所在的位置——即data的位置。我們可以將緩沖區再多溢出一部分，淹沒data這樣的函數參數，並在這里放上我們想要執行的代碼！這樣，不管程序被加載到哪個位置，最終都會回來執行棧內的代碼。
圖5 借助跳板的棧溢出攻擊
借助於跳板的確可以很好的解決棧幀移位（棧加載地址不固定）的問題，但是跳板指令從哪找呢？“幸運”的是，在Windows操作系統加載的大量dll中，包含了許多這樣的指令，比如kernel32.dll，ntdll.dll，這兩個動態鏈接庫是Windows程序默認加載的。如果是圖形化界面的Windows程序還會加載user32.dll，它也包含了大量的跳板指令！而且更“神奇”的是Windows操作系統加載dll時候一般都是固定地址，因此這些dll內的跳板指令的地址一般都是固定的。我們可以離線搜索出跳板執行在dll內的偏移，並加上dll的加載地址，便得到一個適用的跳板指令地址！
int findJmp( char*dll_name)
{
char* handle=( char*)LoadLibraryA(dll_name); // 獲取dll加載地址
for( int pos= 0;;pos++) // 遍歷dll代碼空間
{
if(handle[pos]==( char) 0xff&&handle[pos+ 1]==( char) 0xe4) // 尋找0xffe4 = jmp esp
{
return ( int)(handle+pos);
}
}
}
這里簡化了搜索算法，輸出第一個跳板指令的地址，讀者可以選取其他更合適位置。LoadLibraryA庫函數返回值就是dll的加載地址，然后加上搜索到的跳板指令偏移pos便是最終地址。jmp esp指令的二進制表示為0xffe4，因此搜索算法就是搜索dll內這樣的字節數據即可。
雖然如此，上述的攻擊方式還不夠好。因為在esp后繼續追加shellcode代碼會將上級函數的棧幀淹沒，這樣做並沒有什么好處，甚至可能會帶來運行時問題。既然被溢出的函數棧幀內提供了緩沖區，我們還是把核心的shellcode放在緩沖區內，而在esp之后放上跳轉指令轉移到原本的緩沖區位置。由於這樣做使代碼的位置在esp指針之前，如果shellcode中使用了push指令便會讓esp指令與shellcode代碼越來越近，甚至淹沒自身的代碼。這顯然不是我們想要的結果，因此我們可以強制抬高esp指針，使它在shellcode之前（低地址位置），這樣就能在shellcode內正常使用push指令了。
圖6 調整shellcode與棧指針
調整代碼的內容很簡單：
jmp esp
第一條指令抬高了棧指針到shellcode之前。X代表shellcode起始地址與esp的偏移。如果shellcode從緩沖區起始位置開始，那么就是buffer的地址偏移。這里不使用sub esp,X指令主要是避免X的高位字節為0的問題，很多情況下緩沖區溢出是針對字符串緩沖區的，如果出現字節0會導致緩沖區截斷，從而導致溢出失敗。
第二條指令就是跳轉到shellcode的起始位置繼續執行。（又是jmp esp！）
通過上述方式便能獲得一個較為穩定的棧溢出攻擊。
五、shellcode構造
shellcode實質是指溢出后執行的能開啟系統shell的代碼。但是在緩沖區溢出攻擊時，也可以將整個觸發緩沖區溢出攻擊過程的代碼統稱為shellcode，按照這種定義可以把shellcode分為四部分：
1、核心shellcode代碼，包含了攻擊者要執行的所有代碼。
2、溢出地址，是觸發shellcode的關鍵所在。
3、填充物，填充未使用的緩沖區，用於控制溢出地址的位置，一般使用nop指令填充——0x90表示。
4、結束符號0，對於符號串shellcode需要用0結尾，避免溢出時字符串異常。
前邊一直在圍繞溢出地址討論，並解決了shellcode組織的問題，而最核心的代碼如何構造並未提及——即攻擊成功后做的事情。其實一旦緩沖區溢出攻擊成功后，如果被攻擊的程序有系統的root權限——比如系統服務程序，那么攻擊者基本上可以為所欲為了！但是我們需要清楚的是，核心shellcode必須是二進制代碼形式。而且shellcode執行時是在遠程的計算機上，因此shellcode是否能通用是一個很復雜的問題。我們可以用一段簡單的代碼實例來說明這個問題。
緩沖區溢出成功后，一般大家都會希望開啟一個遠程的shell控制被攻擊的計算機。開啟shell最直接的方式便是調用C語言的庫函數system，該函數可以執行操作系統的命令，就像我們在命令行下執行命令那樣。假如我們執行cmd命令——在遠程計算機上啟動一個命令提示終端（我們可能還不能和它交互，但是可以在這之前建立一個遠程管道等），這里僅作為實例測試。
為了使system函數調用成功，我們需要將“cmd”字符串內容壓入棧空間，並將其地址壓入作為system函數的參數，然后使用call指令調用system函數的地址，完成函數的執行。但是這樣做還不夠，如果被溢出的程序沒有加載C語言庫的話，我們還需要調用Windows的API Loadlibrary加載C語言的庫msvcrt.dll，類似的我們也需要為字符串“msvcrt.dll”開辟棧空間。
push 0x3f3f6c6c ; //ll??
push 0x642e7472 ; //rt.d
push 0x6376736d ; //msvc
mov [esp+ 10],ebx ; //'?'->'0'
mov [esp+ 11],ebx ; //'?'->'0'
mov eax,esp ; //"msvcrt.dll"地址
push eax ; //"msvcrt.dll"
mov eax,0x77b62864 ; //kernel32.dll:LoadLibraryA
call eax ; //LoadLibraryA("msvcrt.dll")
add esp, 16
push 0x3f646d63 ; //"cmd?"
mov [esp+ 3],ebx ; //'?'->'\0'
mov eax,esp ; //"cmd"地址
push eax ; //"cmd"
mov eax,0x774ab16f ; //msvcrt.dll:system
call eax ; //system("cmd")
add esp, 8
上述匯編代碼實質上是如下兩個函數調用語句：
system(“cmd”);
不過在構造這段匯編代碼時需要注意不能出現字節0，為了填充字符串的結束字符，我們使用已經初始化為0的ebx寄存器代替。另外，在對庫函數調用的時候需要提前計算出函數的地址，如Loadlibrary函數的0x77b62864。計算方式如下：
{
HINSTANCE handle=LoadLibraryA(dll_name); // 獲取dll加載地址
return ( int)GetProcAddress(handle,func_name);
}
這個函數地址是在本地計算的，如果被攻擊計算機的操作系統版本差別較大的話，這個地址可能是錯誤的。不過在《0day安全：軟件漏洞分析技術》中，作者提供了一個更好的方式，感興趣的讀者可以參考該書提供的代碼。因此構造一個通用的shellcode並非十分容易，如果想讓攻擊變得有效的話。
六、匯編語言自動轉換
寫出shellcode后（無論是簡單的還是通用的），我們還需要將這段匯編代碼轉換為機器代碼。如果讀者對x86匯編十分熟悉的話，選擇手工敲出二進制代碼的話也未嘗不可。不過我們都希望能讓計算機幫助做完這些事，既然開發環境提供了編譯器，用它們幫忙何樂而不為呢？既不用OllyDbg工具，也不適用其他的第三方工具，我們寫一個簡單的函數來完成這個工作。
int dumpCode(unsigned char*buffer)
{
goto END ; // 略過匯編代碼
BEGIN:
__asm
{
// 在這里定義任意的合法匯編代碼
}
END:
// 確定代碼范圍
UINT begin,end;
__asm
{
mov eax,BEGIN ;
mov begin,eax ;
mov eax,END ;
mov end,eax ;
}
// 輸出
int len=end-begin;
memcpy(buffer,( void*)begin,len);
// 四字節對齊
int fill=(len-len% 4)% 4;
while(fill--)buffer[len+fill]= 0x90;
// 返回長度
return len+fill;
}
因為C++是支持嵌入式匯編代碼的，因此在函數內的匯編代碼都會被整成編譯為二進制代碼。實現二進制轉換的基本思想是讀取編譯器最終生成的二進制代碼段數據，將數據導出到指定的緩沖區內。為了鎖定嵌入式匯編代碼的位置和長度，我們定義了兩個標簽BEGIN和END。這兩個標簽在匯編語言級別會被解析為實際的線性地址，但是在高級語言級是無法直接使用這兩個標簽值的，只能使用goto語句跳轉使用它們。但是我們可以順水推舟，使用兩個局部變量在匯編級記錄這兩個標簽的值！
UINT begin,end;
__asm
{
mov eax,BEGIN ;
mov begin,eax ;
mov eax,END ;
mov end,eax ;
}
這樣就可以得到嵌入式匯編的代碼范圍了，使用memcpy操作將代碼數據拷貝到目標緩沖區即可（后邊還用nop指令將代碼按照四字節對齊）。不過我們還需要注意一個問題，嵌入式匯編在函數執行時也會執行，這顯然不可以，我們只是把它當作數據而已（是數據？還是代碼？），因此在函數開始的地方我們使用goto語句直接跳轉到嵌入式會變語句的結尾——END標簽！
七、攻擊測試
按照上述內容，相信不難構造出一個簡單的shellcode並攻擊之前提供的漏洞函數。但是如果使用VS2010測試的話可能會碰到很多問題。經過大量的調試和資料查詢，我們需要設置三處VS的項目屬性。
1、配置->配置屬性->C/C++->基本運行時檢查=默認值，避免被檢測棧幀失衡。
2、配置->配置屬性->C/C++->緩沖區安全檢查=否，避免識別緩沖區溢出漏洞。
3、配置->配置屬性->鏈接器->高級->數據執行保護(DEP)=否，避免堆棧段不可執行。
從這三處設置看來，目前的編譯器已經針對緩沖區溢出攻擊做了大量的保護工作（顯然這會降低程序的執行性能，因此允許用戶配置），使得傳統的緩沖區溢出攻擊變得沒那么“猖狂”了，但是在計算機安全領域，“道高一尺，魔高一丈”，總有人會找到更隱蔽的攻擊方式讓編譯器開發者措手不及。本文除了分析緩沖區溢出攻擊的原理之外，更希望讀者能從中感受到代碼安全的重要性，並結合編譯器提供的安全功能讓自己的代碼更加安全高效。