深度探索編譯器安全檢查

簡介
   安全是高質量軟件的重點關注方面，最讓人害怕、最多被誤解的就是緩沖區溢出。現在，提及緩沖區溢出足以讓人們停下來，仔細聽。太頻繁了，技術細節丟失在抄本中，大部分人們對于這種基礎的、值得關注的方面離開了。為了解決這個問題，Visual C++ .NET引入了安全檢查來幫助開發者確定緩沖區溢出。

什么是緩沖區溢出？

   緩沖區是一塊內存，通常是數組的形式。當沒有校驗數組的長度時，可能會寫出緩沖區的邊界。如果這樣的行為發生的地址比緩沖區的內存地址高，稱為緩沖區溢出；類似的，如果這樣的行為發生的地址比緩沖區的內存地址低，稱為緩沖區下溢。緩沖區下溢的發生率明顯少于緩沖區溢出，但是，正如本文的后面所描述，它確實發生過。向一個正在運行進程注入代碼的緩沖區溢出被稱為可以用緩沖區溢出。

   一些文檔化的函數，例如strcpy，gets，scanf，sprintf，strcat等，本身很容易受到緩沖區溢出的攻擊，所以不推薦使用他們。一個簡單的例子說明了這些函數的危險性：

int vulnerable1(char * pStr) { 
        int nCount = 0; 
        char pBuff[_MAX_PATH]; 
 
        strcpy(pBuff, pStr); 
        for(; pBuff; pBuff++) 
               if (*pBuff == '\\') nCount++; 
        return nCount; 
}

   這些代碼有個明顯的弱點 —如果由pStr指向的緩沖區長度大于_MAX_PATH ,那么pBuffer參數可能溢出。如果包含一句assert(strlen(pStr) < _MAX_PATH)就能夠在debug版本下發現這個錯誤，但是release版本不行。用這些容易受到攻擊的函數被認為是壞的實踐。技術上來講更不容易受到攻擊的相似的函數確實存在，如strncpy，strncat和memcpy。這些函數的問題是開發者來驗證緩沖區的長度，而不是編譯器。下面的函數展示一個普遍的錯誤：

 

#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); 
}

   這種情況下，字節的個數用來標示緩沖區的大小，而不是字符的個數，于是發生了緩沖區溢出。為了修正這個可攻擊點，MultiByteToWideChar的最后一個參數因該使用sizeof(buf)/sizeof(buf[0]). vulnerable1 和vulnerable2都是很普遍的錯誤，并且可以很容易的預防。然而，如果由于代碼Reviewer的疏忽，這些潛在的安全漏洞可能發布到產品中。這就是為什么Visual C++ .NET引入了安全檢查，它可以阻止vulnerable1 和vulnerable2函數中的緩沖區溢出向容易受到攻擊的應用程序注入惡意代碼。

 

X86棧的分析

   為了理解如何利用緩沖區溢出以及安全檢查如何工作，必須完全理解堆棧的布局結構。在X86體系下，堆棧向下增長，意味著新創建數據的地址小于早期壓入棧中元素的地址。每一個函數創建一個新的、有如下布局的棧幀，注意高內存地址在列表的頂部：

·                     Function parameters

·                     Function return address

·                     Frame pointer

·                     Exception Handler frame

·                     Locally declared variables and buffers

·                     Callee save registers

從以上布局很明顯的可以看出，緩沖區溢出有可能覆蓋掉比該緩沖區分配的早的變量，異常處理幀，棧幀指針，返回地址，函數參數。為了接管程序的執行，一個值必須寫進數據中，該數據的值被裝載進EIP寄存器中。函數的返回地址就是一個這樣的數據。典型的利用緩沖區溢出是覆蓋函數返回地址，讓函數的返回指令將返回地址加載到EIP中。

數據元素按照如下方式存入棧中。函數調用之前將函數的參數壓入棧中。參數從右到左被壓入棧中。CALL指令將函數的返回地址壓入棧中，它存儲EIP寄存器的當前值。棧幀指針是前一個EB寄存器的值，當沒有發生FPO優化時，也壓入棧中。因此，棧幀指針不總是在棧中。如果函數包括了try/catch 或者任何其他形式的異常處理結構，編譯器將在棧中包含異常處理信息。之后，是局部聲明的變量和分配的緩沖區。這些分配的順序可能根據優化實施而作改變。最后是調用者保存的寄存器如ESI，EDI，EBX，如果他們在函數執行時被使用。

運行時檢查

   緩沖區溢出是c、c++程序員普遍犯的錯誤，也是潛在的最危險的。Visual C++ .NET提供了工具，它可以使開發者在開發階段很容易發現這些錯誤并修正。Visual C++ 6.0中的/GZ開關在Visual C++ .NET中的/RTC1中獲得了新生。/RTC1開關是/RTsu的別名，其中s代表堆棧檢查，u代表未初始化變量檢查。所有在堆棧中分配的緩沖區在邊界處設置了標簽。因此，緩沖區溢出、下溢可以被捕捉。盡管小的緩沖區溢出可能不會改變程序的執行，它可以改變附近的數據，而這都不會被覺察到。

   運行時檢查對于那些不僅想寫安全的代碼、而且關心編寫正確代碼的基本問題的開發者很有幫助。然而運行時檢查僅僅工作在debug版本下，該特性從沒有設計為在產品代碼中可用。但是，在產品代碼中進行這樣的檢查有很明顯的價值。做這些運行時檢查需要一小部分的性能損失。結果，Visual C++ .NET引入了/GS開關。

 

/GS開關做什么

/GS開關在緩沖區和返回地址間提供了一個“Speed bump”或cookie。如果一個溢出覆蓋了返回地址，那么它也覆蓋了放在緩沖區和他之間的Cookie，新的堆棧布局如下：

·                     Function parameters

·                     Function return address

·                     Frame pointer

·                     Cookie

·                     Exception Handler frame

·                     Locally declared variables and buffers

·                     Callee save

Cookie在以后會更詳細的檢查。隨著這些安全檢查的加入，函數的執行也改變了。首先，當一個函數執行時，第一條要執行的指令在函數的prolog中。至少，prolog為堆棧中的局部變量分配空間，例如如下指令：

sub esp,20h

這條指令為函數中的局部變量預留了32字節。當函數使用/GS開關編譯時，函數prolog將預留另外的4個字節，三個如下另外的指令：

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和返回地址進行XOR操作，最后將cookie存儲在緊挨著返回地址的下面。從以上來看，函數象正常一樣執行。當函數返回時，最后要執行的是函數的epilog，它和prolog正好相反。如果沒有安全檢查，它將回收堆棧空間、返回，就像如下指令：

add esp,20h 
ret

當使用/GS編譯時，安全檢查也放在epilog中：
mov ecx,dword ptr [esp+20h] 
xor ecx,dword ptr [esp+24h] 
add esp,24h 
jmp __security_check_cookie (4010B2h)



查詢堆棧的cookie的拷貝，然后和返回地址進行XOR操作，ECX寄存器應該包含和存儲在 __security_cookie變量中的原始cookie相同的內容。接著回收堆棧空間，然后不是RET指令，而是執行JMP指令，跳轉到__security_check_cookie例程。

__security_check_cookie例程是很直觀的。如果cookie沒有被改變，它執行RET指令并結束函數調用。否則，它調用report_failure函數，report_failure接著調用__security_error_handler(_SECERR_BUFFER_OVERRUN, NULL)。這些函數都定義在C 運行庫（CRT）的源文件seccook.c中。

錯誤處理器

 
   使這些安全檢查起作用需要CRT的支持。當安全檢查失敗時，程序的控制需要交給__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); 
}

缺省情況下，安全檢查失敗的應用程序彈出顯示信息為” Buffer overrun detected!”的對話框，當關閉對話框后終止應用程序。CRT庫提供給開發者定制不同的、能夠更好的處理緩沖區溢出的處理器功能。函數__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 
}



   緩沖區溢出發生時，將會向控制臺窗口打印一條消息，而不是彈出消息窗口。盡管用戶處理器沒有顯示的終止程序，但是當處理器返回時，__security_error_handler通過調用_exit(3)來終止程序。函數__security_error_handler 和_set_security_error_handler都在CRT的secfail.c文件中

討論在用戶處理器中應該怎么做是有用的。普遍的動作時拋出異常。然而，因為異常信息存儲在堆棧中，拋出異常會將控制傳遞給異常棧。為了防止這種行為發生，__security_error_handler函數中調用用戶函數時使用try/__except來捕捉所有異常，然后終止程序。開發者不應該調用DebugBreak因為它會導致異常，也不應該調用longjmp.用戶處理器應該做的是報告錯誤，盡可能創建一個日志以便修正這個問題。

有時，開發者或許想重寫函數__security_error_handler，而不是用函數_set_security_error_handler來達到同樣的目的。重寫容易出錯，主處理器非常重要，如果沒有正確的實現將導致危險的結果。

Cookie的值

Cookie是一個和指針同樣大小的隨機數，意味著在X86體系下，cookie是4個字節長。它的值存儲在CRT全局變量__security_cookie中。它的值由在CRT seccinit.c文件中的函數__security_init_cookie來初始化。Cookie的隨機性來自于CPU處理器的計數器。每一個影像文件（使用/GS編譯的DLL、EXE ）在裝載時有一個不同的cookie。

當時用/GS編譯器開關編譯程序時可能有兩個問題。第一、不包含CRT支持的程序

將缺少隨機的cookie，因為CRT初始化時調用__security_init_cookie。如果在裝載時cookie沒有被初始化，如果有緩沖區溢出，應用程序還是有可能被攻擊。為了解決這個問題，應用程序在啟動時需要顯示的調用__security_init_cookie。第二、調用文檔化的函數來初始化的

遺留的應用程序可能遇到不可預期的安全檢查失敗。例如下面的例子：

DllEntryPoint() {
         char buf[_MAX_PATH]; // A buffer that triggers security checks 
         
        _CRT_INIT(); 
         
}



   問題是_CRT_INIT改變了已經存在的用來安全檢查的cookie的值。因為cookie的值在函數退出時和原來的值不同，安全檢查認為發生了緩沖區溢出。解決辦法是避免在調用_CRT_INIT之前聲明緩沖區。現在可以使用_alloca在堆棧上分配緩沖區作為回避方法，因為如果使用函數_alloca分配緩沖區，編譯器不會產生安全檢查。這種回避方法不保證在以后的Visual C++版本中適用。

性能影響

必須平衡程序的性能和安全檢查。Visual C++編譯器組致力于將性能影響降低到最小。大多說情況下，性能影響不超過2%。實際上，經驗顯示對大多說的應用程序、包括高性能的服務器端程序來講，性能影響是微乎其微的。

使性能不受影響的最重要的因素是只有那些容易受到攻擊的函數才執行安全檢查。現在，容易受到攻擊的函數為在堆棧中分配緩沖區的函數。字符串緩沖區如果分配多于四個字節、緩沖區中每個元素時1到2個字節，就容易受到攻擊。小緩沖區不容易受到攻擊并且限制進行安全檢查的函數的數量就限制了代碼的增長。大部分的可執行程序因為適用/GS編譯引起的代碼增長時微乎其微的。

例子

              因此，/GS開關并沒有修正緩沖區溢出，但是它可以阻止攻擊者利用緩沖區進行攻擊。當時用/GS開關編譯vulnerable1 、vulnerable2時，溢出就不會被利用。緩沖區溢出發生在最后一個動作的函數可以免于被攻擊。因為如果溢出發生在函數執行的早期，安全檢查或者沒有機會執行、或者安全檢查本身已被攻擊，象如下例子。

例子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; 
}

              這種情況下，在棧中分配了含有許函數的對象的指針。因為對象含有虛函數，對象包含一個vtable指針。供給者能提供一個惡意的pStr并溢出buf。函數返回前，delete操作符調用vuln的虛函數。調用需要在vtable中查找析構函數，它已經被接管了。在函數返回前，程序已經北接管，所以安全檢查根本沒有檢測到緩沖區溢出發生。

例子2

void vulnerable4(char *bBuff, in cbBuff) {
         char bName[128];
         void (*func)() = MyFunction; 
        memcpy(bName, bBuff, cbBuff); 
        (func)(); 
}



   這種情況下，函數容易受到指針修改攻擊。當編譯器為這兩個局部變量分配空間時，它把func變量放在bName之前。因為這種布局優化器可以提升代碼的效率。很不幸，這允許攻擊者一個為bBuff提供惡意的值。攻擊者同樣可以提供cbBuff的值，它標示著bBuff的大小。函數忽略了驗證cbBuff小于等于128。調用memcpy導致了緩沖區溢出，覆蓋了func的值。因為在vulnerable4返回之前首先調用func，在進行安全檢查之前，代碼已經被攻擊了。

例子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; 
}



   這個程序展示了一個特別難的問題，因為它使用了結構化異常處理。如前面提及，使用異常處理的函數將把異常處理信息，例如合適的異常處理函數，放在棧中。本例中，main函數的異常處理幀因為函數vulnerable5的缺陷而可能被攻擊。攻擊者利用溢出buf來破壞pch、main函數的異常處理幀。因為vulnerable5函數后來引用了pch，如果攻擊者覆蓋它的值為0，這將導致訪問異常。在堆棧展開的過程中，操作系統在異常處理幀中查找處理該異常的異常處理函數。因為異常處理幀已經被破壞，操作系統可能將程序的控制權交給由攻擊者提供的任意代碼。安全檢查將不能夠檢查這樣的緩沖區溢出，因為函數沒有正常返回。

近來一些很流行的攻擊都是利用異常處理。其中最流行的Code Red病毒出現在2001年夏。Window XP已經創建了一個環境，在該環境下，通過異常處理進行攻擊將會更難，因為異常處理函數的地址不在棧中，而且調用異常處理函數之前清除所有的寄存器的值。

例子4

void vulnerable6(char * pStr) { 
        char buf[_MAX_PATH]; 
        int * pNum; 
        strcpy(buf, pStr); 
        sscanf(buf, "%d", pNum); 
}



   不象以前其他的例子，當時用/GS開關編譯此函數時，攻擊者不能簡單的通過緩沖區溢出來獲得程序的控制權。如果想獲得程序的控制權需要兩階段的攻擊。pNum將被分配在buf之前使得它可以被pStr提供的任意的值重寫。攻擊者將不得不選擇四個字節進行重寫。如果緩沖區重寫超過了cookie，存儲在user_handle中的用戶提供的處理器或者或者存儲在__security_cookie中的默認處理器會接管程序的運行。如果沒有覆蓋cookie，攻擊者將選擇函數的返回地址作作為不包含安全檢查的函數。這種情況下，程序正常的執行，從函數中正常返回，沒有意識到緩沖區溢出；一段時間后，程序悄悄的被接管。

容易受到攻擊的代碼可能受到另外的攻擊如，發生在堆中的緩沖區溢出，它不能夠被/GS開關檢查出來。數組索引越界攻擊，它對數組中的某一個位置進行存取，而不是對數組進行連續寫入，這樣的問題/GS開關也不能檢查出來。一個未檢查的數組索引可以訪問內存的任意部分，而不會修改cookie的內容。另外一種未檢查的索引是有符號、無符號的不匹配。如果索引是有符號整數，簡單的驗證索引小于數組的大小也是不夠的。最后，/GS開關不能夠檢查緩沖區下溢。

結論

              很明顯，緩沖區溢出是應用程序的一個非常關鍵的缺陷。沒有比寫出緊湊、安全的代碼更重要。盡管大多數觀點認為，少量的緩沖區溢出很難被發現。在編寫安全代碼方面，/GS開關對開發者是很有幫助的。但是，它解決不了代碼中的緩沖區溢出的問題。盡管安全檢查在某種程度上阻止了緩沖區被利用，但程序仍然終止了，一種拒絕服務的攻擊，特別是服務器端代碼。使用/GS開關是一種安全的方法來減少在沒有意識到的情況下，受到緩沖區溢出的攻擊。

              盡管存在能夠標記可能受到攻擊的代碼的工具，例如本文所討論的，但是他們都是由缺點的。被好的代碼Review人員檢查過得好的代碼比什么都更可靠。Michael Howard 和David LeBlanc 的< Writing Secure Code>在編寫高度安全的應用程序方面，提供了很多其他的、可以降低被攻擊的方法。

posted on 2009-12-21 13:38 楊粼波 閱讀(908) 評論(0)  編輯 收藏 引用