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