轉(zhuǎn)載：網(wǎng)絡(luò)。
作者：Brandon Bray (MSFT)
譯者：SmartTech
簡介
安全是高質(zhì)量軟件的重點關(guān)注方面，最讓人害怕、最多被誤解的就是緩沖區(qū)溢出。現(xiàn)在，提及緩沖區(qū)溢出足以讓人們停下來，仔細(xì)聽。太頻繁了，技術(shù)細(xì)節(jié)丟失在抄本中，大部分人們對于這種基礎(chǔ)的、值得關(guān)注的方面離開了。為了解決這個問題，Visual C++ .NET引入了安全檢查來幫助開發(fā)者確定緩沖區(qū)溢出。
什么是緩沖區(qū)溢出？
緩沖區(qū)是一塊內(nèi)存，通常是數(shù)組的形式。當(dāng)沒有校驗數(shù)組的長度時，可能會寫出緩沖區(qū)的邊界。如果這樣的行為發(fā)生的地址比緩沖區(qū)的內(nèi)存地址高，稱為緩沖區(qū)溢出；類似的，如果這樣的行為發(fā)生的地址比緩沖區(qū)的內(nèi)存地址低，稱為緩沖區(qū)下溢。緩沖區(qū)下溢的發(fā)生率明顯少于緩沖區(qū)溢出，但是，正如本文的后面所描述，它確實發(fā)生過。向一個正在運行進(jìn)程注入代碼的緩沖區(qū)溢出被稱為可以用緩沖區(qū)溢出。
一些文檔化的函數(shù)，例如strcpy，gets，scanf，sprintf，strcat等，本身很容易受到緩沖區(qū)溢出的攻擊，所以不推薦使用他們。一個簡單的例子說明了這些函數(shù)的危險性：
int vulnerable1(char * pStr) 
{
int nCount = 0;
char pBuff[_MAX_PATH];
strcpy(pBuff, pStr);
for(; pBuff; pBuff++)
if (*pBuff == '\\') nCount++;
return nCount;
}
這些代碼有個明顯的弱點 —如果由pStr指向的緩沖區(qū)長度大于_MAX_PATH ,那么pBuffer參數(shù)可能溢出。如果包含一句assert(strlen(pStr) < _MAX_PATH)就能夠在debug版本下發(fā)現(xiàn)這個錯誤，但是release版本不行。用這些容易受到攻擊的函數(shù)被認(rèn)為是壞的實踐。技術(shù)上來講更不容易受到攻擊的相似的函數(shù)確實存在，如strncpy，strncat和memcpy。這些函數(shù)的問題是開發(fā)者來驗證緩沖區(qū)的長度，而不是編譯器。下面的函數(shù)展示一個普遍的錯誤：
#define BUFLEN 16
void vulnerable2(void)
{
wchar_t buf[BUFLEN];
int ret;
ret = MultiByteToWideChar(CP_ACP, 0, "1234567890123456789", -1, buf, sizeof(buf));
printf("%d\n", ret);
}
這種情況下，字節(jié)的個數(shù)用來標(biāo)示緩沖區(qū)的大小，而不是字符的個數(shù)，于是發(fā)生了緩沖區(qū)溢出。為了修正這個可攻擊點，MultiByteToWideChar的最后一個參數(shù)因該使用sizeof(buf)/sizeof(buf[0]). vulnerable1 和vulnerable2都是很普遍的錯誤，并且可以很容易的預(yù)防。然而，如果由于代碼Reviewer的疏忽，這些潛在的安全漏洞可能發(fā)布到產(chǎn)品中。這就是為什么Visual C++ .NET引入了安全檢查，它可以阻止vulnerable1 和vulnerable2函數(shù)中的緩沖區(qū)溢出向容易受到攻擊的應(yīng)用程序注入惡意代碼。
X86棧的分析
為了理解如何利用緩沖區(qū)溢出以及安全檢查如何工作，必須完全理解堆棧的布局結(jié)構(gòu)。在X86體系下，堆棧向下增長，意味著新創(chuàng)建數(shù)據(jù)的地址小于早期壓入棧中元素的地址。每一個函數(shù)創(chuàng)建一個新的、有如下布局的棧幀，注意高內(nèi)存地址在列表的頂部：
· Function parameters
· Function return address
· Frame pointer
· Exception Handler frame
· Locally declared variables and buffers
· Callee save registers
從以上布局很明顯的可以看出，緩沖區(qū)溢出有可能覆蓋掉比該緩沖區(qū)分配的早的變量，異常處理幀，棧幀指針，返回地址，函數(shù)參數(shù)。為了接管程序的執(zhí)行，一個值必須寫進(jìn)數(shù)據(jù)中，該數(shù)據(jù)的值被裝載進(jìn)EIP寄存器中。函數(shù)的返回地址就是一個這樣的數(shù)據(jù)。典型的利用緩沖區(qū)溢出是覆蓋函數(shù)返回地址，讓函數(shù)的返回指令將返回地址加載到EIP中。
數(shù)據(jù)元素按照如下方式存入棧中。函數(shù)調(diào)用之前將函數(shù)的參數(shù)壓入棧中。參數(shù)從右到左被壓入棧中。CALL指令將函數(shù)的返回地址壓入棧中，它存儲EIP寄存器的當(dāng)前值。棧幀指針是前一個EB寄存器的值，當(dāng)沒有發(fā)生FPO優(yōu)化時，也壓入棧中。因此，棧幀指針不總是在棧中。如果函數(shù)包括了try/catch 或者任何其他形式的異常處理結(jié)構(gòu)，編譯器將在棧中包含異常處理信息。之后，是局部聲明的變量和分配的緩沖區(qū)。這些分配的順序可能根據(jù)優(yōu)化實施而作改變。最后是調(diào)用者保存的寄存器如ESI，EDI，EBX，如果他們在函數(shù)執(zhí)行時被使用。
運行時檢查
緩沖區(qū)溢出是c、c++程序員普遍犯的錯誤，也是潛在的最危險的。Visual C++ .NET提供了工具，它可以使開發(fā)者在開發(fā)階段很容易發(fā)現(xiàn)這些錯誤并修正。Visual C++ 6.0中的/GZ開關(guān)在Visual C++ .NET中的/RTC1中獲得了新生。/RTC1開關(guān)是/RTsu的別名，其中s代表堆棧檢查，u代表未初始化變量檢查。所有在堆棧中分配的緩沖區(qū)在邊界處設(shè)置了標(biāo)簽。因此，緩沖區(qū)溢出、下溢可以被捕捉。盡管小的緩沖區(qū)溢出可能不會改變程序的執(zhí)行，它可以改變附近的數(shù)據(jù)，而這都不會被覺察到。
運行時檢查對于那些不僅想寫安全的代碼、而且關(guān)心編寫正確代碼的基本問題的開發(fā)者很有幫助。然而運行時檢查僅僅工作在debug版本下，該特性從沒有設(shè)計為在產(chǎn)品代碼中可用。但是，在產(chǎn)品代碼中進(jìn)行這樣的檢查有很明顯的價值。做這些運行時檢查需要一小部分的性能損失。結(jié)果，Visual C++ .NET引入了/GS開關(guān)。
/GS開關(guān)做什么
/GS開關(guān)在緩沖區(qū)和返回地址間提供了一個“Speed bump”或cookie。如果一個溢出覆蓋了返回地址，那么它也覆蓋了放在緩沖區(qū)和他之間的Cookie，新的堆棧布局如下：
· Function parameters
· Function return address
· Frame pointer
· Cookie
· Exception Handler frame
· Locally declared variables and buffers
· Callee save
Cookie在以后會更詳細(xì)的檢查。隨著這些安全檢查的加入，函數(shù)的執(zhí)行也改變了。首先，當(dāng)一個函數(shù)執(zhí)行時，第一條要執(zhí)行的指令在函數(shù)的prolog中。至少，prolog為堆棧中的局部變量分配空間，例如如下指令：
sub esp,20h
這條指令為函數(shù)中的局部變量預(yù)留了32字節(jié)。當(dāng)函數(shù)使用/GS開關(guān)編譯時，函數(shù)prolog將預(yù)留另外的4個字節(jié)，三個如下另外的指令：
sub esp,24h
mov eax,dword ptr [___security_cookie (408040h)]
xor eax,dword ptr [esp+24h]
mov dword ptr [esp+20h],eax
prolog包含了一個提取cookie拷貝的指令，接著一條指令是將cookie和返回地址進(jìn)行XOR操作，最后將cookie存儲在緊挨著返回地址的下面。從以上來看，函數(shù)象正常一樣執(zhí)行。當(dāng)函數(shù)返回時，最后要執(zhí)行的是函數(shù)的epilog，它和prolog正好相反。如果沒有安全檢查，它將回收堆棧空間、返回，就像如下指令：
當(dāng)使用/GS編譯時，安全檢查也放在epilog中：
mov ecx,dword ptr [esp+20h]
xor ecx,dword ptr [esp+24h]
add esp,24h
jmp __security_check_cookie (4010B2h)
查詢堆棧的cookie的拷貝，然后和返回地址進(jìn)行XOR操作，ECX寄存器應(yīng)該包含和存儲在 __security_cookie變量中的原始cookie相同的內(nèi)容。接著回收堆棧空間，然后不是RET指令，而是執(zhí)行JMP指令，跳轉(zhuǎn)到__security_check_cookie例程。
__security_check_cookie例程是很直觀的。如果cookie沒有被改變，它執(zhí)行RET指令并結(jié)束函數(shù)調(diào)用。否則，它調(diào)用report_failure函數(shù)，report_failure接著調(diào)用__security_error_handler(_SECERR_BUFFER_OVERRUN, NULL)。這些函數(shù)都定義在C 運行庫（CRT）的源文件seccook.c中。
錯誤處理器
使這些安全檢查起作用需要CRT的支持。當(dāng)安全檢查失敗時，程序的控制需要交給__security_error_handler，以下是它的處理概要：
void __cdecl __security_error_handler(int code, void *data)
{
if (user_handler != NULL) {
__try {
user_handler(code, data);
} __except (EXCEPTION_EXECUTE_HANDLER) {}
} else { //prepare outmsg
__crtMessageBoxA( outmsg, "Microsoft Visual C++ Runtime Library", MB_OK|MB_ICONHAND|MB_SETFOREGROUND|MB_TASKMODAL);
}
_exit(3);
}
缺省情況下，安全檢查失敗的應(yīng)用程序彈出顯示信息為” Buffer overrun detected!”的對話框，當(dāng)關(guān)閉對話框后終止應(yīng)用程序。CRT庫提供給開發(fā)者定制不同的、能夠更好的處理緩沖區(qū)溢出的處理器功能。函數(shù)__set_security_error_handler 通過在變量user_handler中存儲用戶提供的處理器的方式來安裝handler。以下例子說明：
void __cdecl report_failure(int code, void * unused)
{
if (code == _SECERR_BUFFER_OVERRUN)
printf("Buffer overrun detected!\n");
}
void main()
{
_set_security_error_handler(report_failure);
// More code follows
}
緩沖區(qū)溢出發(fā)生時，將會向控制臺窗口打印一條消息，而不是彈出消息窗口。盡管用戶處理器沒有顯示的終止程序，但是當(dāng)處理器返回時，__security_error_handler通過調(diào)用_exit(3)來終止程序。函數(shù)__security_error_handler 和_set_security_error_handler都在CRT的secfail.c文件中
討論在用戶處理器中應(yīng)該怎么做是有用的。普遍的動作時拋出異常。然而，因為異常信息存儲在堆棧中，拋出異常會將控制傳遞給異常棧。為了防止這種行為發(fā)生，__security_error_handler函數(shù)中調(diào)用用戶函數(shù)時使用try/__except來捕捉所有異常，然后終止程序。開發(fā)者不應(yīng)該調(diào)用DebugBreak因為它會導(dǎo)致異常，也不應(yīng)該調(diào)用longjmp.用戶處理器應(yīng)該做的是報告錯誤，盡可能創(chuàng)建一個日志以便修正這個問題。
有時，開發(fā)者或許想重寫函數(shù)__security_error_handler，而不是用函數(shù)_set_security_error_handler來達(dá)到同樣的目的。重寫容易出錯，主處理器非常重要，如果沒有正確的實現(xiàn)將導(dǎo)致危險的結(jié)果。
Cookie的值
Cookie是一個和指針同樣大小的隨機(jī)數(shù)，意味著在X86體系下，cookie是4個字節(jié)長。它的值存儲在CRT全局變量__security_cookie中。它的值由在CRT seccinit.c文件中的函數(shù)__security_init_cookie來初始化。Cookie的隨機(jī)性來自于CPU處理器的計數(shù)器。每一個影像文件（使用/GS編譯的DLL、EXE ）在裝載時有一個不同的cookie。
當(dāng)時用/GS編譯器開關(guān)編譯程序時可能有兩個問題。第一、不包含CRT支持的程序
將缺少隨機(jī)的cookie，因為CRT初始化時調(diào)用__security_init_cookie。如果在裝載時cookie沒有被初始化，如果有緩沖區(qū)溢出，應(yīng)用程序還是有可能被攻擊。為了解決這個問題，應(yīng)用程序在啟動時需要顯示的調(diào)用__security_init_cookie。第二、調(diào)用文檔化的函數(shù)來初始化的
遺留的應(yīng)用程序可能遇到不可預(yù)期的安全檢查失敗。例如下面的例子：
DllEntryPoint() {
char buf[_MAX_PATH]; // A buffer that triggers security checks
_CRT_INIT();
}
問題是_CRT_INIT改變了已經(jīng)存在的用來安全檢查的cookie的值。因為cookie的值在函數(shù)退出時和原來的值不同，安全檢查認(rèn)為發(fā)生了緩沖區(qū)溢出。解決辦法是避免在調(diào)用_CRT_INIT之前聲明緩沖區(qū)。現(xiàn)在可以使用_alloca在堆棧上分配緩沖區(qū)作為回避方法，因為如果使用函數(shù)_alloca分配緩沖區(qū)，編譯器不會產(chǎn)生安全檢查。這種回避方法不保證在以后的Visual C++版本中適用。
性能影響
必須平衡程序的性能和安全檢查。Visual C++編譯器組致力于將性能影響降低到最小。大多說情況下，性能影響不超過2%。實際上，經(jīng)驗顯示對大多說的應(yīng)用程序、包括高性能的服務(wù)器端程序來講，性能影響是微乎其微的。
使性能不受影響的最重要的因素是只有那些容易受到攻擊的函數(shù)才執(zhí)行安全檢查。現(xiàn)在，容易受到攻擊的函數(shù)為在堆棧中分配緩沖區(qū)的函數(shù)。字符串緩沖區(qū)如果分配多于四個字節(jié)、緩沖區(qū)中每個元素時1到2個字節(jié)，就容易受到攻擊。小緩沖區(qū)不容易受到攻擊并且限制進(jìn)行安全檢查的函數(shù)的數(shù)量就限制了代碼的增長。大部分的可執(zhí)行程序因為適用/GS編譯引起的代碼增長時微乎其微的。
例子
因此，/GS開關(guān)并沒有修正緩沖區(qū)溢出，但是它可以阻止攻擊者利用緩沖區(qū)進(jìn)行攻擊。當(dāng)時用/GS開關(guān)編譯vulnerable1 、vulnerable2時，溢出就不會被利用。緩沖區(qū)溢出發(fā)生在最后一個動作的函數(shù)可以免于被攻擊。因為如果溢出發(fā)生在函數(shù)執(zhí)行的早期，安全檢查或者沒有機(jī)會執(zhí)行、或者安全檢查本身已被攻擊，象如下例子。
例子1
class Vulnerable3 {
public:
int value;
Vulnerable3() { value = 0; }
virtual ~Vulnerable3() { value = -1; }
};
void vulnerable3(char * pStr) {
Vulnerable3 * vuln = new Vulnerable3;
char buf[20];
strcpy(buf, pStr);
delete vuln;
}
這種情況下，在棧中分配了含有許函數(shù)的對象的指針。因為對象含有虛函數(shù)，對象包含一個vtable指針。供給者能提供一個惡意的pStr并溢出buf。函數(shù)返回前，delete操作符調(diào)用vuln的虛函數(shù)。調(diào)用需要在vtable中查找析構(gòu)函數(shù)，它已經(jīng)被接管了。在函數(shù)返回前，程序已經(jīng)北接管，所以安全檢查根本沒有檢測到緩沖區(qū)溢出發(fā)生。
例子2
void vulnerable4(char *bBuff, in cbBuff) {
char bName[128];
void (*func)() = MyFunction;
memcpy(bName, bBuff, cbBuff);
(func)();
}
這種情況下，函數(shù)容易受到指針修改攻擊。當(dāng)編譯器為這兩個局部變量分配空間時，它把func變量放在bName之前。因為這種布局優(yōu)化器可以提升代碼的效率。很不幸，這允許攻擊者一個為bBuff提供惡意的值。攻擊者同樣可以提供cbBuff的值，它標(biāo)示著bBuff的大小。函數(shù)忽略了驗證cbBuff小于等于128。調(diào)用memcpy導(dǎo)致了緩沖區(qū)溢出，覆蓋了func的值。因為在vulnerable4返回之前首先調(diào)用func，在進(jìn)行安全檢查之前，代碼已經(jīng)被攻擊了。
例子3
int vulnerable5(char * pStr) {
char buf[32];
char * volatile pch = pStr;
strcpy(buf, pStr);
return *pch == '\0';
}
int main(int argc, char* argv[]) {
__try { vulnerable5(argv[1]); }
__except(2) { return 1; }
return 0;
}
這個程序展示了一個特別難的問題，因為它使用了結(jié)構(gòu)化異常處理。如前面提及，使用異常處理的函數(shù)將把異常處理信息，例如合適的異常處理函數(shù)，放在棧中。本例中，main函數(shù)的異常處理幀因為函數(shù)vulnerable5的缺陷而可能被攻擊。攻擊者利用溢出buf來破壞pch、main函數(shù)的異常處理幀。因為vulnerable5函數(shù)后來引用了pch，如果攻擊者覆蓋它的值為0，這將導(dǎo)致訪問異常。在堆棧展開的過程中，操作系統(tǒng)在異常處理幀中查找處理該異常的異常處理函數(shù)。因為異常處理幀已經(jīng)被破壞，操作系統(tǒng)可能將程序的控制權(quán)交給由攻擊者提供的任意代碼。安全檢查將不能夠檢查這樣的緩沖區(qū)溢出，因為函數(shù)沒有正常返回。
近來一些很流行的攻擊都是利用異常處理。其中最流行的Code Red病毒出現(xiàn)在2001年夏。Window XP已經(jīng)創(chuàng)建了一個環(huán)境，在該環(huán)境下，通過異常處理進(jìn)行攻擊將會更難，因為異常處理函數(shù)的地址不在棧中，而且調(diào)用異常處理函數(shù)之前清除所有的寄存器的值。
例子4
void vulnerable6(char * pStr) {
char buf[_MAX_PATH];
int * pNum;
strcpy(buf, pStr);
sscanf(buf, "%d", pNum);
}
不象以前其他的例子，當(dāng)時用/GS開關(guān)編譯此函數(shù)時，攻擊者不能簡單的通過緩沖區(qū)溢出來獲得程序的控制權(quán)。如果想獲得程序的控制權(quán)需要兩階段的攻擊。pNum將被分配在buf之前使得它可以被pStr提供的任意的值重寫。攻擊者將不得不選擇四個字節(jié)進(jìn)行重寫。如果緩沖區(qū)重寫超過了cookie，存儲在user_handle中的用戶提供的處理器或者或者存儲在__security_cookie中的默認(rèn)處理器會接管程序的運行。如果沒有覆蓋cookie，攻擊者將選擇函數(shù)的返回地址作作為不包含安全檢查的函數(shù)。這種情況下，程序正常的執(zhí)行，從函數(shù)中正常返回，沒有意識到緩沖區(qū)溢出；一段時間后，程序悄悄的被接管。
容易受到攻擊的代碼可能受到另外的攻擊如，發(fā)生在堆中的緩沖區(qū)溢出，它不能夠被/GS開關(guān)檢查出來。數(shù)組索引越界攻擊，它對數(shù)組中的某一個位置進(jìn)行存取，而不是對數(shù)組進(jìn)行連續(xù)寫入，這樣的問題/GS開關(guān)也不能檢查出來。一個未檢查的數(shù)組索引可以訪問內(nèi)存的任意部分，而不會修改cookie的內(nèi)容。另外一種未檢查的索引是有符號、無符號的不匹配。如果索引是有符號整數(shù)，簡單的驗證索引小于數(shù)組的大小也是不夠的。最后，/GS開關(guān)不能夠檢查緩沖區(qū)下溢。
結(jié)論
很明顯，緩沖區(qū)溢出是應(yīng)用程序的一個非常關(guān)鍵的缺陷。沒有比寫出緊湊、安全的代碼更重要。盡管大多數(shù)觀點認(rèn)為，少量的緩沖區(qū)溢出很難被發(fā)現(xiàn)。在編寫安全代碼方面，/GS開關(guān)對開發(fā)者是很有幫助的。但是，它解決不了代碼中的緩沖區(qū)溢出的問題。盡管安全檢查在某種程度上阻止了緩沖區(qū)被利用，但程序仍然終止了，一種拒絕服務(wù)的攻擊，特別是服務(wù)器端代碼。使用/GS開關(guān)是一種安全的方法來減少在沒有意識到的情況下，受到緩沖區(qū)溢出的攻擊。
盡管存在能夠標(biāo)記可能受到攻擊的代碼的工具，例如本文所討論的，但是他們都是由缺點的。被好的代碼Review人員檢查過得好的代碼比什么都更可靠。Michael Howard 和David LeBlanc 的< Writing Secure Code>在編寫高度安全的應(yīng)用程序方面，提供了很多其他的、可以降低被攻擊的方法。
引用英文原文：
http://www.codeproject.com/KB/tips/seccheck.aspx?msg=119784PDF下載：
http://www.shnenglu.com/Files/tx7do/Compiler%20Security%20Check.rar