一、引言
基于OpenSSL的心臟出血漏洞被認為是CVE-2014-0160的嚴重問題，OpenSSL被廣泛的應(yīng)用于SSL和TLS插件上。本文用對心臟出血漏洞的解釋來說明這個漏洞是怎么被利用的。
本文中研究了抗心臟出血漏洞及其相似漏洞的專用工具和技術(shù)。我首先通過簡單的測試來分析為什么很多的工具和技術(shù)不能發(fā)現(xiàn)這些漏洞，這樣可以使我們更能了解到為什么之前的技術(shù)不能發(fā)現(xiàn)這些漏洞。我還要概括總結(jié)要點來減少這些的問題。本文不介紹如何編寫安全軟件，你可以從我的書《Secure Programming for Linux and Unix HOWTO 》或是其他的著作中學(xué)習(xí)到這點，本文中認為您能開發(fā)軟件。
我的目的是為了幫助防止類似漏洞的出現(xiàn)，從而提高安全軟件的開發(fā)能力。正如Orson Scott Card’s Ender’s Game中的虛幻人物Mazer Rackham所說的“這里沒有老師，只有敵人…只有在敵人那里你才能了解到自己的弱點?！弊屛覀儊砹私膺@些漏洞，然后可以避免相似的漏洞再次出現(xiàn)。
二、為什么這個漏洞不能更早的被發(fā)現(xiàn)?
這個OpenSSL漏洞是由一個很熟悉的問題引起的，這個關(guān)鍵的問題就是緩沖區(qū)讀溢出，由于不正確的輸入導(dǎo)致。這些都是很常見的問題，很多的工具是專門用來查找這方面的問題，會使用很多工具對OpenSSL進行定期檢查。
Kupsch和Miller專門查找了心臟出血漏洞，在這個漏洞被發(fā)現(xiàn)之前，使用了很多的方法也沒有發(fā)現(xiàn)這個漏洞，雖然很多人和工具都用來查找類似的漏洞。他們進一步認識到“心臟出血漏洞對當前的輔助軟件提出了重大的挑戰(zhàn)，而且我們不知道是否有工具能在這個漏洞被發(fā)現(xiàn)之前被使用?！蔽視娬{(diào)一些其它的問題和我自己的一些觀點。
2.1 靜態(tài)分析
在沒有執(zhí)行這個程序時的靜態(tài)分析。
最常用來尋找漏洞的靜態(tài)分析工具是source code weakness analyzers，source code security analyzers, static application security testing，static analysis code scanners 和 code weakness analysis tools。每個源代碼分析工具是通過使用類型匹配的方法來尋找漏洞的。有很多的報告可以評估這些工具。
然而，在之前的時間里使用靜態(tài)分析工具沒有發(fā)現(xiàn)這個漏洞：
1、Coverity：Coverity沒能在心臟出血漏洞公布之前發(fā)現(xiàn)這個漏洞。他們正在通過努力來提高他們的工具的質(zhì)量，從而在將來能夠發(fā)現(xiàn)相似的漏洞，使用了一些有趣的新啟發(fā)方法。
2、HP/Fortify: HP/Fortify已經(jīng)公布了一些心臟出血漏洞的描述，但是我沒有任何的證明能說明他們的靜態(tài)分析工具在漏洞公布前就發(fā)現(xiàn)了這個漏洞，在漏洞被公布后，他們確實是更改了他們的動態(tài)測試軟件包，但是和之前的不同。在專門討論這個問題時，他們沒有證據(jù)讓我相信他們的工具真的在心臟出血漏洞被公布之前就發(fā)現(xiàn)了這個漏洞。
3、Klocwork: Klocwork在正常的配置下沒有能夠偵測到這個漏洞。
4、Grammatech: Grammatech 的CodeSonar同樣沒有偵測到這個漏洞。他們也是通過實驗來提升能力，以便在以后能夠發(fā)現(xiàn)相似的漏洞。
最主要的爭議就是這些工具都不能保證能夠發(fā)現(xiàn)所有的漏洞，甚至不能保證發(fā)現(xiàn)特定類型的漏洞。很糟糕的是這些術(shù)語很混亂，所以我們首先要搞清這些術(shù)語的意思。
本文中在分析軟件時，使用的工具不能找到所有的漏洞，但是我找到了這個分析軟件的不足。在以前的文章中，很多人使用unsound來描述那些不能找到所有漏洞的來查找漏洞的工具。例如Bessey等人在分析Coverity的靜態(tài)分析工具，并且說：“像PREfix產(chǎn)品，我們也使用unsound。”我們的產(chǎn)品并沒有證明說這是沒有錯誤的，而是盡我們的能力來發(fā)現(xiàn)這些問題。這項研究工作中存在很大的爭議，雖然它幾乎已經(jīng)成為商業(yè)軟件和研究項目的實際工具基礎(chǔ)。一個unsound術(shù)語會導(dǎo)致混亂，因為人們使用program checkers，它使用術(shù)語unsound來代替不同的意思。在一個博客上解釋了為什么相同術(shù)語會有兩種相互矛盾意思。“大多數(shù)的program checkers來證明定律的程序。特別情況下，主要的目的是在某個方面來證明程序的正確性。一個定律的證明是來證明這個定律的正確與否…人民在程序檢查過程中習(xí)慣了使用這種做法，所以他們沒有考慮bug的存在。但是一個bug的發(fā)現(xiàn)者不是要證明這個程序是不對的，而是用來證明有bug存在，使得他們報告了發(fā)現(xiàn)的bugs，它們就都變成了真正的bug，如果沒有錯誤，將會忽略bug，因為他們不能證明是否正確。”
本文中我使用了NIST SAMATE SATE V Ockham Sound Analysis標準來消除混亂，在NIST SAMATE用語中，工具是不能發(fā)現(xiàn)所有漏洞的，從而證明程序是不完備的。下面來說明NIST是怎么區(qū)分程序的可靠性和完整性：“一個網(wǎng)站的代碼可能會出問題，一個有bug的網(wǎng)站會有一系列問題，這就是說一些輸入會導(dǎo)致問題。一個沒有bug的網(wǎng)站不會出現(xiàn)一些列問題，就是說它是安全的或是沒有漏洞的…這些可以從一個網(wǎng)站的報告中得知?；蛘哒f，一個網(wǎng)站有特殊的問題或是一個網(wǎng)站沒有問題…可靠就意味著每一個發(fā)現(xiàn)都是正確的。沒有必要使用工具產(chǎn)生每個網(wǎng)站的報告;這是完整的?！?/P>
為什么那么多的源代碼分析工具是不完整的?首先，大多數(shù)的程序語言不是很容易能被分析的。其次，大多數(shù)的軟件使用靜態(tài)分析工具來分析也是很不簡單的。最后，完整的分析工具要求更多的人來應(yīng)用在程序上。相反，不完整的分析工具能夠立刻應(yīng)用到程序上。他們成功的使用啟發(fā)的方法來鑒定漏洞和在有限的時間里來完善分析。但是，這里會有重要的警告：不完整的代碼分析工具常常會漏掉漏洞。
心臟出血漏洞是一個鮮明的使用不完全的啟發(fā)方法不能發(fā)現(xiàn)的重要漏洞的例子，不能發(fā)現(xiàn)這個重要漏洞的最主要原因就是OpenSSL代碼很復(fù)雜;多個層次的間接尋址和超出了工具的分析能力，從而不能發(fā)現(xiàn)漏洞。局限性和深層次存在的原因是C, C++和Objective-C都很難使用靜態(tài)分析;像指針更難使用靜態(tài)管理。這并不是意味著靜態(tài)分析工具就是沒用的，靜態(tài)分析工具能夠測試軟件在大量的輸入后的表現(xiàn)，工具的啟發(fā)原理會限制錯誤報告的出現(xiàn)次數(shù)。但是更重要的是不完整的靜態(tài)分析工具使用了啟發(fā)原理后，在分析大的漏洞時會出現(xiàn)錯誤。
2.2 動態(tài)分析
動態(tài)方法就是使用特定的輸入來運行一個程序并試著發(fā)現(xiàn)漏洞。
動態(tài)分析局限性是它不能使用時間表來測試任何程序。如在一個瑣碎的程序中加入了64bit的整數(shù)，會有2128種可能的輸入，測試這些輸入就要使用13.5十萬億億年的時間。甚至大規(guī)模的并行計算也不能解決這個問題?，F(xiàn)實中的程序要比這復(fù)雜的多，因此動態(tài)方法不能體現(xiàn)一個程序的安全性;他們只能顯示在測試中存在漏洞。
但是這并是意味著動態(tài)方法就是沒有用的。動態(tài)方法在提升安全性上是很有用的，但是要了解到他們的局限。
讓我們來分析我們廣泛使用的兩種方法，但是不能發(fā)現(xiàn)心臟出血漏洞： mostly-positive測試和fuzzers。
2.2.1 mostly-positive自動測試套件
一個方法是開發(fā)一個強大的自動化測試套件。Eric S. Raymond和一些其他人在研究心臟出血漏洞時，他的表述為：“我認為很多人都認為這個測試套件不能很好的工作…我以前學(xué)到了盡量去推進傳統(tǒng)方法來完成你不能達到的程度?！蔽彝馑挠^點，一個好的自動化測試套件是很強大的，特別是應(yīng)用于非安全性缺陷時。如果你沒有或是開發(fā)一個，就完全的停止，我們表示同意。
但是，測試套件能否發(fā)現(xiàn)心臟出血漏洞要依靠你是怎么開發(fā)的這個套件。很多的開發(fā)人員都開發(fā)了測試套件，這個套件主要是我說的“mostly-positive”測試套件，它可能不能發(fā)現(xiàn)心臟出血漏洞。后面我將會討論negative測試，這種測試方法可能會有作用，但是我們要知道為什么一般的測試方法不能做到。
很多的開發(fā)者和組織者專門測試了正確的輸入時會發(fā)生什么。當你這樣思考時就更有意義;一般的使用者都會抱怨在正確的輸入時是否會沒有正確的輸出，并且大多數(shù)的使用者不會測試在不正確的輸入時程序會有什么結(jié)果。如果你的目的是很快的分辨出問題，在大多數(shù)的情況下，在正確的輸入時人們會努力控制能夠預(yù)測的錯誤條件。很多的開發(fā)人員不能思考到當入侵者發(fā)送精心設(shè)計的輸入來利用程序時會發(fā)生什么。
我會使用mostly-positive測試套件的方法來測試在正確的輸入時會發(fā)生什么。不幸運的是，在很大程度上，今天的軟件入侵測試套件都是mostly-positive。都在關(guān)注開發(fā)mostly-positive測試套件的測試。
1、Test-driven development(TTD)是一個軟件開發(fā)過程，“開發(fā)者寫了一個自動測試工具來提升和增加新的功能，之后使用最少數(shù)量的代碼來通過測試，和最終生成新的代碼的接受標準?！蓖ǔＧ闆r下這些測試是用描述一個新功能要做什么，而不是他們不能做什么。
2、當很多的標準鏈接在一起，交互式測試就會決定他們是否能夠鏈接和分享數(shù)據(jù)。交互式測試能夠很好的幫助開發(fā)者來提高一個協(xié)議標準。但是其他的實施方法也能遵守這個規(guī)則，其他的實施方法不能夠完成“什么不發(fā)生”的測試。
mostly-positive測試實際上對于安全軟件來說是沒有用的。mostly-positive測試一般不能測試正確的事物。對于心臟出血攻擊和其他的攻擊，攻擊者發(fā)送數(shù)據(jù)用不是平時用的格式。TTD和交互式測試都是好工具…但是你需要加強他們來改善安全軟件。
代碼覆蓋工具對漏洞的發(fā)現(xiàn)沒有任何的幫助。一個開發(fā)者可能會運行代碼覆蓋工具來看下哪些程序沒有被測試，之后增加測試來達到大部分的代碼被測試。當測試套件測試了80%-90%的代碼時，很多人會很高興;一般很少會達到100%的覆蓋。測試覆蓋工具有某種安全價值，例如，他們有時能夠偵測到等待出發(fā)者的惡意軟件，他們也能夠核查是否有特別的程序能夠正確的運行。但是使用典型的代碼覆蓋工具測試到100%的覆蓋，不能對抗心臟出血漏洞。心臟出血漏洞缺少恰當?shù)妮斎腧炞C?；旧?，一個代碼覆蓋工具不能注意到丟失的代碼;只能注意到?jīng)]有測試的代碼。
我要說在OpenSSL里也不會有例外出現(xiàn)，又如在蘋果的iOS設(shè)備上運行SSL/TLS得到了錯誤的結(jié)果時，也能通過mostly-positive來證實它的測試。在這個漏洞中，SSL/TLS庫接受了有效的證明。然而，沒有人驗證這個庫能拒絕某些無用的驗證。如果你只是測試是否有效的數(shù)據(jù)會產(chǎn)生有效的結(jié)果，你就不能發(fā)現(xiàn)安全漏洞，因為大多數(shù)的攻擊都是在基于程序沒有準備好的時候輸入。
如果你開發(fā)的套件能使用我在下面描述的方法，你能夠通過一個好的測試套件來發(fā)現(xiàn)這個漏洞。首先，讓我們來研究fuzzing。
2.2.2 Fuzzers 和fuzz測試
Fuzz測試是一個隨機輸入，之后發(fā)送到程序測試去看是否出現(xiàn)不渴望的過程。進行fuzz測試的軟件叫Fuzzers。
Fuzz測試同傳統(tǒng)的測試不同，在傳統(tǒng)的測試過程中，你會有一個給定的輸入組，并且你知道每個輸入對應(yīng)的輸出情況。傳統(tǒng)測試會隨著測試數(shù)據(jù)的增加而變得更復(fù)雜，因為你要預(yù)測渴望的輸出結(jié)果。決定輸出想要的輸出結(jié)果是一個Oracle機制。使用一個Oracle的數(shù)據(jù)作為輸入的問題被叫做Oracle problem。
Fuzz測試處理不同的Oracle problem，因為它只是在試圖偵探能使程序崩潰的問題。這就是使它在Fuzz測試中輸入更多的測試數(shù)據(jù)，即使輸出測試更不準確。Fuzzing測試方法是1988年Barton Miller在University of Wisconsin開發(fā)的。在http://pages.cs.wisc.edu/~bart/fuzz/ 上有更多的有關(guān)fuzz測試的信息。
Fuzzers經(jīng)常用來發(fā)現(xiàn)安全漏洞，因為他們能夠測試大量不可想象的輸入。特別是，F(xiàn)uzzers常用來發(fā)現(xiàn)輸入驗證的問題，心臟出血漏洞就是在輸入驗證錯誤的基礎(chǔ)上產(chǎn)生的。但是典型的Fuzzers不能發(fā)現(xiàn)心臟出血漏洞，因為：
1、心臟出血漏洞是由于緩沖區(qū)讀入溢出，而不是緩沖區(qū)寫入溢出的漏洞。大多數(shù)的Fuzzers只是發(fā)送大量的數(shù)據(jù)和尋找程序的崩潰。但是，當緩沖區(qū)寫入溢出常常會導(dǎo)致崩潰，緩沖區(qū)寫入溢出在正常的環(huán)境里是不會崩潰的。在Fuzzing過程中，甚至?xí)褂靡恍Σ邅斫鉀Q寫入溢出，而不是讀入溢出，如canary-based保護方法和非執(zhí)行堆棧。可靠性不是很大的問題，因為存在方法是出入溢出導(dǎo)致崩潰，或使用其他的測試工具來測試…這會給我們帶來第二個問題。
2、OpenSSL包括它的內(nèi)存分配路徑，并且除非使用特別的調(diào)試方法，不然我們會經(jīng)常使用他們。更糟糕的是這些特別的方法不能正常工作。特別是，OpenSSL使用它自身的應(yīng)用程序管理緩存來提高性能時，而不是簡單的依靠內(nèi)存管理路徑。這種應(yīng)用程序管理緩存可以阻止許多典型的緩存例程，包括測試工具如electric fence、valgrind和address sanitizer。這就意味著使用fuzz測試來測試緩存的路徑問題時，測試會忽略一些特殊的情況。
因為加密技術(shù)能在很大程度上減少fuzz測試的無效性，除非fuzzer有密碼和專門用來襲擊的密碼庫。有一些fuzzing不能在OpenSSL和一些密碼庫下嚴格執(zhí)行的推測應(yīng)該是正確的，然而，沒有什么能阻止密碼被fuzzers獲取。除此之外，心臟出血漏洞甚至在沒有密碼的情況下被發(fā)現(xiàn)。因此，就是在讀出溢出和OpenSSL使用自身的內(nèi)存緩存分配路徑的聯(lián)合使用時，使fuzzing變的無效。
三、用什么來對抗類似心臟出血的漏洞?
這里有部分在先前可以對抗心臟出血漏洞的軟件和工具，我會特別的介紹一些好用并且免費的自由開源、源代碼軟件。
首先是一些說明：
不要只用一種工具或一種技術(shù)來開發(fā)安全軟件。開發(fā)安全軟件要集合很多的方法，最開始要知道怎么開發(fā)安全軟件。大多數(shù)的組織最初是使用簡潔清晰的方法來開發(fā)安全軟件，啟用和注意編輯器的警告標志，使用源代碼弱點分析工具，讓多人進行研究，運行fuzzers，使用大量的自動入侵工具套件。如果你只是使用一種技術(shù)，你只能對抗上一次攻擊而不是這次。例如，會大量的忽略掉警告標志，即使是警告標志不能發(fā)現(xiàn)心臟出血。那就是說，當攻擊成功時，最重要的是怎么完善軟件，攻擊者可能如使用一樣的方法來入侵軟件。更好的改進也能對抗其他的攻擊。
這不存在一種類型的工具和技術(shù)的列表，不同的工具有不同的用途?？梢栽赱BAH2009 ] [ NIST ]上了解更多關(guān)于各個類型的工具和技術(shù)。我創(chuàng)建了這個特別的列表，但是我要盡量清楚我的意思。
先前沒有一個明確和完整的用來發(fā)現(xiàn)心臟出血漏洞的工具和技術(shù)的列表，我很想做一個，我希望得到更好的建議。
以上是一些說明，先前是什么在對抗這個漏洞的，為了完成這個，我已經(jīng)大致的完成了這個列表，用最簡單的方式介紹他們。這是最粗略的，會有一些問題;歡迎來改進。使用更多的方法來對抗其他類似漏洞，不只是心臟出血。使用動態(tài)和靜態(tài)分析法來識別在括號里的副標題。
3.1 使用negative測試(動態(tài)分析)
negative測試會得到錯誤的結(jié)果。例如，對于一個設(shè)置了密碼的系統(tǒng)來說，在知道有效的用戶名和密碼時，要通過很多次的回歸測試才能登錄成果。negative測試會顯示很多無用的用戶名和密碼，其他的無效的輸入會阻止用戶登錄。
通過negative測試方法創(chuàng)建了一系列的使用錯誤輸入的測試。我指的是每個類型的輸入，因為不能測試每一個輸入，在動態(tài)測試中能得到解釋。在回歸測試工件中要包含無效數(shù)值來測試每一個輸入，每個狀態(tài)/協(xié)議轉(zhuǎn)換，每個使用說明書等等。這就會立刻發(fā)現(xiàn)心臟出血漏洞，因為心臟出血漏洞包含一個不正確數(shù)據(jù)的長數(shù)值。這也會發(fā)現(xiàn)其他類似CVE-2014-1266的錯誤，如在蘋果iOS上使用SSL/TLS會得到的錯誤。在CVE-2014-1266中，iOS存在接受無效認證的問題。很多的測試中存在有效的認證…但是，沒有足夠的測試來測試無效的認證。
在大多數(shù)情況下只有negative測試對安全還有點用途，之前，我注意到重要的是如何創(chuàng)建測試套件。對于閱讀本文來說是明顯的，特別是，當我懷疑Eric S. Raymond在討論測試的優(yōu)勢時使用這些類型的測試。但是這對于軟件的開發(fā)者來說是明顯的，大多數(shù)的開發(fā)者和組織者都是在使用mostly-positive test套件。很多的開發(fā)者很難像攻擊者一樣的思考，只是錯誤的通過廣泛的測試不可能發(fā)現(xiàn)的原因。
通過negative測試的就是起初的半自動的過程，您可以開發(fā)出可以執(zhí)行計算機可處理的規(guī)范，并生成大量測試結(jié)果的工具…之后看看是否可以控制它。
另一個使用negative測試的重要條件就是是否有一個標準，可能合作開發(fā)一個獨立的普通測試工件作為FLOSS項目。之后可以通過快速測試所有當前和以后要執(zhí)行的方法，并且阻止使用者遇到問題。我強烈的推薦使用SSL/TLS協(xié)議開發(fā)一般目的測試工件;不然會減少效果，這會增加應(yīng)用的安全性。單獨的應(yīng)用也需要使用附加測試來補充單一測試，但是一般的大測試套件是很有用的。
軟件測試是一個完整的領(lǐng)域。存在著不同類型的測試方法和測試范圍標準。我只能在本文中總結(jié)測試。更一般的信息可以看下Paul Ammann and Jeff Offutt 的Introduction to Software Testing。但是要理解這個：只用使用有效的輸入來測試來發(fā)現(xiàn)這多的問題，如心臟出血漏洞。
我不知道在整個negative測試中依靠什么，或是其他什么單獨的技術(shù)，對于安全來說。動態(tài)的方法很自然，在真實輸入空間只能測試一個微不足道的部分。但是這種方法很容易發(fā)現(xiàn)安全漏洞。
3.2 地址核對和標準內(nèi)存分配在fuzzing
不幸運的是一般的fuzz測試方法在這種情況下是不能很好使用，但是我們可以學(xué)習(xí)簡單的過程。如果可以使fuzzing對一系列的地址進行有效果的、容易的核對和使用。這種類型的工具能偵測到在執(zhí)行過程中讀溢出和加寫溢出，并且常常發(fā)現(xiàn)其他的存儲問題。
許多的工具能夠完成對地址的核對;每一種工具都有兩面性。但是，如果你沒有使用其他的什么工具，我強烈的建議你嘗試下address sanitizer。
address sanitizer簡單有效;它只是一個在LLVM/clang和gcc中建立的附加的標志。address sanitizer沒有什么神奇的;它只是擅長偵測緩沖區(qū)的讀寫溢出問題，釋放后使用或是雙重釋放。它也能偵測到use-after-return和存儲泄漏。它不能發(fā)現(xiàn)所有的存儲問題，但是這是一個很好的工具。它的表現(xiàn)超出平均的73%，使用2x-4x的存儲。這種表現(xiàn)一般和測試環(huán)境是無關(guān)，在偵測這些問題時它很少被提到，在測試過程中Chromium和Firefox網(wǎng)頁瀏覽器都使用的address sanitizer。要了解更多可以去看USENIX 2012或是address sanitizer網(wǎng)頁。
還有其他的工具能夠偵測內(nèi)存的使用和分配地址的問題。很多人使用guard pages來檢測讀和寫在緩存。Valgrind被廣泛使用和廣受歡迎;valgrind在檢測內(nèi)存時能發(fā)現(xiàn)很多的問題包括在堆棧中讀溢出。另一個廣泛使用的工具是electric fence。在運行不同的fuzzer時可以使用不同的工具。
一般情況下，使用fuzz測試時你必須打開你能打開的所有的探測設(shè)備。第一個fuzzer偵測時使用這種機制“沒有改變的程序崩潰或是死掉?”并且很多的fuzzer還只能做這個。你必須要加強程序的訪問，并且要開發(fā)盡可能多的訪問。你可以增加額外的核對來確保中間和最終程序語句的正確。要不是心臟出血漏洞的出現(xiàn)，你至少應(yīng)該打開無效的內(nèi)存訪問探測器，如address sanitizer。
許多的工具包括address sanitizer和基于程序的guard page，要求這些程序具有測試正常分配和釋放內(nèi)存的能力。特別是，程序沒有必要使用符合分派準測的機制。至少，這個程序應(yīng)該可以輕松地使用正常分配方法用于fuzz測試。
一個相對的方法是concolic測試，CREST就是一個基于C的concolic測試的自動測試過程工具。但是CREST目前只能用于象征性為線性整數(shù)的運算，所以它能在這種情況下工作。更一般的是現(xiàn)在的concolic測試工具不可能發(fā)現(xiàn)心臟出血漏洞。如果哪個人說他確認concolic測試發(fā)現(xiàn)了心臟出血漏洞，請讓我知道。
大家一直都在為fuzzers是否比negative測試復(fù)雜而爭論不休，但是這只是我的推理。negative測試的一個優(yōu)點是它很容易入手;假設(shè)你已經(jīng)有了一個測試套件，你就可以開始negative測試。更重要的是negative測試能快速給出一個模糊導(dǎo)致問題的答案，他們要求計算能力很少的開發(fā)者使用每一種方法來獲得重復(fù)測試套件。相反，fuzz測試要求更好的計算能力和對結(jié)果的解釋;計算能力不算什么，這會影響到對開發(fā)者的反饋速度。一個潛在的更快negative測試的反饋能夠是開發(fā)者更快的實現(xiàn)檢測和修復(fù);今天最大的問題就是開發(fā)者的時間，而不是計算時間;一個最好的機制能減少開發(fā)過程的復(fù)雜度。你也可以在某個特定的協(xié)議下，使用negative測試套件;你能夠在每個測試設(shè)備和實施方法中輕松的重新使用測試套件。當然，這不存在什么沖突;最好使用fuzz測試和negative測試兩種方法。
3.3 編輯內(nèi)存分配標準和使用address guard或是sanitizer
如果在對抗來自潛在的漏洞攻擊，在未知的環(huán)境里你現(xiàn)在就要使用一個程序怎么辦呢?
一個方法就是使用偵測在分配的內(nèi)存的最后區(qū)域來實現(xiàn)讀的機制，但是使用這種方法你不能改變測試怎么運行;這個觀點就是你實際上用的在一個分配要求下的多重分配機制。
存在運行時間偵測漏洞的多種機制;這就是一些例子：
1、Address sanitizer。你要重復(fù)調(diào)試一個程序時可以使用它。在LLVM/clang和gcc編輯器上Address sanitizer就是一個標志，這相對與C程序的軟件簡單的多，這占了平均運行的73%，和2x-4x的存儲。這不是你想只能手機上做的，很多繁忙的網(wǎng)站不歡迎這些。現(xiàn)在的計算機比過去的有更好的能力和存儲，一些環(huán)境中就會被接受…這就是你能夠立刻對抗未知攻擊的可能性。Address sanitizer在偵測一長系列潛在問題上很有作用，包括大量無效的緩沖區(qū)訪問。Address sanitize不是在所有的編輯器里都無效;這要在其他的如C, C++, 和Objective-C編輯器中來添加它。
2、Intel Memory Protection Extensions。MPX新增了叫邊界寄存器的寄存器來控制指針的邊界，使用新的指令來運行和使用邊界。MPX使用Skylake架構(gòu)，但是在2014年這些CPU不能和公眾見面。這要更長的時間被廣泛的得到使用，那不能組成non-Intel系統(tǒng)。
3、內(nèi)存分配保護頁面。一些系統(tǒng)內(nèi)存分配能夠在分配一個用來組織讀和寫的內(nèi)存后，添加一個未定的保護頁面。這些能否會禁止和阻止心臟出血漏洞，這些取決于它是如何實施的。OpenBSD的malloc的實施支持保護界面。在OpenBSD中，G選項會導(dǎo)致“使用保護頁面后的每個頁面分配到的數(shù)據(jù)大小過大，這些會導(dǎo)致訪問錯誤?！边@會與P選項進行組合來移動一個頁面內(nèi)的分配。OpenBSD機制可以啟動特定的程序，甚至是特定的默認情況下，在整個系統(tǒng)中啟動，這樣就可以在更多的環(huán)境下得到保護。OpenBSD的malloc機制有一個弱點：即使開啟G和P兩個啟動項，少量的分配不會立刻完成保護頁面。如果OpenBSD的保護界面機制能夠在較少量的分配后立刻插入一個保護頁面，我認為會更好，即使這可能會對速度和內(nèi)存大小有很大的影響。但是即使是這樣，開啟G和P就意味著所有大于半頁的分配會立刻跟隨一個保護頁面，并且分配一個半頁或是更少將會泄漏半頁。這就會明顯的減少泄漏規(guī)模，相比于原來心臟出血漏洞攻擊時泄露的64K。內(nèi)存分配必須要對齊，所以保護頁面可能泄漏一些字節(jié)的信息，這就取決于如何實施的。我懷疑Address sanitizer要比增加保護頁面的分配快，但是添加保護頁面不要求更多的程序來進行重新編譯，這就是它的優(yōu)勢。不幸運的是GUN的libc中malloc不能有附加的這些功能。
當然，這種方法假設(shè)你有一個能啟動(1)的內(nèi)存保護機制和(2)內(nèi)存保護機制也會在這種機制下工作。很多的機制可以對抗緩存寫溢出，不是緩存讀溢出，心臟出血漏洞就利用了讀溢出。例如：GUN的libc中的malloc()可以選擇MALLOC_CHECK_。這就是防止寫溢出的方法，但是我不認為它能對抗類似心臟出血的讀溢出。同樣，Dmalloc’s fence-post檢測“在程序從這個區(qū)域中讀取時不能注意到，只有在寫入時才會有通知?！蔽矣X得GUN的libc和一些類似的運行過程中也要增加類似OpenBSD的malloc的保護頁面機制，從而對抗讀溢出。
這是一個可以減少傷害的方法，而不是一個消除個問題的辦法。從安全的角度來看這種方法把缺少保密變成了缺少實用。然而在很多的情況下這是一個很好的協(xié)議。一旦受到攻擊，這個方法就會使問題變成可視化的，一旦問題可視化后就變的很好改正了。
這個方法很容易和honeypot或honeynet聯(lián)系在一起。在honeypot或honeynet系統(tǒng)上設(shè)置這些硬化的方法。如果攻擊者試圖破壞軟件，這個軟件不會崩潰，并且會記錄下攻擊者的重要日志和追蹤記錄。Forensics就會偵測到一些專門利用一日0攻擊。我認為通過一些日志記錄結(jié)合入侵偵測系統(tǒng)來進行追蹤;在硬化密碼庫中發(fā)生了崩潰，就會特意的記錄下。這就會使普遍的偵測利用一日0攻擊更加的容易。分布核心基礎(chǔ)設(shè)施組織和在互聯(lián)網(wǎng)上其他組織都可以建立這些類保護我們。
雖然這種方法并不能完全解決這個問題，但是他能提供一個有力的緩解功能。一些發(fā)行者或組織可能需要在特定情況下使用這些措施，或至少使這些措施變得更容易。
修改代碼不會很復(fù)雜，并且重新編譯也是很簡單的。不過，在很多的設(shè)備上性能的欠佳都體現(xiàn)的很顯著，可能是你失去了硬件后的性能。特別是在使用Address sanitizer時，你會失去一半的速度。因此，我指望使用這種復(fù)雜的解決方法，就要考慮到硬件的消耗。在很多的情況下，會影響到運行，在智能手機上就會降低運行速度和電池的壽命，對于當前流行的服務(wù)器的話，也會減慢反應(yīng)速度和增加電量的消耗。如果將來的CPU能支持Address sanitizer，對速度的影響就會顯著的降低了。我希望CPU制造商能考慮下這點。
3.4 關(guān)注各個領(lǐng)域的手動檢測驗證
漏洞的代碼是人為審查的，顯然只有一個人來審查是不行的。
然而，大量的工作就要有專門的人來檢查每個領(lǐng)域，為確保得到有效的驗證，有時會在計算機安全中得到一個不好的名字。我懷疑的原因之一就是有時候，那些部署清單的人在做什么，之后也不能很好的利用它。但是出色的飛行員經(jīng)常使用儀表盤，他們知道是做什么的。如果補丁是他們使用清單上工具后的唯一成果，“必須證明每一個不可信的數(shù)據(jù)字段進行驗證，”之后這個漏洞被反擊。
列入人為檢查/審計的一部分，和一些簡單的方法不同。然而，這確實要就檢測人能了解所有的補丁，它不能依靠以前的代碼來得到幫助。
3.5 對文件包括注解系統(tǒng)的配置源代碼的弱點分析
傳統(tǒng)的源代碼弱點分析是找不到心臟出血漏洞，因為他們使用的是通用的啟發(fā)式方法，代碼復(fù)雜，在這種情況下不能很好的起到作用。它總是你能看到的最簡潔的代碼，但是基于你要完成的任務(wù)總是會有一些復(fù)雜性，真實情況下人類是不能達到完美的簡約。Coverity公司正在開發(fā)一些新的，他們認為能夠檢測到心臟出血漏洞的啟發(fā)方法…并且對他們是有好處的。至少有一個人已經(jīng)使用了類似的啟發(fā)方式。事實上，我希望所有的代碼分析工具都能得到改善，從而發(fā)現(xiàn)他們以前不能發(fā)現(xiàn)的漏洞。但通用的啟發(fā)方式在某個特定的時間點只能達到這個程度，你能做的更好嗎?
回答是肯定的，它叫做為上下文配置的源代碼弱點分析工具?；舅枷胧?，你開始使用一個惡源代碼弱點分析工具，之后你在提供更多的你要分析的程序的信息。這種方法比僅僅運行源代碼弱點分析工具需要更多的時間，而這些額外的信息通常要和一個特定的工具聯(lián)系在一起。然而，提供你需要的程序的信息，源代碼弱點分析工具可以能更好的工作。
Klocwork已經(jīng)表示這種方法對心臟出血漏洞是很有效的。
現(xiàn)在讓我們來談?wù)勛⑨屜到y(tǒng)。在很多的地方來為靜態(tài)分析工具提供這種額外的信息。一個常用的方法就是對程序添加額外的注釋機制，在修改程序時會使用他們。這些注解可能在更改的代碼中進行添加，添加在注釋中，或是加在單獨的文件里。使用C的工具或是注解包括Microsoft’s SAL、splint、Deputy、Oink/CQual++、cqual、和Frama-C ANSI/ISO C。你可以很容易得出添加這些信息確實是一個不同的技術(shù)。
認真的使用這些額外的注解來對抗漏洞就要有很大的工作量，如果從現(xiàn)存的代碼來說。對于C來說存在許多不同的不兼容的注釋系統(tǒng)。對于他們來說是沒有什么標準的，這會進一步的阻礙他們的使用。畢竟，它需要添加注釋和這些注釋會把你鎖到一個特定的工具中;Microsoft SAL會有更多的問題，沒有FLOSS的應(yīng)用和這只能在Windows上使用。我認為如果針對每個主要的編程語言包括C在內(nèi)，任何一種單一被廣泛接受的標準注釋符號，注釋系統(tǒng)將會更加廣泛的應(yīng)用。當沒有這么個符號時，像C語言等語言就會很難得到那樣一個協(xié)議。Peter Gutmann已經(jīng)寫了一些他的經(jīng)歷。
但是，注解系統(tǒng)是由一些好處的，注解系統(tǒng)能夠發(fā)現(xiàn)簡單的漏洞，不用在轉(zhuǎn)變成不同的語言。他們也很少去轉(zhuǎn)變成不同的語言，當然，這并不沖突;你可以切換語言，使用一種新的語言在注釋系統(tǒng)中。