當 David LeBlanc 和我確定《Writing Secure Code》(英文)一書的目錄時，我們明確地意識到必須著重介紹緩沖區溢出問題，因為已經有太多的開發人員在編寫代碼時犯了太多的此類錯誤，這些錯誤導致了可被人利用的緩沖區溢出的出現。在本文中，我將集中介紹為什么會出現緩沖區溢出及其修復的方法。

　　為什么會出現緩沖區溢出

　　出現緩沖區溢出需要具備很多條件，包括：

　　使用非類型安全的語言，如 C/C++。

　　以不安全的方式訪問或復制緩沖區。

　　編譯器將緩沖區放在內存中關鍵數據結構旁邊或鄰近的位置。

　　現在我們來仔細看看以上每種條件。

　　首先，緩沖區溢出主要出現在 C 和 C++ 中，因為這些語言不執行數組邊界檢查和類型安全檢查。C/C++ 允許開發人員創建非常接近硬件運行的程序，從而允許直接訪問內存和計算機寄存器。其結果可以獲得優異的性能;很難有任何應用程序能象編寫得很好的 C/C++ 應用程序運行得那樣快。其他語言中也會出現緩沖區溢出，但很少見。如果出現這種錯誤，通常不是由開發人員造成的，而是運行時環境的錯誤。

　　其次，如果應用程序從用戶(或攻擊者)那里獲取數據，并將數據復制到應用程序所維護的緩沖區中而未考慮目標緩沖區的大小，則可能造成緩沖區溢出。換句話說，代碼為緩沖區分配了 N 個字節，卻將多于 N 個字節的數據復制到該緩沖區中。這就象向 12 盎司的玻璃杯中注入 16 盎司的水一樣。那么多出的 4 盎司水到哪里去了呢?全溢出去了!

　　***后一點，也是***重要的一點，編譯器通常將緩沖區放在“令人感興趣的”數據結構旁邊。例如，當某個函數的緩沖區緊鄰堆棧，則在內存中該函數的返回地址緊靠在緩沖區之后。這時，如果攻擊者可以使該緩沖區發生溢出，他就可以覆蓋函數的返回地址，從而在返回函數時，返回到攻擊者定義的地址。其他令人感興趣的數據結構包括 C++ V 表、異常處理程序地址、函數指針等等。

　　下面我們來看一個示例。

　　以下代碼有什么錯誤?

　　void CopyData(char *szData) {

　　char cDest[32];

　　strcpy(cDest,szData);

　　// 使用 cDest

　　...

　　}

　　令人驚訝的是，這段代碼可能沒有什么錯誤!這完全取決于

　　CopyData()

　　的調用方式。例如，以下代碼是安全的：

　　char *szNames[] = {"Michael","Cheryl","Blake"};

　　CopyData(szName[1]);

　　這段代碼是安全的，因為名字是硬編碼的，并且知道每個字符串在長度上不超過 32 個字符，因此調用

　　strcpy

　　永遠是安全的。然而，如果

　　CopyData

　　和

　　szData

　　的******參數來自不可靠的源(如套接字或文件)，則

　　strcpy

　　將復制該數據，直到碰到空字符為止;如果此數據的長度大于 32 個字符，則

　　cDest

　　緩沖區將溢出，并且在內存中該緩沖區以外的任何數據將遭到破壞。不幸的是，在這里，遭到破壞的數據是來自

　　CopyData

　　的返回地址，這意味著當

　　CopyData

　　完成時，它仍然在由攻擊者指定的位置繼續執行。這真糟糕!

　　其他數據結構也同樣敏感。假設某個 C++ 類的 V 表遭到破壞，如下面這段代碼：

　　void CopyData(char *szData) {

　　char cDest[32];

　　CFoo foo;

　　strcpy(cDest,szData);

　　foo.Init();

　　}

　　此示例假定 CFoo 類具有虛方法，以及一個 V 表或該類方法的地址列表(與所有 C++ 類一樣)。如果由于

　　cDest

　　緩沖區被覆蓋而破壞了 V 表，則該類的任何虛方法(在此例中是

　　Init()

　　)都可能調用攻擊者指定的地址，而不是

　　Init()

　　的地址。順便說一句，如果認為您的代碼不調用任何 C++ 方法就安全了，那就錯了，因為有一個方法始終會被調用，即該類的虛析構函數!當然，如果某個類不調用任何方法，就應該想想它存在的必要了。

　　修復緩沖區溢出

　　現在，我們繼續討論一些更實際的內容 - 如何在您的代碼中刪除和防止緩沖區溢出。

　　遷移到托管代碼

　　在 2002 年 2 月和 3 月，我們舉辦了 Microsoft Windows? Security Push 活動。在此期間，我的工作組對 8,500 多位人員在設計、編寫、測試和記錄安全功能方面進行了培訓。我們為所有設計人員提出的一個建議就是，制定計劃，將相應的應用程序和工具從本機 Win32? C++ 代碼遷移到托管代碼。這樣做有多種原因，主要是有助于減少緩沖區溢出。在托管代碼中，很難創建出包含緩沖區溢出的代碼，因為所編寫的代碼不能直接訪問指針、計算機寄存器或內存。您應當考慮，或者至少要計劃將某些應用程序和工具遷移到托管代碼中。例如，管理工具就是一個很好的遷移對象。當然，我們也要現實一些，因為不可能在一個晚上將所有的應用程序從 C++ 遷移到 C# 或其他托管語言中。

　　遵循以下重要規則

　　當編寫 C 和 C++ 代碼時，應注意如何管理來自用戶的數據。如果某個函數具有來自不可靠源的緩沖區，請遵循以下規則：

　　要求代碼傳遞緩沖區的長度。

　　探測內存。

　　采取防范措施。

　　現在我們來仔細看看以上每種情況。

　　要求代碼傳遞緩沖區的長度

　　如果任何函數調用具有類似特征，將出現一個錯誤：

　　void Function(char *szName) {

　　char szBuff[MAX_NAME];

　　// 復制并使用 szName

　　strcpy(szBuff,szName);

　　}

　　此代碼的問題在于函數不能判斷

　　szName

　　的長度，這意味著將不能安全地復制數據。函數應知道

　　szName

　　的大?。?

　　void Function(char *szName, DWORD cbName) {

　　char szBuff[MAX_NAME];

　　// 復制并使用 szName

　　if (cbName < MAX_NAME)

　　strncpy(szBuff,szName,MAX_NAME-1);

　　}

　　然而，您不能想當然地信任

　　cbName

　　。攻擊者可以設置該名稱和緩沖區大小，因此必須進行檢查!

　　探測內存

　　如何判別

　　szName

　　和

　　cbName

　　是有效的?您相信用戶會提供有效的值嗎?一般來說，答案是否定的。驗證緩沖區大小是否有效的一個簡單方法是探測內存。以下代碼段顯示了如何在代碼的調試版中完成這一驗證過程：

　　void Function(char *szName, DWORD cbName) {

　　char szBuff[MAX_NAME];

　　#ifdef _DEBUG

　　// 探測

　　memset(szBuff, 0x42, cbName);

　　#endif

　　// 復制并使用 szName

　　if (cbName < MAX_NAME)

　　strncpy(szBuff,szName,MAX_NAME-1);

　　}

　　此代碼將嘗試向目標緩沖區寫入值 0x42。您可能會想，為什么要這樣做而不是直接復制緩沖區呢?通過向目標緩沖區的末尾寫入一個固定的已知值，可以在源緩沖區太大時，強制代碼失敗。同時這樣也可以在開發過程中及早發現開發錯誤。與其運行攻擊者的惡意有效代碼，還不如讓程序失敗。這就是不復制攻擊者的緩沖區的原因。

　　注意：您只能在調試版中這樣做，以便在測試過程中捕獲緩沖區溢出。

　　采取防范措施

　　說實話，探測雖然很有用，但它并不能使您免遭攻擊。真正安全的辦法是編寫防范性的代碼。您會注意到代碼已經具有防范性了。它將檢查進入函數的數據是否不超過內部緩沖區

　　szBuff

　　。然而，有些函數在處理或復制不可靠的數據時，如果使用不當，則會存在潛在的嚴重安全問題。這里的關鍵是不可靠的數據。在檢查代碼的緩沖區溢出錯誤時，應跟蹤數據在代碼中的流向，并檢查各種數據假設。當您意識到有些假設不正確時，您也許會驚異于所發現的錯誤。

　　需要注意的函數包括諸如 strcpy、strcat、gets 等常見函數。但也不能排除所謂的 strcpy 和 strcat 的“安全的 n 版本”- strncpy 和 strncat。這些函數被認為使用起來更安全、可靠，因為它們允許開發人員限制復制到目標緩沖區中的數據的大小。然而，開發人員在使用這些函數時也會出錯!請看以下這段代碼。您能看出其中的缺點嗎?

　　#define SIZE(b) (sizeof(b))

　　char buff[128];

　　strncpy(buff,szSomeData,SIZE(buff));

　　strncat(buff,szMoreData,SIZE(buff));

　　strncat(buff,szEvenMoreData,SIZE(buff));

　　如果您需要提示，請注意每個字符串處理函數的***后一個參數。要放棄嗎?在我給出答案之前，我經常會開玩笑說，如果您禁用“不安全”的字符串處理函數，而使用較為安全的 n 版本，則恐怕您要在修復新產生的錯誤中度過您的余生。以下便是原因所在。首先，***后那個參數不是目標緩沖區的總體大小。它是緩沖區剩余空間的大小，代碼每次向

　　buff

　　添加內容時，

　　buff

　　都會有實質的減小。第二個問題是，即使用戶傳遞了緩沖區大小，他們通常也是逐一減小的。那么在計算字符串大小時，您有沒有包含末尾的空字符?當我針對這個問題進行讀者調查時，通常是對半分。其中一半認為在計算緩沖區大小時確實要考慮末尾空字符，另外一半則不這么認為。第三，在某些情況下，n 版本可能不會以空字符作為結果字符串的結束字符，因此請一定要閱讀文檔。

　　如果編寫 C++ 代碼，請考慮使用 ATL、STL、MFC 或者您***喜歡的字符串處理類來處理字符串，而不要直接處理字節。******潛在的不足是可能出現性能的下降，但總的來說，大部分這些類的使用都會使代碼更加強大和可維護。

　　使用 /GS 進行編譯

　　Visual C++? .Net 中的這個新的編譯時選項會在某些函數的堆?？蚣苤胁迦胫?，有助于減少基于堆棧的緩沖區溢出的潛在弱點。請記住，此選項不會修復您的代碼，也不能刪除任何錯誤。它只是象一個棒球運動的捕手，幫助您減少某些類的緩沖區溢出變為可被人利用的緩沖區溢出的潛在可能性，以免攻擊者向過程中寫入代碼并執行?？梢园阉暈橐粋€很小的保險措施。請注意，對于使用 Win32 應用程序向導創建的新的本機 Win32 C++ 項目，將默認啟用此選項。此外，Windows .NET Server 編譯時也使用了此選項。有關詳細信息，請參閱 Brandon Bray 的 Compiler Security Checks In Depth(英文)。

　　排除隱患

　　下面我給出了一些代碼，其中至少包含一處安全隱患。您能找出來嗎?我將在下一篇文章中公布答案!

　　WCHAR g_wszComputerName[INTERNET_MAX_HOST_NAME_LENGTH + 1];

　　// 獲取服務器名稱并將其轉換為 Unicode 字符串。

　　BOOL GetServerName (EXTENSION_CONTROL_BLOCK *pECB) {

　　DWORD dwSize = sizeof(g_wszComputerName);

　　char szComputerName[INTERNET_MAX_HOST_NAME_LENGTH + 1];

　　if (pECB->GetServerVariable (pECB->ConnID,

　　"SERVER_NAME",

　　szComputerName,

　　&dwSize)) {

　　// 其余代碼被略去