基本介紹
溢出溢出是在你自己電腦上能夠運行的東西他可以全部做到，等於你的電腦就是他的了。在黑客頻頻攻擊、在系統漏洞層出不窮的今天，作為網路管理員、系統管理員的我們雖然在伺服器的安全上都下了不少功夫:諸如，及時的打上系統安全補丁、進行一些常規的安全配置,但是仍然不太可能每台伺服器都會在第一時間內給系統打上全新補丁。因此我們必需要在還未被入侵之前，通過一些系列安全設定，來將入侵者們擋在“安全門”之外。
溢出分類
1.1在程式的地址空間裡安排適當的代碼
1.1.1殖入法
攻擊者用被攻擊程式的緩衝區來存放攻擊代碼。 攻擊者向被攻擊的程式輸入一個字元串，程式會把這個字元串放到緩衝區里。這個字元串包含的數據是可以在這個被攻擊的硬體平台上運行的指令序列。
1.1.2利用已經存在的代碼
有時候，攻擊者想要的代碼已經在被攻擊的程式中了,攻擊者所要做的只是對代碼傳遞一些參數，然後使程式跳轉到指定目標。比如，在C語言中，攻擊代碼要求執行“exec("/bin/sh")”，而在libc庫中的代碼執行“exec(arg)”，其中arg是指向一個字元串的指針參數，那么攻擊者只要把傳入的參數指針指向"/bin/sh"，就可以調轉到libc庫中的相應的指令序列。
1.2控制程式轉移到攻擊代碼
這種方法旨在改變程式的執行流程，使之跳轉到攻擊代碼。最基本方法的就是溢出一個沒有邊界檢查或者其他弱點的緩衝區，這樣就擾亂了程式的正常的執行順序。通過溢出一個緩衝區，攻擊者可以用近乎暴力的方法改寫相鄰的程式空間而直接跳過了系統的檢查。
1.2.1激活紀錄（Activation Records）
每當一個函式調用發生時，調用者會在堆疊中留下一個激活紀錄，它包含了函式結束時返回的地址。攻擊者通過溢出這些自動變數，使這個返回地址指向攻擊代碼。通過改變程式的返回地址，當函式調用結束時，程式就跳轉到攻擊者設定的地址，而不是原先的地址。這類的緩衝區溢出被稱為“stack smashing attack”，是目前常用的緩衝區溢出攻擊方式。
1.2.2函式指針（Function Pointers）
C語言中，“void (* foo)()”聲明了一個返回值為void函式指針的變數foo。函式指針可以用來定位任何地址空間，所以攻擊者只需在任何空間內的函式指針附近找到一個能夠溢出的緩衝區，然後溢出這個緩衝區來改變函式指針。在某一時刻，當程式通過函式指針調用函式時，程式的流程就按攻擊者的意圖實現了！它的一個攻擊範例就是在Linux系統下的super probe程式。
1.2.3長跳轉緩衝區（Longjmp buffers）
在C語言中包含了一個簡單的檢驗/恢復系統，稱為setjmp/longjmp。意思是在檢驗點設定“setjmp(buffer)”，用“longjmp(buffer)”來恢復檢驗點。然而，如果攻擊者能夠進入緩衝區的空間，那么“longjmp(buffer)”實際上是跳轉到攻擊者的代碼。象函式指針一樣，longjmp緩衝區能夠指向任何地方，所以攻擊者所要做的就是找到一個可供溢出的緩衝區。一個典型的例子就是Perl 5.003，攻擊者首先進入用來恢復緩衝區溢出的的longjmp緩衝區，然後誘導進入恢復模式，這樣就使Perl的解釋器跳轉到攻擊代碼上了！
最簡單和常見的緩衝區溢出攻擊類型就是在一個字元串里綜合了代碼殖入和激活紀錄。攻擊者定位一個可供溢出的自動變數，然後向程式傳遞一個很大的字元串，在引發緩衝區溢出改變激活紀錄的同時殖入了代碼。這個是由Levy指出的攻擊的模板。因為C語言在習慣上只為用戶和參數開闢很小的緩衝區，因此這種漏洞攻擊的實例不在少數。
代碼殖入和緩衝區溢出不一定要在一次動作內完成。攻擊者可以在一個緩衝區內放置代碼，這是不能溢出緩衝區。然後，攻擊者通過溢出另外一個緩衝區來轉移程式的指針。這種方法一般用來解決可供溢出的緩衝區不夠大的情況。
如果攻擊者試圖使用已經常駐的代碼而不是從外部殖入代碼，他們通常有必須把代碼作為參數化。舉例來說，在libc中的部分代碼段會執行“exec(something)”，其中something就是參數。攻擊者然後使用緩衝區溢出改變程式的參數，利用另一個緩衝區溢出使程式指針指向libc中的特定的代碼段。
為什麼緩衝區溢出如此常見
在幾乎所有計算機語言中，不管是新的語言還是舊的語言，使緩衝區溢出的任何嘗試通常都會被該語言本身自動檢測並阻止（比如通過引發一個異常或根據需要給緩衝區添加更多空間）。但是有兩種語言不是這樣：C 和 C++ 語言。C 和 C++ 語言通常只是讓額外的數據亂寫到其餘記憶體的任何位置，而這種情況可能被利用從而導致恐怖的結果。更糟糕的是，用 C 和 C++ 編寫正確的代碼來始終如一地處理緩衝區溢出則更為困難；很容易就會意外地導致緩衝區溢出。除了 C 和 C++ 使用得 非常廣泛外，上述這些可能都是不相關的事實；例如，Red Hat Linux 7.1 中 86% 的代碼行都是用 C 或 C ++ 編寫的。因此，大量的代碼對這個問題都是脆弱的，因為實現語言無法保護代碼避免這個問題。
在 C 和 C++ 語言本身中，這個問題是不容易解決的。該問題基於 C 語言的根本設計決定（特別是 C 語言中指針和數組的處理方式）。由於 C++ 是最兼容的 C 語言超集，它也具有相同的問題。存在一些能防止這個問題的 C/C++ 兼容版本，但是它們存在極其嚴重的性能問題。而且一旦改變 C 語言來防止這個問題，它就不再是 C 語言了。許多語言（比如 Java 和 C#）在語法上類似 C，但它們實際上是不同的語言，將現有 C 或 C++ 程式改為使用那些語言是一項艱巨的任務。
然而，其他語言的用戶也不應該沾沾自喜。有些語言存在允許緩衝區溢出發生的“轉義”子句。Ada 一般會檢測和防止緩衝區溢出（即針對這樣的嘗試引發一個異常），但是不同的程式可能會禁用這個特性。C# 一般會檢測和防止緩衝區溢出，但是它允許程式設計師將某些例程定義為“不安全的”，而這樣的代碼 可能 會導致緩衝區溢出。因此如果您使用那些轉義機制，就需要使用 C/C++ 程式所必須使用的相同種類的保護機制。許多語言都是用 C 語言來實現的（至少部分是用 C 語言來實現的 ），並且用任何語言編寫的所有程式本質上都依賴用 C 或 C++ 編寫的庫。因此，所有程式都會繼承那些問題，所以了解這些問題是很重要的。
防止緩衝區溢出的新技術
當然，要讓程式設計師 不犯常見錯誤是很難的，而讓程式（以及程式設計師）改為使用另一種語言通常更為困難。那么為何不讓底層系統自動保護程式避免這些問題呢？最起碼，避免 stack-smashing 攻擊是一件好事，因為 stack-smashing 攻擊是特別容易做到的。
一般來說，更改底層系統以避免常見的安全問題是一個極好的想法，我們在本文後面也會遇到這個主題。事實證明存在許多可用的防禦措施，而一些最受歡迎的措施可分組為以下類別：
基於探測方法（canary）的防禦。這包括 StackGuard（由 Immunix 所使用）、ProPolice（由 OpenBSD 所使用）和 Microsoft 的 /GS 選項。
非執行的堆疊防禦。這包括 Solar Designer 的 non-exec 補丁（由 OpenWall 所使用）和 exec shield（由 Red Hat/Fedora 所使用）。
其他方法。這包括 libsafe（由 Mandrake 所使用）和堆疊分割方法。
遺憾的是，迄今所見的所有方法都具有弱點，因此它們不是萬能藥，但是它們會提供一些幫助。
▲基於探測方法的防禦
研究人員 Crispen Cowan 創建了一個稱為 StackGuard 的有趣方法。Stackguard 修改 C 編譯器（gcc），以便將一個“探測”值插入到返回地址的前面。“探測儀”就像煤礦中的探測儀：它在某個地方出故障時發出警告。在任何函式返回之前，它執行檢查以確保探測值沒有改變。如果攻擊者改寫返回地址（作為 stack-smashing 攻擊的一部分），探測儀的值或許就會改變，系統內就會相應地中止。這是一種有用的方法，不過要注意這種方法無法防止緩衝區溢出改寫其他值（攻擊者仍然能夠利用這些值來攻擊系統）。人們也曾擴展這種方法來保護其他值（比如堆上的值）。Stackguard（以及其他防禦措施）由 Immunix 所使用。
IBM 的 stack-smashing 保護程式（ssp，起初名為 ProPolice）是 StackGuard 的方法的一種變化形式。像 StackGuard 一樣，ssp 使用一個修改過的編譯器在函式調用中插入一個探測儀以檢測堆疊溢出。然而，它給這種基本的思路添加了一些有趣的變化。 它對存儲局部變數的位置進行重新排序，並複製函式參數中的指針，以便它們也在任何數組之前。這樣增強了ssp 的保護能力；它意味著緩衝區溢出不會修改指針值（否則能夠控制指針的攻擊者就能使用指針來控制程式保存數據的位置）。默認情況下，它不會檢測所有函式，而只是檢測確實需要保護的函式（主要是使用字元數組的函式）。從理論上講，這樣會稍微削弱保護能力，但是這種默認行為改進了性能，同時仍然能夠防止大多數問題。考慮到實用的因素，它們以獨立於體系結構的方式使用 gcc 來實現它們的方法，從而使其更易於運用。從 2003 年 5 月的發布版本開始，廣受讚譽的 OpenBSD（它重點關注安全性）在他們的整個發行套件中使用了 ssp（也稱為 ProPolice）。
Microsoft 基於 StackGuard 的成果，添加了一個編譯器標記（/GS）來實現其 C 編譯器中的探測儀。
▲非執行的堆疊防禦
另一種方法首先使得在堆疊上執行代碼變得不可能。 遺憾的是，x86 處理器（最常見的處理器）的記憶體保護機制無法容易地支持這點；通常，如果一個記憶體頁是可讀的，它就是可執行的。一個名叫 Solar Designer 的開發人員想出了一種核心和處理器機制的聰明組合，為 Linux 核心創建了一個“非執行的堆疊補丁”；有了這個補丁，堆疊上的程式就不再能夠像通常的那樣在 x86 上運行。 事實證明在有些情況下，可執行程式 需要在堆疊上；這包括信號處理和跳板代碼（trampoline）處理。trampoline 是有時由編譯器（比如 GNAT Ada 編譯器）生成的奇妙結構，用以支持像嵌套子例程之類的結構。Solar Designer 還解決了如何在防止攻擊的同時使這些特殊情況不受影響的問題。
Linux 中實現這個目的的最初補丁在 1998 年被 Linus Torvalds 拒絕，這是因為一個有趣的原因。即使不能將代碼放到堆疊上，攻擊者也可以利用緩衝區溢出來使程式“返回”某個現有的子例程（比如 C 庫中的某個子例程），從而進行攻擊。簡而言之，僅只是擁有非可執行的堆疊是不足夠的。
一段時間之後，人們又想出了一種防止該問題的新思路：將所有可執行代碼轉移到一個稱為“ASCII 保護（ASCII armor）”區域的記憶體區。要理解這是如何工作的，就必須知道攻擊者通常不能使用一般的緩衝區溢出攻擊來插入 ASCII NUL 字元（0)這個事實。 這意味著攻擊者會發現，要使一個程式返回包含 0 的地址是很困難的。由於這個事實，將所有可執行代碼轉移到包含 0 的地址就會使得攻擊該程式困難多了。
具有這個屬性的最大連續記憶體範圍是從 0 到 0x01010100 的一組記憶體地址，因此它們就被命名為 ASCII 保護區域（還有具有此屬性的其他地址，但它們是分散的）。與非可執行的堆疊相結合，這種方法就相當有價值了：非可執行的堆疊阻止攻擊者傳送可執行代碼，而 ASCII 保護記憶體使得攻擊者難於通過利用現有代碼來繞過非可執行堆疊。這樣將保護程式代碼避免堆疊、緩衝區和函式指針溢出，而且全都不需重新編譯。
然而，ASCII 保護記憶體並不適用於所有程式；大程式也許無法裝入 ASCII 保護記憶體區域（因此這種保護是不完美的），而且有時攻擊者 能夠將 0 插入目的地址。 此外，有些實現不支持跳板代碼，因此可能必須對需要這種保護的程式禁用該特性。Red Hat 的 Ingo Molnar 在他的“exec-shield”補丁中實現了這種思想，該補丁由 Fedora 核心（可從 Red Hat 獲得它的免費版本）所使用。最新版本的 OpenWall GNU/Linux (OWL)使用了 Solar Designer 提供的這種方法的實現（請參閱 參考資料 以獲得指向這些版本的連結）。
▲其他方法
還有其他許多方法。一種方法就是使標準庫對攻擊更具抵抗力。Lucent Technologies 開發了 Libsafe，這是多個標準 C 庫函式的包裝，也就是像 strcpy() 這樣已知的對 stack-smashing 攻擊很脆弱的函式。Libsafe 是在 LGPL 下授予許可證的開放原始碼軟體。那些函式的 libsafe 版本執行相關的檢查，確保數組改寫不會超出堆疊楨。然而，這種方法僅保護那些特定的函式，而不是從總體上防止堆疊溢出缺陷，並且它僅保護堆疊，而不保護堆疊中的局部變數。它們的最初實現使用了 LD_PRELOAD ，而這可能與其他程式產生衝突。Linux 的 Mandrake 發行套件（從 7.1 版開始）包括了 libsafe。
另一種方法稱為“分割控制和數據堆疊”―― 基本的思路是將堆疊分割為兩個堆疊，一個用於存儲控制信息（比如“返回”地址），另一個用於控制其他所有數據。Xu et al. 在 gcc 中實現了這種方法，StackShield 在彙編程式中實現了這種方法。這樣使得操縱返回地址困難多了，但它不會阻止改變調用函式的數據的緩衝區溢出攻擊。
事實上還有其他方法，包括隨機化可執行程式的位置；Crispen 的“PointGuard”將這種探測儀思想引申到了堆中，等等。如何保護當今的計算機現在已成了一項活躍的研究任務。
一般保護是不足夠的
如此多不同的方法意味著什麼呢？對用戶來說，好的一面在於大量創新的方法正在試驗之中；長期看來，這種“競爭”會更容易看出哪種方法最好。而且，這種多樣性還使得攻擊者躲避所有這些方法更加困難。然而，這種多樣性也意味著開發人員需要 避免編寫會干擾其中任何一種方法的代碼。這在實踐上是很容易的；只要不編寫對堆疊楨執行低級操作或對堆疊的布局作假設的代碼就行了。即使不存在這些方法，這也是一個很好的建議。
作業系統供應商需要參與進來就相當明顯了：至少挑選一種方法，並使用它。緩衝區溢出是第一號的問題，這些方法中最好的方法通常能夠減輕發行套件中幾乎半數已知缺陷的影響。可以證明，不管是基於探測儀的方法更好，還是基於非可執行堆疊的方法更好，它們都具有各自的優點。可以將它們結合起來使用，但是少數方法不支持這樣使用，因為附加的性能損失使得這樣做不值得。我並沒有其他意思，至少就這些方法本身而言是這樣；libsafe 和分割控制及數據堆疊的方法在它們所提供的保護方面都具有局限性。當然，最糟糕的解決辦法就是根本不對這個第一號的缺陷提供保護。還沒有實現一種方法的軟體供應商需要立即計畫這樣做。從 2004 年開始，用戶應該開始避免使用這樣的作業系統，即它們至少沒有對緩衝區溢出提供某種自動保護機制。
然而，沒有哪種方法允許開發人員忽略緩衝區溢出。所有這些方法都能夠被攻擊者破壞。 攻擊者也許能夠通過改變函式中其他數據的值來利用緩衝區溢出；沒有哪種方法能夠防止這點。如果能夠插入某些難於創建的值（比如 NUL 字元），那么這其中的許多方法都能被攻擊者繞開；隨著多媒體和壓縮數據變得更加普遍，攻擊者繞開這些方法就更容易了。從根本上講，所有這些方法都能減輕從程式接管攻擊到拒絕服務攻擊的緩衝區溢出攻擊所帶來的破壞。遺憾的是，隨著計算機系統在更多關鍵場合的使用，即使拒絕服務通常也是不可接受的。因而，儘管發行套件應該至少包括一種適當的防禦方法，並且開發人員應該使用（而不是反對）那些方法，但是開發人員仍然需要最初就編寫無缺陷的軟體。
解決方法
下面討論記憶體溢出問題的解決和預防措施。
受控代碼
2002 年 2 月和 3 月，微軟公司展開了 Microsoft Windows Security Push 活動。在此期間，我所在的小組一共培訓了超過 8500 人，教授他們如何在設計、測試和文檔編制過程中解決安全問題。在我們向所有程式設計人員提出的建議中，有一條就是：緊跟微軟公司軟體開發策略的步伐，將某些應用程式和工具軟體由原先基於本地 Win32 的 C++ 代碼改造成基於 .NET 的受控代碼。我們的理由很多，但其中最根本的一條，就是為了解決記憶體溢出問題。基於受控代碼的軟體發生記憶體溢出問題的機率要小得多，因為受控代碼無法直接存取系統指針、暫存器或者記憶體。作為開發人員，你應該考慮(至少是打算)用受控代碼改寫某些應用程式或工具軟體。例如：企業管理工具就是很好的改寫對象之一。當然，你也應該很清楚，不可能在一夜之間把所有用 C++ 開發的軟體用 C# 之類的受控代碼語言改寫。
黃金規則
當你用 C/C++ 書寫代碼時，應該處處留意如何處理來自用戶的數據。如果一個函式的數據來源不可靠，又用到記憶體緩衝區，那么它就必須嚴格遵守下列規則：
必須知道記憶體緩衝區的總長度。
檢驗記憶體緩衝區。
提高警惕。
讓我們來具體看看這些“黃金規則”：
（1）必須知道記憶體緩衝區的總長度。
類似這樣的代碼就有可能導致 bug ：
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)
strcpy(szBuff,szName);
}
這樣雖然有所改進，可它似乎又過於信任 cbName 了。攻擊者仍然有機會偽造 czName 和 szName 兩個參數以謊報數據長度和記憶體緩衝區長度。因此，你還得檢檢這兩個參數！
（2）檢驗記憶體緩衝區
如何知道由參數傳來的記憶體緩衝區長度是否真實呢？你會完全信任來自用戶的數據嗎？通常，答案是否定的。其實，有一種簡單的辦法可以檢驗記憶體緩衝區是否溢出。請看如下代碼片斷：
void Function(char *szName, DWORD cbName) {
char szBuff[MAX_NAME];
// 檢測記憶體
szBuff[cbName] = 0x42;
// 複製並使用 szName
if (cbName < MAX_NAME)
strcpy(szBuff,szName);
}
這段代碼試圖向欲檢測的記憶體緩衝區末尾寫入數據 0x42 。你也許會想：真是多此一舉，何不直接複製記憶體緩衝區呢？事實上，當記憶體緩衝區已經溢出時，一旦再向其中寫入常量值，就會導致程式代碼出錯並中止運行。這樣在開發早期就能及時發現代碼中的 bug 。試想，與其讓攻擊者得手，不如及時中止程式；你大概也不願看到攻擊者隨心所欲地向記憶體緩衝區複製數據吧。
（3）提高警惕
雖然檢驗記憶體緩衝區能夠有效地減小記憶體溢出問題的危害，卻不能從根本上避免記憶體溢出攻擊。只有從原始碼開始提高警惕，才能真正免除記憶體溢出攻擊的危脅。不錯，上一段代碼已經很對用戶數據相當警惕了。它能確保複製到記憶體緩衝區的數據總長度不會超過 szBuff 的長度。然而，某些函式在使用或複製不可靠的數據時也可能潛伏著記憶體溢出漏洞。為了檢查你的代碼是否存在記憶體溢出漏洞，你必須儘量追蹤傳入數據的流向，向代碼中的每一個假設提出質疑。一旦這么做了，你將會意識到其中某些假設是錯誤的；然後你還會驚訝地叫道：好多 bug 呀！
在調用 strcpy、strcat、gets 等經典函式時當然要保持警惕；可對於那些所謂的第 n 版 (n-versions) strcpy 或 strcat 函式 —— 比如 strncpy 或 strncat (其中 n = 1，2，3 ……) —— 也不可輕信。的確，這些改良版本的函式是安全一些、可靠一些，因為它們限制了進入記憶體緩衝區的數據長度；然而，它們也可能導致記憶體溢出問題！請看下列代碼，你能指出其中的錯誤嗎？
#define SIZE(b) (sizeof(b))
char buff;
strncpy(buff,szSomeData,SIZE(buff));
strncat(buff,szMoreData,SIZE(buff));
strncat(buff,szEvenMoreData,SIZE(buff));
給點提示：請注意這些字元串函式的最後一個參數。怎么，棄權？我說啊，如果你是執意要放棄那些“不安全”的經典字元串函式，並且一律改用“相對安全”的第 n 版函式的話，恐怕你這下半輩子都要為了修復這些新函式帶來的新 bug 而疲於奔命了。呵呵，開個玩笑而已。為何這么說？首先，它們的最後一個參數並不代表記憶體緩衝區的總長度，它們只是其剩餘空間的長度；不難看出，每執行完一個 strn... 函式，記憶體緩衝區 buff 的長度就減少一些。其次，傳遞給函式的記憶體緩衝區長度難免存在“大小差一”(off-by-one)的誤差。你認為在計算 buff 的長度時包括了字元串末尾的空字元嗎？當我向聽眾提出這個問題時，得到的肯定答覆和否定答覆通常是 50 比 50 ，對半開。也就是說，大約一半人認為計算了末尾的空字元，而另一半人認為忽略了該字元。最後，那些第 n 版函式所返回的字元串不見得以空字元結束，所以在使用前務必要仔細閱讀它們的說明文檔。
編譯選項
“/GS”是Visual C++.NET 新引入的一個編譯選項。它指示編譯器在某些函式的堆疊幀(stack-frames) 中插入特定數據，以幫助消除針對堆疊的記憶體溢出問題隱患。切記，使用該選項並不能替你清除代碼中的記憶體溢出漏洞，也不可能消滅任何 bug 。它只是亡羊補牢，讓某些記憶體溢出問題隱患無法演變成真正的記憶體溢出問題；也就是說，它能防止攻擊者在發生記憶體溢出時向進程中插入和運行惡意代碼。無論如何，這也算是小小的安全保障吧。請注意，在新版的本地 Win32 C++ 中使用 Win32應用程式嚮導創建新項目時，默認設定已經打開了此選項。同樣，Windows .NET Server 環境也默認打開了此選項。關於 /GS 選項的更多信息，請參考 Brandon Bray 的《Compiler Security Checks In Depth》一書。
所謂定點數溢出是指定點數的運算結果的絕對值大於計算機能表示的最大數的絕對值。浮點數的溢出又可分為“上溢出”和“下溢出”兩種，“上溢出”與整數、定點數的含義相同，“下溢出”是指浮點數的運算結果的絕對值小於機器所能表示的最小數絕對值，此時將該運算結果處理成機器零。若發現溢出(上溢出)，運算器將產生溢出標誌或發出中斷請求，當溢出中斷未被禁止時，溢出中斷信號的出現可中止程式的執行而轉入溢出中斷處理程式。
例如：有兩個數0.1001111和0.1101011相加，其結果應為1.0111010。由於定點數計算機只能表示小於1的數，如果字長只有8位，那么小數點前面的1，會因沒有觸發器存放而丟失。這樣，上述兩個數在計算機中相加，其結果變為0.0111010。若字長只有8位，則結果顯示為0.0000000，後面的1個0和6個1全部丟失，顯然這個結果有誤差。計算機的任何運算都不允許溢出，除非專門利用溢出做判斷，而不使用所得的結果。所以，當發生和不允許出現的溢出時，就要停機或轉入檢查程式，以找出產生溢出的原因，做出相應的處理。
