*大學(xué)*學(xué)院信息安全產(chǎn)品開發(fā)實踐課程設(shè)計報告題 目 緩沖區(qū)溢出的保護(hù) 學(xué)生姓名 學(xué) 號_ _ 年 級 指導(dǎo)老師 指導(dǎo)老師評閱意見： 指導(dǎo)老師評分： 提交時間： 2007年12月 緩沖區(qū)溢出的保護(hù)（軟件工程專業(yè)）學(xué)生 學(xué)號 指導(dǎo)教師 摘要：1999 年 Bugtraq（一個討論安全缺陷的郵件列表）進(jìn)行的一次非正式調(diào)查發(fā)現(xiàn)，三分之二的參與者認(rèn)為第一號的缺陷就是緩沖區(qū)溢出。從 1997 年到 2007 年 3 月，CERT/CC 發(fā)出的半數(shù)安全警報都基于緩沖區(qū)缺陷。 面對如此大的威脅，我們需要知道什么是緩沖區(qū)溢出，如何防止它們，可以采用哪些最新的自動化工具來防止它們以及為什么這些工具還不足夠，還有如何在編寫程序的程序中防止它們。關(guān)鍵字：緩沖區(qū)溢出；溢出保護(hù)；溢出防御 Detection Of Buffer Overflow Abstract: From an informal investigation on Bugtraq (a mail list which discuss a limitation on security) in 1999, we can find that two-parts participants thought that the No.1 limitation is buffer overflow. From 1997 to May, 2007, almost half the secure warnings sent by CERT/CC were based on the limitation of buffer. Facing such a huge menace, we need to learn what is the buffer overflow, how to defend them, which kinds of the latest automatization tools we can used for avoid them , why these tools still not enough, and how to prevent them in programming.Keywords: Buffer Overflow，Overflow Detection, Overflow Defense 正文1 緒論1.1 立題背景緩沖區(qū)溢出是當(dāng)前一些軟件存在的最常見的安全隱患之一，通過提供一個惡意的輸入黑客可以改變進(jìn)程的執(zhí)行流程，緩沖區(qū)溢出能夠威脅到整個進(jìn)程，機(jī)器，甚至相關(guān)的系統(tǒng)領(lǐng)域。如果運(yùn)行的進(jìn)程是在權(quán)限比較高的用戶下面，比如administrator或者本地的系統(tǒng)帳戶(Local System Account),那么黑客破壞所導(dǎo)致的損失將會很嚴(yán)重而且將會面臨更廣泛的潛在危脅。最近時期爆發(fā)的一些眾所周知的病毒像，紅色代碼病毒和震蕩波蠕蟲病毒，都是C/C+代碼里存在著緩沖區(qū)溢出的結(jié)果。1.2 研究內(nèi)容在幾乎所有計算機(jī)語言中，不管是新的語言還是舊的語言，使緩沖區(qū)溢出的任何嘗試通常都會被該語言本身自動檢測并阻止（比如通過引發(fā)一個異?；蚋鶕?jù)需要給緩沖區(qū)添加更多空間）。但是有兩種語言不是這樣：C 和 C+ 語言。C 和 C+ 語言通常只是讓額外的數(shù)據(jù)亂寫到其余內(nèi)存的任何位置，而這種情況可能被利用從而導(dǎo)致恐怖的結(jié)果。更糟糕的是，用 C 和 C+ 編寫正確的代碼來始終如一地處理緩沖區(qū)溢出則更為困難；很容易就會意外地導(dǎo)致緩沖區(qū)溢出。除了 C 和 C+ 使用得 非常廣泛外，上述這些可能都是不相關(guān)的事實；例如，Red Hat Linux 7.1 中 86% 的代碼行都是用 C 或 C + 編寫的。因此，大量的代碼對這個問題都是脆弱的，因為實現(xiàn)語言無法保護(hù)代碼避免這個問題。 在 C 和 C+ 語言本身中，這個問題是不容易解決的。該問題基于 C 語言的根本設(shè)計決定（特別是 C 語言中指針和數(shù)組的處理方式）。由于 C+ 是最兼容的 C 語言超集，它也具有相同的問題。存在一些能防止這個問題的 C/C+ 兼容版本，但是它們存在極其嚴(yán)重的性能問題。而且一旦改變 C 語言來防止這個問題，它就不再是 C 語言了。許多語言（比如 Java 和 C#）在語法上類似 C，但它們實際上是不同的語言，將現(xiàn)有 C 或 C+ 程序改為使用那些語言是一項艱巨的任務(wù)。有些語言存在允許緩沖區(qū)溢出發(fā)生的“轉(zhuǎn)義”子句。Ada 一般會檢測和防止緩沖區(qū)溢出（即針對這樣的嘗試引發(fā)一個異常），但是不同的程序可能會禁用這個特性。C# 一般會檢測和防止緩沖區(qū)溢出，但是它允許程序員將某些例程定義為“不安全的”，而這樣的代碼 可能 會導(dǎo)致緩沖區(qū)溢出。因此如果您使用那些轉(zhuǎn)義機(jī)制，就需要使用 C/C+ 程序所必須使用的相同種類的保護(hù)機(jī)制。許多語言都是用 C 語言來實現(xiàn)的（至少部分是用 C 語言來實現(xiàn)的 ），并且用任何語言編寫的所有程序本質(zhì)上都依賴用 C 或 C+ 編寫的庫。因此，所有程序都會繼承那些問題，所以了解這些問題是很重要的。 2緩沖區(qū)溢出的概述 2.1 緩沖區(qū)溢出的起源內(nèi)存溢出已經(jīng)是軟件開發(fā)歷史上存在了近40年的“老大難”問題2.2緩沖區(qū)溢出如何工作計算機(jī)還有由程序共享， 隨機(jī)訪問內(nèi)存 (RAM)。 為了簡化, 內(nèi)存管理 Windows XP SP 2 有功能控制當(dāng)前正在使用哪段的 RAM。 如果啟動程序, 釋放內(nèi)存分配給程序。 該內(nèi)存被分為三段： 代碼段此處存儲程序特定執(zhí)行命令。 數(shù)據(jù)段此處程序特定數(shù)據(jù)存儲。 堆棧是數(shù)據(jù)段 （一部分）此處存儲所有與程序函數(shù)。 這包括參數(shù)、 緩沖區(qū)存儲本地變量以及, 最重要、 返回地址。 返回地址指定執(zhí)行函數(shù)后， 程序?qū)⒗^續(xù)從。作為是由用戶輸入該信息也注冊作為變量, 一切， 發(fā)送到堆棧用戶類型。 不通常, 此行為不提出問題。 但是, 如果因編程錯誤, 超過緩沖區(qū)限制堆棧成為容易控制。 整個段被指定為本地變量例如, 如果攻擊者選擇適當(dāng)項對于攻擊, 可能會覆蓋用指令。 此外, 后續(xù)返回地址可更改為指向惡意代碼。 因此, 程序不再正常, 但盲目執(zhí)行攻擊者的命令。內(nèi)存的底部 內(nèi)存的頂部 buffer1 sfp ret a b c - 增長 - . 堆棧的頂部 堆棧的底部 許多計算機(jī)處理器，包括所有 x86 處理器，都支持從高位地址向低位地址“倒”增長堆棧。因此，每當(dāng)一個函數(shù)調(diào)用另一個函數(shù)，更多的數(shù)據(jù)將被添加到左邊（低位地址），直至系統(tǒng)的堆?？臻g耗盡。在這個例子中，當(dāng) main() 調(diào)用 function1() 時，它將 c 的值壓入堆棧，然后壓入 b 的值，最后壓入 a 的值。之后它壓入 return (ret) 值，這個值在 function1() 完成時告訴 function1() 返回到 main() 中的何處。它還把所謂的“已保存的幀指針（saved frame pointer，sfp）”記錄到堆棧上；這并不是必須保存的內(nèi)容，此處我們不需要理解它。在任何情況下， function1() 在啟動以后，它會為 buffer1() 預(yù)留空間，這在圖 1 中顯示為具有一個低地址位置。 現(xiàn)在假設(shè)攻擊者發(fā)送了超過 buffer1() 所能處理的數(shù)據(jù)。接下來會發(fā)生什么情況呢？當(dāng)然，C 和 C+ 程序員不會自動檢查這個問題，因此除非程序員明確地阻止它，否則下一個值將進(jìn)入內(nèi)存中的“下一個”位置。那意味著攻擊者能夠改寫 sfp （即已保存的幀指針），然后改寫 ret （返回地址）。之后，當(dāng) function1() 完成時，它將“返回” 不過不是返回到 main() ，而是返回到攻擊者想要運(yùn)行的任何代碼。 通常攻擊者會使用它想要運(yùn)行的惡意代碼來使緩沖區(qū)溢出，然后攻擊者會更改返回值以指向它們已發(fā)送的惡意代碼。這意味著攻擊者本質(zhì)上能夠在一個操作中完成整個攻擊！Aleph On 的文章（請參閱 參考資料）詳細(xì)介紹了這樣的攻擊代碼是如何創(chuàng)建的。例如，將一個 ASCII 0 字符壓入緩沖區(qū)通常是很困難的，而該文介紹了攻擊者一般如何能夠解決這個問題。 除了 smashing-stack 和更改返回地址外，還存在利用緩沖區(qū)溢出缺陷的其他途徑。與改寫返回地址不同，攻擊者可以 smashing-stack（使堆棧上的緩沖區(qū)溢出），然后改寫局部變量以利用緩沖區(qū)溢出缺陷。緩沖區(qū)根本就不必在堆棧上 它可以是堆中動態(tài)分配的內(nèi)存（也稱為“malloc”或“new”區(qū)域），或者在某些靜態(tài)分配的內(nèi)存中（比如“global”或“static”內(nèi)存）?；旧希绻粽吣軌蛞绯鼍彌_區(qū)的邊界，麻煩或許就會找上你了。 然而，最危險的緩沖區(qū)溢出攻擊就是 stack-smashing 攻擊，因為如果程序?qū)粽吆艽嗳?，攻擊者獲得整個機(jī)器的控制權(quán)就特別容易 2.3緩沖區(qū)溢出分類 2.3.1在程序的地址空間里安排適當(dāng)?shù)拇a 2.3.1.1殖入法 攻擊者用被攻擊程序的緩沖區(qū)來存放攻擊代碼。 攻擊者向被攻擊的程序輸入一個字符串，程序會把這個字符串放到緩沖區(qū)里。這個字符串包含的數(shù)據(jù)是可以在這個被攻擊的硬件平臺上運(yùn)行的指令序列。 2.3.1.2利用已經(jīng)存在的代碼 有時候，攻擊者想要的代碼已經(jīng)在被攻擊的程序中了,攻擊者所要做的只是對代碼傳遞一些參數(shù)，然后使程序跳轉(zhuǎn)到指定目標(biāo)。比如，在C語言中，攻擊代碼要求執(zhí)行“exec(/bin/sh)”，而在libc庫中的代碼執(zhí)行“exec(arg)”，其中arg是指向一個字符串的指針參數(shù)，那么攻擊者只要把傳入的參數(shù)指針指向/bin/sh，就可以調(diào)轉(zhuǎn)到libc庫中的相應(yīng)的指令序列。 2.3.2控制程序轉(zhuǎn)移到攻擊代碼這種方法旨在改變程序的執(zhí)行流程，使之跳轉(zhuǎn)到攻擊代碼。最基本方法的就是溢出一個沒有邊界檢查或者其他弱點的緩沖區(qū)，這樣就擾亂了程序的正常的執(zhí)行順序。通過溢出一個緩沖區(qū)，攻擊者可以用近乎暴力的方法改寫相鄰的程序空間而直接跳過了系統(tǒng)的檢查。 2.3.2.1激活紀(jì)錄（Activation Records） 每當(dāng)一個函數(shù)調(diào)用發(fā)生時，調(diào)用者會在堆棧中留下一個激活紀(jì)錄，它包含了函數(shù)結(jié)束時返回的地址。攻擊者通過溢出這些自動變量，使這個返回地址指向攻擊代碼。通過改變程序的返回地址，當(dāng)函數(shù)調(diào)用結(jié)束時，程序就跳轉(zhuǎn)到攻擊者設(shè)定的地址，而不是原先的地址。這類的緩沖區(qū)溢出被稱為“stack smashing attack”，是目前常用的緩沖區(qū)溢出攻擊方式。 2.3.2.2函數(shù)指針（Function Pointers） C語言中，“void (* foo)()”聲明了一個返回值為void函數(shù)指針的變量foo。函數(shù)指針可以用來定位任何地址空間，所以攻擊者只需在任何空間內(nèi)的函數(shù)指針附近找到一個能夠溢出的緩沖區(qū)，然后溢出這個緩沖區(qū)來改變函數(shù)指針。在某一時刻，當(dāng)程序通過函數(shù)指針調(diào)用函數(shù)時，程序的流程就按攻擊者的意圖實現(xiàn)了！它的一個攻擊范例就是在Linux系統(tǒng)下的super probe程序。 2.3.2.3長跳轉(zhuǎn)緩沖區(qū)（Longjmp buffers） 在C語言中包含了一個簡單的檢驗/恢復(fù)系統(tǒng)，稱為setjmp/longjmp。意思是在檢驗點設(shè)定“setjmp(buffer)”，用“l(fā)ongjmp(buffer)”來恢復(fù)檢驗點。然而，如果攻擊者能夠進(jìn)入緩沖區(qū)的空間，那么“l(fā)ongjmp(buffer)”實際上是跳轉(zhuǎn)到攻擊者的代碼。象函數(shù)指針一樣，longjmp緩沖區(qū)能夠指向任何地方，所以攻擊者所要做的就是找到一個可供溢出的緩沖區(qū)。一個典型的例子就是Perl 5.003，攻擊者首先進(jìn)入用來恢復(fù)緩沖區(qū)溢出的的longjmp緩沖區(qū)，然后誘導(dǎo)進(jìn)入恢復(fù)模式，這樣就使Perl的解釋器跳轉(zhuǎn)到攻擊代碼上了！ 3. 緩沖區(qū)溢出的保護(hù)當(dāng)然，要讓程序員 不犯常見錯誤是很難的，而讓程序（以及程序員）改為使用另一種語言通常更為困難。那么為何不讓底層系統(tǒng)自動保護(hù)程序避免這些問題呢？最起碼，避免 stack-smashing 攻擊是一件好事，因為 stack-smashing 攻擊是特別容易做到的。 一般來說，更改底層系統(tǒng)以避免常見的安全問題是一個極好的想法，我們在本文后面也會遇到這個主題。事實證明存在許多可用的防御措施，而一些最受歡迎的措施可分組為以下類別： 3.1基于探測方法（canary）的防御。這包括 StackGuard（由 Immunix 所使用）、ProPolice（由 OpenBSD 所使用）和 Microsoft 的 /GS 選項。 非執(zhí)行的堆棧防御。這包括 Solar Designer 的 non-exec 補(bǔ)?。ㄓ?OpenWall 所使用）和 exec shield（由 Red Hat/Fedora 所使用）。 其他方法。這包括 libsafe（由 Mandrake 所使用）和堆棧分割方法。 遺憾的是，迄今所見的所有方法都具有弱點，因此它們不是萬能藥，但是它們會提供一些幫助。 3.2基于探測方法的防御 :研究人員 Crispen Cowan 創(chuàng)建了一個稱為 StackGuard 的有趣方法。Stackguard 修改 C 編譯器（gcc），以便將一個“探測”值插入到返回地址的前面?！疤綔y儀”就像煤礦中的探測儀：它在某個地方出故障時發(fā)出警告。在任何函數(shù)返回之前，它執(zhí)行檢查以確保探測值沒有改變。如果攻擊者改寫返回地址（作為 stack-smashing 攻擊的一部分），探測儀的值或許就會改變，系統(tǒng)內(nèi)就會相應(yīng)地中止。這是一種有用的方法，不過要注意這種方法無法防止緩沖區(qū)溢出改寫其他值（攻擊者仍然能夠利用這些值來攻擊系統(tǒng)）。人們也曾擴(kuò)展這種方法來保護(hù)其他值（比如堆上的值）。Stackguard（以及其他防御措施）由 Immunix 所使用。 IBM 的 stack-smashing 保護(hù)程序（ssp，起初名為 ProPolice）是 StackGuard 的方法的一種變化形式。像 StackGuard 一樣，ssp 使用一個修改過的編譯器在函數(shù)調(diào)用中插入一個探測儀以檢測堆棧溢出。然而，它給這種基本的思路添加了一些有趣的變化。 它對存儲局部變量的位置進(jìn)行重新排序，并復(fù)制函數(shù)參數(shù)中的指針，以便它們也在任何數(shù)組之前。這樣增強(qiáng)了ssp 的保護(hù)能力；它意味著緩沖區(qū)溢出不會修改指針值（否則能夠控制指針的攻擊者就能使用指針來控制程序保存數(shù)據(jù)的位置）。默認(rèn)情況下，它不會檢測所有函數(shù)，而只是檢測確實需要保護(hù)的函數(shù)（主要是使用字符數(shù)組的函數(shù)）。從理論上講，這樣會稍微削弱保護(hù)能力，但是這種默認(rèn)行為改進(jìn)了性能，同時仍然能夠防止大多數(shù)問題?？紤]到實用的因素，它們以獨(dú)立于體系結(jié)構(gòu)的方式使用 gcc 來實現(xiàn)它們的方法，從而使其更易于運(yùn)用。從 2003 年 5 月的發(fā)布版本開始，廣受贊譽(yù)的 OpenBSD（它重點關(guān)注安全性）在他們的整個發(fā)行套件中使用了 ssp（也稱為 ProPolice）。3.3非執(zhí)行的堆棧防御:另一種方法首先使得在堆棧上執(zhí)行代碼變得不可能。 遺憾的是，x86 處理器（最常見的處理器）的內(nèi)存保護(hù)機(jī)制無法容易地支持這點；通常，如果一個內(nèi)存頁是可讀的，它就是可執(zhí)行的。一個名叫 Solar Designer 的開發(fā)人員想出了一種內(nèi)核和處理器機(jī)制的聰明組合，為 Linux 內(nèi)核創(chuàng)建了一個“非執(zhí)行的堆棧補(bǔ)丁”；有了這個補(bǔ)丁，堆棧上的程序就不再能夠像通常的那樣在 x86 上運(yùn)行。 事實證明在有些情況下，可執(zhí)行程序 需要在堆棧上；這包括信號處理和跳板代碼（trampoline）處理。trampoline 是有時由編譯器（比如 GNAT Ada 編譯器）生成的奇妙結(jié)構(gòu)，用以支持像嵌套子例程之類的結(jié)構(gòu)。Solar Designer 還解決了如何在防止攻擊的同時使這些特殊情況不受影響的問題。 Linux 中實現(xiàn)這個目的的最初補(bǔ)丁在 1998 年被 Linus Torvalds 拒絕，這是因為一個有趣的原因。即使不能將代碼放到堆棧上，攻擊者也可以利用緩沖區(qū)溢出來使程序“返回”某個現(xiàn)有的子例程（比如 C 庫中的某個子例程），從而進(jìn)行攻擊。簡而言之，僅只是擁有非可執(zhí)行的堆棧是不足夠的。一段時間之后，人們又想出了一種防止該問題的新思路：將所有可執(zhí)行代碼轉(zhuǎn)移到一個稱為“ASCII 保護(hù)（ASCII armor）”區(qū)域的內(nèi)存區(qū)。要理解這是如何工作的，就必須知道攻擊者通常不能使用一般的緩沖區(qū)溢出攻擊來插入 ASCII NUL 字符（0)這個事實。 這意味著攻擊者會發(fā)現(xiàn)，要使一個程序返回包含 0 的地址是很困難的。由于這個事實，將所有可執(zhí)行代碼轉(zhuǎn)移到包含 0 的地址就會使得攻擊該程序困難多了。具有這個屬性的最大連續(xù)內(nèi)存范圍是從 0 到 0x01010100 的一組內(nèi)存地址，因此它們就被命名為 ASCII 保護(hù)區(qū)域（還有具有此屬性的其他地址，但它們是分散的）。與非可執(zhí)行的堆棧相結(jié)合，這種方法就相當(dāng)有價值了：非可執(zhí)行的堆棧阻止攻擊者發(fā)送可執(zhí)行代碼，而 ASCII 保護(hù)內(nèi)存使得攻擊者難于通過利用現(xiàn)有代碼來繞過非可執(zhí)行堆棧。這樣將保護(hù)程序代碼避免堆棧、緩沖區(qū)和函數(shù)指針溢出，而且全都不需重新編譯。然而，ASCII 保護(hù)內(nèi)存并不適用于所有程序；大程序也許無法裝入 ASCII 保護(hù)內(nèi)存區(qū)域（因此這種保護(hù)是不完美的），而且有時攻擊者 能夠?qū)?0 插入目的地址。 此外，有些實現(xiàn)不支持跳板代碼，因此可能必須對需要這種保護(hù)的程序禁用該特性。Red Hat 的 Ingo Molnar 在他的“exec-shield”補(bǔ)丁中實現(xiàn)了這種思想，該補(bǔ)丁由 Fedora 核心（可從 Red Hat 獲得它的免費(fèi)版本）所使用。最新版本的 OpenWall GNU/Linux (OWL)使用了 Solar Designer 提供的這種方法的實現(xiàn)（請參閱 參考資料 以獲得指向這些版本的鏈接）。 3.4其他方法還有其他許多方法。一種方法就是使標(biāo)準(zhǔn)庫對攻擊更具抵抗力。Lucent Technologies 開發(fā)了 Libsafe，這是多個標(biāo)準(zhǔn) C 庫函數(shù)的包裝，也就是像 strcpy(