1、基于mozilla的安全性漏洞再修復經驗 研究張凱孫小兵彭鑫趙文耘復旦大學軟件學院復旦大學上海市數據科學重點實驗室摘要：相較于其他類型的漏洞，安全性漏洞更容易發生再修復，這使得安全性漏洞需 要更多的開發資源，從而增加了這些安全性漏洞修復的成木。因此，減少安全性 漏洞再修復的發生的重要性不言而喻。對安全性漏洞再修復的經驗研究有助于減 少再修復的發生。首先，通過對mozilla工程中一些發生再修復的安全性漏洞的 安全性漏洞類型、發生再修復的原因、再修復的次數、修改的提交數、修改的文 件數、修改的代碼行數的增減、初始修復和再修復的對比等數據進行分析，發現 了安全性漏洞發牛再修復是普遍存在的，且與漏洞

2、發牛原因的識別的復雜程度 和漏洞修復的復雜程度這兩個因素有關;其次，初始修復涉及的文件、代碼的集 屮程度是影響再修復的原因z-,而使用更復雜、更有效的修復過程可有效避免 再修復的發生;最后，總結了幾種安全性漏洞發生再修復的原因，使開發人員有 效地識別不同類型的安全性漏洞再修復。關鍵詞： 安全性漏洞;再修復;漏洞修復;經驗研究;作者簡介：張凱（1993-）,男，碩士生，主要研究方向為軟件維護；作者簡介：孫小兵（1985-），男，博士，主要研究方向為軟件分析、維護與演 化；作者簡介:彭鑫（1979-）,男，博-上，教授，ccf高級會員，主要研究方向為需求工程、自適應軟件、軟件產品線、軟件維護、逆向

3、工 程;e-mail:pcngxinfudan. cdu. cn;作者簡介：趙文耘（1964-），男，碩士，教授，ccf高級會員，主要研究方向 為軟件復用、軟件產品線、軟件工程。收稿日期:2016-10-07基金：國家自然科學基金(61402396, 61370079)empirical study of reopened security bugs on mozillazhang kai sun xiao-bing peng xin zhao wen-yunabstract：compared to other types of bugs, securi ty bug reopens more

4、 often, moreover, they need more development resources to fix it, which adds an extra cost to fix them. hence, the empirical study of reopened security bugs is important. our study collected the reopened security bugs from the mozilla project, and analyzed them from the times of their reopening and

5、commits, files which were modified to fix them, lines of added and deleted code, and compcirison of the original fixing and reopened fixing. the empiriccil resuits show that security bug reopening often happen and it rclates to the complexity of recognizing the reason that a security bug happens and

6、 fixing bugs. in addition, the locality of the files and code in the original security bug f ixi ng is one of the causes to in flue nee i ts re-fix ing for bug reopens, and using more complex and effective fixing process can help reduce the security bug reopens. finally, we summarized several causes

7、 for security bug reopens to help developers more easily identify the reopens of different types of security bugs.keyword：security bug; reopens; bug fixing; empirical study;received： 2016-10-071引言在軟件開發和維護過程中，開發人員常常遇到程序運行狀態與預期不符的情況， 如輸出值不正確、程序死機、數據丟失等，這種現彖來源于程序的漏洞（bug）。 開發人員如果在程序中發現漏洞的存在，則必定會停止開發工作來修

8、復漏洞， 或者投入專門的人力和物力進行漏洞修復。不論是哪種應對方案，都會不可避免 地消耗開發資源，使開發成木變得更加昂貴，直接導致開發軟件的利潤變得更 小，軟件競爭力下降。在眾多漏洞類型中，安全性漏洞是軟件開發者在軟件維護與更新的過程中重要 的關注點之一1-3。安全性漏洞是指能被攻擊者利用，以在計算機系統中獲取 未經授權的訪問或進行超岀權限的行為的一種軟件漏洞，會導致安全性缺陷， 使計算機系統陷入危險z屮。安全性漏洞不一定會導致程序崩潰或停止運行，但 其一旦被攻擊者利用，則可能會造成不可挽回的損失。有時，漏洞的修復不能一蹴而就，開發人員也不可避免地會發生修復漏洞錯誤 的情況。開發人員完成漏洞修

9、復之后會關閉漏洞，但如果發現這個漏洞未被完全 修復，為了使之修復正確，需要重新打開(reopen)該漏洞來對其進行再修復， 以避免在開發人員自認為修復正確的情況下，安全性漏洞卻悄悄造成重大的損 失o zaman等人發現，安全性漏洞相比于其他漏洞更常發生再修復。因此，對 安全性漏洞的再修復進行研究，找出再修復與初次修復的隱含關系，對于安全 性漏洞再修復的預測和提供修復意見十分重要。本文主要通過對mozillal程中發生再修復的安全性漏洞的各項數據進行統計 分析，找到安全性漏洞在再修復時存在的各種修復規律，如修改文件和代碼較 為分散的安全性漏洞較容易發生再修復，一些類型的安全性漏洞再修復會包含 初

10、始修復的修改模式、修復過程和修改的文件與代碼。這些規律可為開發安全性 漏洞再修復預測和自動化修復的工具提供經驗支持。本文第2節介紹經驗研究的一些背景知識;第3節介紹研究的設計，包括數據來 源、研究的數據和數據分類方式;第4節給出對數據分析的結果以及得到的規律; 第5節介紹相關工作;最后總結全文。2背景知識2. 1漏洞生命周期一個漏洞通常遵循圖1 5所示的生命周期。圖1漏洞生命周期下載原圖一個漏洞在被發現后會被發現者報告出來，此時漏洞發牛的根木原因、漏洞類型 等信息還不確定，這便是未確認(u7c0mftrmed)階段。下一階段就是通過錯誤 信息對漏洞發生的原因進行分析，如果是新的漏洞，就進入這個

11、新漏洞的各種 信息獲取階段(new and assigned);如果與已有漏洞相同，就標注為重復 (duplicate)。獲取完漏洞信息之后，即對漏洞進行修復，修復完成則進入解決 (resolved)階段。解決階段之后就是對修復進行驗證(verified)的階段，該 階段主要負責驗證修復是否正確，最后關閉(closed)漏洞。在解決階段和關閉階段之后，都有可能因為修復不正確或不完整需要重新打開 (reopened)漏洞來重新對其進行修復。這個重新打開階段承擔的工作就是木文 要研究的安全性漏洞再修復。2. 2安全性漏洞分類osvdb (open sourced vulnerability dat

12、abase)是一個為安全性漏洞提供準確、 詳細、及時、公正的信息的獨立且開源的數據庫。osvdb為安全性漏洞分類提供 了參考。結合對數據的分析及osvdb的參考分類，我們將研究中的安全性漏洞分 為7類回:信息泄露、拒絕服務攻擊、跨站腳本攻擊(xss)、緩存溢岀、內存 泄露、使用非法內存及其他。信息泄露是指在程序運行過程中，一些數據應該被保護或加密，未經授權的用 戶不能得到這些數據，但這些數據在某些安全性漏洞存在的情況下會被惡意用 戶獲取，從而給系統或正常用戶造成損失。拒絕服務攻擊是指使目標電腦的網絡或資源過載或耗盡，從而使服務暫時中斷 或停止，導致其對客戶不可用。跨站腳本攻擊是代碼注入的一種，

13、指在網站應用程序中存在安全性漏洞惡意用 戶通過這些漏洞在網頁中插入惡意代碼，而當用戶進入、使用該網站時惡意代碼 會被執行。惡意代碼包括javascript, java等。惡意代碼執行完之后，可能會 獲取更大的權限，竊取隱私信息等，給正常用戶造成影響和損失。程序在運行時都會分配一定大小的緩沖區，而當寫入的內容超過緩沖區大小時， 就會造成緩存溢出。若這種緩存溢出未被系統或程序察覺，則攻擊者可能破壞程 序的運行、獲得程序甚至系統的控制權，進而運行惡意代碼進行一些破壞性的操 作。內存泄露是指在程序中一些已經使用過且不再需要的內存未被釋放，使得程序 的可用內存越來越少，最后導致程序因缺少內存而使部分功能

14、被迫停止，甚至 程序崩潰。這種內存的減少并不是物理上的內存減少，而是可分配使用的內存數 量越來越少。程序中經常使用指針來儲存和操作數據，但如果這些指針是空指針、指向地址己 經被釋放或指向程序堆棧之外即不屬于程序的內存地址，則會使程序停止運行 或崩潰，這就是使用非法內存。通過這些安全性漏洞分類，可針對每類安全性漏洞進行分析，研究各類安全性 漏洞自身的特點。2.3安全性漏洞的修改模式安全性問題通常是因為攻擊者非法對數據進行訪問而引起的。在對安全性漏洞的 分析中，安全性漏洞的修復大多并不復雜，根據程序系統對數據處理的3個階 段(數據的預處理、數據處理、數據確保)對安全性漏洞的修復，總結了如表1 所列

15、的一些修改模式。表1安全性漏洞的修改模式下載原表在數據進入程序階段，即數據預處理階段，通常會對數據做一些檢測和篩選, 來防止外部數據對程序進行攻擊。在數據處理階段，即稈序對數據進行操作的階段，需要保證數據被正確、安全地 處理。在數據被程序處理完成后，系統通常會根據這些數據輸出一些我們想要的結果， 而這些結果也可能因為處理過程的不理想而出現一些錯誤。針對這種情況，需耍 進行數據確保工作，以防止錯誤的處理結果對程序造成影響。在數據確保階段， 最常用的修改模式是添加if模塊，對結果進行判斷，確認其為正確合法的結 果。安全性漏洞的修改模式相較于其他類型的漏洞更為簡單，通常是針對數據的修 改。安全性漏洞

16、的修改模式不涉及對軟件功能性的修改，只是對可能產生安全性 問題的數據在程序傳播的各個階段進行檢查、確認，針對不同的安全問題與傳播 階段添加相應的防護機制，使數據的使用變得更加安全。同時，安全性漏洞的修 改模式更具通用性，能夠將相同的修改模式應用于不同的安全性漏洞的修復， 而非安全性漏洞則難以總結出一些統一的修改模式，只能針對不同的功能模塊 得出不同的修改方法。針對以上修改模式，可以觀察安全性漏洞再修復與初始修復使用的修改模式之 間的區別和聯系。3研究設計本文的研究主要圍繞以下兒個問題展開：仃)安全性漏洞再修復的發生是否頻繁，以及與什么因素有關？(2) 哪種類型的安全性漏洞容易發生再修復且修復的

17、難度較大？(3) 初始修復與再修復在修改模式、修復過程、修改內容方面有什么聯系?3.1數據來源 本文選定mozilla作為研究安全性漏洞再修復的數據來源，它維護的全部都是 mozilla產品的安全性漏洞，且信息全面、清晰，還能在git上找到對應的提交 信息，使得研究數據豐富且全面。在對安全性漏洞的修復工作屮，moz訂la維護了一個安全性漏洞管理的社區，管 理了 2005年至今mozilla發現的所有安全性漏洞的相關信息。漏洞報告中包含許多信息，其中對研究有用的是以下兒類信息:漏洞id、漏洞描 述、漏洞修改歷史記錄、漏洞修復評論。在漏洞修復評論中，可以了解到修復人員的思考過程，從中得岀該安全性漏

18、洞 產生的原因、修復時對錯誤信息的分析、使用該種修復方式的原因、對漏洞再修 復的原因、修復完成后進行了何種測試等信息。通過對這些信息進行分析，明確 了安全性漏洞修復的全過程，從而得出安全性漏洞的類型、漏洞再修復的原因、 漏洞每次修復使用的修復方式及原因、每次修復之間的關系等。漏洞修改歷史記錄（見圖2）中包含在每個吋間點該漏洞處于何種狀態的信息， 圖2屮表的第5列出現“reopen”表示該安全性漏洞被再修復，而在接下來的狀 態中第5列出現“fixed”則表示該再修復完成。圖2 bug修改歷史下載原圖對安全性漏洞再修復進行分析時，每次修復吋代碼的提交信息是必不可少的。mozilla將他們的項目提交

19、到git上，通過git可以得到mozilla工程每次提交 的漏洞id、代碼、提交者、提交時間、修改的文件、本次提交與上次提交的代 碼更改信息、修改相關信息等。但是，git上的moz訂la工程只持續到2011年, 因此能得到的提交信息年份為2005-201 lo通過mozilla安全性漏洞社區和git 項目數據，總共獲取到48個可用的發生過再修復的安全性漏洞的相關數據，這 些安全性漏洞的id范圍為312278-672485。3.2研究內容對這些安全性漏洞數據的分析主要包括3方面:漏洞的整體情況、初始修復和再 修復的對比數據、修復過程中用到的數據。漏洞的整體情況數據包括:漏洞的id,漏洞的類型，發

20、生再修復的原因，在gil 上這個漏洞的修復提交的總次數，所有修改的文件數，所有修改增加和減少的 代碼行數，發生再修復的次數。這些數據有助于分析安全性漏洞的慕本信息中隱 含的修復規律。初始修復與再修復的對比數據包括:兩次修復時間的長短對比，兩次修復使用的 修改模式的對比，修改者的對比，兩次修復使用的修復過程的對比，兩次修復 修改的文件和文件中修改內容的對比。通過這些修復的對比數據可以得到再修復 和初始修復之間的關系，可通過初始修復推斷再修復的修改模式、修改文件與內 容、修復時需要注意的事項，從而提供更方便的再修復方法。而通過修復過程的數據（如評論、提交的代碼）對比，可以得到修復者的思路， 并可從

21、中找出安全性漏洞類型、再修復原因、修改模式、修復過程等。以上兩方 面數據，有些通過對修復過程中的數據進行統計和分析獲得。木文研究通過兩種方式進行分類:安全性漏洞的類型和安全性漏洞再修復的原 因。根據安全性漏洞的分類方式，可以統計安全性漏洞再修復發生的次數、再修復的 原因、這類安全性漏洞提交的總次數、總的文件修改數、增加的代碼行數和刪除 的代碼行數。在這些數據的支持下，對以下問題進行研究:安全性漏洞整體情況 的分析;不同類型的安全性漏洞較容易發牛哪種再修復;不同類型的安全性漏洞 在修改時修改文件、修改的代碼數量等有什么規律。通過對安全性漏洞再修復的原因進行分類，收集初始修復與再修復兩方面的數 據

22、:使用的修改模式，修復過程，修復所用的時間，修改者，兩次修改對文件及 代碼的影響。通過收集到的數據，研究如下問題:安全性漏洞再修復的原因;再修 復和初始修復使用的修復過程有什么聯系;兩次修復的修改時間和修改者有什么 聯系;兩次修復使用的修改模式有什么聯系;兩次修復修改的文件和內容有什么 聯系。4數據分析4.1基礎數據統計實驗共收集到721條安全性漏洞信息和48條發牛再修復的安全性漏洞。在 mozillal程中，安全性漏洞發生再修復的概率約為6. 7%,再修復的概率較高 i41o安全性漏洞在所有id和時間段都有發生再修復，由此可見，安全性漏洞發生再 修復是一個普遍存在且發生概率比較高的問題。通過

23、對安全性漏洞再修復的信息 進行分析，找到減少再修復、預測再修復、幫助再修復的方法，有助于提高程序 的安全性，減少開發、維護的資源消耗，使得程序員在對安全性漏洞進行修復時 更加全而、正確，減少對安全性漏洞再次修復的次數。如表2所列，在48個發生再修復的安全性漏洞中，37個發生了 1次再修復，10 個發生了 2次再修復，只有1個發生了 3次再修復，未見超過3次的再修復。在 修復安全性漏洞時，發牛1次再修復可能是對漏洞的理解有遺漏;發牛2次再修 復就需要程序員特別注意自己的修復以及對漏洞的理解是否正確;唯一一次發生 了 3次再修復的漏洞是對漏洞進行登記和測試，因此通常情況下不會發生超過2 次的再修復

24、。多次發生再修復不僅會對資源造成浪費，還會加大系統的危險性, 給攻擊者更多機會。表2安全性漏洞修復基礎數據統計下載原表發生2次再修復的安全性漏洞大多是緩存溢出，發生1次再修復的大多是跨站腳 本攻擊，其他的比例都比較接近。而這兒種類型的安全性漏洞git提交的平均次 數都比較接近，使用非法內存修改的文件數最多，內存泄露最少。在減少和增加 的代碼行數方面，內存泄露和緩存溢岀分別為減少和增加代碼行最多的，緩存 溢出和內存泄露分別為減少和增加代碼行最少的。緩存溢出和內存泄露雖然涉及的文件數較少，但是修改的代碼行數卻較多，說 明這兩類安全性漏洞問題比較集中，修復時所涉及功能的關聯性比較強。而使用 非法內存

25、和跨站腳木攻擊涉及的文件較多，但是修改的代碼行數較少，說明這 兩種安全性漏洞涉及的功能較為分散，修改的文件范圍較廣，修復吋較容易有 遺漏，考慮得不夠全面。4.2安全性漏洞再修復的原因在對數據進行分析后，得到以下兒個發生再修復的原因:加強漏洞填補（范圍加 強、強度加強）；減弱漏洞的填補;填補原來沒有考慮到的漏洞（線性關系、并列 關系）；對修復進行登記或測試；以前修復無效或錯誤而重新修復;懷疑修復造成 了錯誤，后來發現不是（誤診）。實驗中統計的48個發生了再修復的安全性漏洞中，每種類型的再修復數量如表 3所列。表3再修復類型統計下載原表從統計數據可知，除了減弱漏洞的修復數量較少以外，其他再修復的原

26、因數都 比較平均，再修復時一般會修復得比較適度或未修復完全，修復過強的情況比 較少。修復過強則表示安全性漏洞發牛的原因分析正確，且修復方式也正確，只 是限制過于強烈，避免這種再修復最好的方法是衡量好限制的強度與影響。而在 填補原來未考慮到的漏洞屮，線性關系的安全性漏洞也比較少，這種再修復的 發生是對數據源頭判斷得不準確或未考慮數據的來源，修改比較簡單，只要找 出數據的源頭并添加保護機制即可。上面的數據中有些類型再修復數據量較少， 對發現普遍性規律有一定的影響，使得偶然性大大增加。4. 2.1加強漏洞的填補 在修復安全性漏洞時，有時可能是臨時性填補，安全性還不夠高，還存在著一 些安全隱患，后續需

27、要對漏洞重新修復，從而提供更高的安全性防護；又或者可 能是修復的范圍不夠廣，同一個問題在不同的地方岀現，此吋只要將修復延伸 至更大的范圍即可。這些再修復就是對漏洞填補的加強。加強漏洞的填補可根據 加強的再修復和原修復之間的關系分為強度加強和范圍加強。可以對安全性漏洞進行臨時性填補是安全性漏洞修復的一個特點。臨時填補是為 了在沒有時間和資源進行完全修復時，盡量減少安全性漏洞的作用力和危害， 甚至用一些非常糟糕、后期難以識別維護的修復來修復漏洞。當然，這樣做只是 暫時使軟件能繼續運行，不至于因為軟件停運造成損失，在有時間和資源時重 新對漏洞進行修復，以保證修復的完整性與安全性，這就是加強漏洞修復的

28、強 度。例如，對于安全性漏洞329385,攻擊者可以利用這個安全性漏洞進行強制性鼠 標操作。初始修復吋對ut進行修改，使得與這個漏洞相關的ui界面暫吋停止相 關功能。這樣修復雖然可以解決問題，但是會造成一些功能無法使用，且真正能 夠強制操控鼠標操作的原因并沒有找到。而在再修復中找到了真止的原因，并對 其進行了修復，也使得ui的相關功能得以正常運行。另一種對漏洞修復的加強是范圍的加強，即對某個安全性漏洞的修復方式是正 確的，但是修復作用的范圍未完全包含所有岀問題的地方，再修復吋只需要將 之前的修復作用于剩下的地方即可完成完整的修復。例如，對于安全性漏洞370127,其傳遞了某個不安全的方法作為新

29、方法的父方 法，而這個新方法如果被調用，則會由于父方法產生安全性問題。一開始的判斷 是js代碼會調用到這個新方法，因此初始修復是在js調用該新方法時做一些安 全性防護，以保證調用時不會傳入不安全的父方法;后來卻發現不但js代碼會 調用該新方法，c+代碼某功能也會調用這個新方法，因此再修復要做的就是將 原來的防護方法作用于c+的調用，使得不論是哪種調用都能安全完成。4. 2.2減弱漏洞的填補與增強相反，減弱漏洞的填補也是安全性漏洞再修復的原因之一。在修復安全性 漏洞吋，如果對漏洞的防護太強，可能會導致一些功能被限制，一些合法數據 被阻攔過濾，這樣依舊會導致安全性問題。例如，對于安全性漏洞4198

30、48, js通過導入一些腳本作為其內容來使用，這樣 可能會導入不安全的腳本，在系統權限下對程序造成危害。因此，初始修復就對 js能導入的腳本進行了限制，使得某些的腳本不能被導入。但這種限制太 強，導致一些合法的腳木因含有相應的url而不能被導入，程序不能正常運行。 再修復就是導入一些程序必須但不能獲得系統權限的腳本，以保證程序安全地 正常運行。4. 2.3填補原來沒有考慮到的漏洞 一個安全性漏洞的發生可能是因為多個地方有安全性問題，這些不同地方的安 全性問題導致了同樣的安全性漏洞。而在安全性漏洞的修復過程中，如果只修復 了其中一部分安全性問題，另一部分未發現或被忽略，那么這個安全性漏洞就 是修

31、復不完整，因此會發生再修復。因為填補原來沒有考慮到的漏洞而發生的安全性漏洞再修復，可以根據具體的 安全性問題之間的關系分為兩種情況。1) 原修復和再修復是線性關系。這就好比一條河流發生洪水，如果在中流抗洪, 并不一定能達到最好的效果，而如果找到發生洪澇的源頭，在源頭治洪，效果 會好很多。例如，安全性漏洞312278發生的原因是某變量在未使用之前就被垃圾收集器釋 放了它所指向的內存地址，因此在后面使用該變量時就是使用非法內存。第一次 修復是在發現內存被垃圾收集器釋放的地方管理那個變量，使之不能被釋放掉。 但是后來發現這個變量被釋放的源頭不是這里，變量在被管理起來之前就有可 能已被垃圾收集器釋放。

32、因此，再修復就是找到變量的源頭，在源頭對變量進行 管理，使得變量不會被釋放。2) 初始修復與再修復是并列關系。初始修復和再修復解決的安全性問題不是相 同的方法或功能，它們的修復方式可能不一樣，但是都會導致安全性漏洞。這些 并列的安全性問題可能是因為難以全部找到或者經常容易被忽略，從而導致再 修復的發生。例如，安全性漏洞360529是因為可以通過某些方法獲得瀏覽器的權限來運行一 些惡意代碼，是跨站腳本攻擊。針對這個安全性漏洞的修復，自然是找出這些方 法并對它們進行保護，防止其被攻擊者利用。初始修復是對array, prototype 和document, write進行保護，并認為成功修復了這個

33、漏洞。但是后來發現 appcndchild ()和rcmovcattributc ()也會有這種問題，因此第二次修復就 是對這些方法進行保護，但其實對每個方法進行保護的方式并不相同。這種再修復原因與加強漏洞修復的范圍的區別在于，用到的修復方式不同。加強 漏洞修復范圍中，初始修復和再修復運用的修復方法是一樣的，只是作用的地 方發生了變化;而填補原來沒考慮到的漏洞(并列關系)則是初始修復和再修復 運用的修復方式可能不同，針對的安全性問題也不同，但是這些安全性問題都 會導致同一個安全性漏洞。4. 2. 4對修復進行登記或測試有時重新打開安全性漏洞并不是因為原來的修復存在問題，而是對完成的修復 進行登

34、記，比如驗證、加入實際項目中；又或者是對其進行測試，以保證修復的 安全性與正確性。這種再修復不涉及到原修復的改動，而是對原修復做一些操 作。例如，安全性漏洞410156的初始修復就已經完全解決了安全隱患，重新打開漏 洞是為了添加一些測試，使修復能在更多條件下被檢驗。4. 2.5以前修復無效或錯誤而重新修復上面發現的一些再修復都是初始修復有一定正確性，能起到一定作用，且再修 復時不會完全推翻初始修復的修復方法。但是，有時候對安全性漏洞的修復并不 那么簡單，只要發生安全性漏洞的原因分析不正確或者修復方式錯誤，都有可 能看似解決了問題，但實際上只是暫時的假象，問題不久又會再次發牛或者還 可能引起其他

35、錯誤，因此要推翻初始修復進行重新修復。這種安全性漏洞的再修 復一般會伴隨著對初始修復的回退，然后用正確的修復替換掉初始修復。例如，對于安全性漏洞349527,初始修復完成之后發現有編譯錯誤，述可能產 生數據泄露的危險，因此須對初始修復進行改正，使因修復而產生的安全性問 題都得到解決。4. 2. 6懷疑修復造成錯誤，后來發現不是最后一種安全性漏洞再修復發生的原因其實是一種誤診。由于安全性漏洞的發生 原因復雜且難以找尋，因此如果初始修復后程序產生了某些問題，開發人員可 能會對這個修復產生懷疑，認為該修復造成了這些問題。于是，程序員會對這個 修復進行回退，回退之后如果發現問題依舊存在，則說明并不是修

36、復帶來的問 題。因此，這種原因產生的再修復-般是先對初始修復進行冋退，然后發現不是 修復存在問題后又將初始修復恢復。4.3安全性漏洞的類型與再修復的原因通過統計安全性漏洞類型耳再修復的原因，即毎種類型對應的再修復原因的數 量，可以得到哪種類型的安全性漏洞更容易發牛哪種再修復。通過表4所列統計結果得到如下規律:在7種安全性漏洞中，數據泄露和拒絕服 務攻擊沒有發生再修復的情況。首先，拒絕服務攻擊在安全性漏洞屮本就較少， 所以可能不會發生再修復;另一方面，也說明這兩種安全性漏洞比較簡單、易于 修復或者修復方式是比較固定的，能夠輕易找出所有要修復的問題并進行正確 的修復，因此很少發牛再修復。由此可見，

37、在修復數據泄露和拒絕服務攻擊的安 全性漏洞時，如果能找到一個通用的發牛漏洞的原因、修復漏洞的方式，就能使 得這兩種安全性漏洞基本不會發生再修復。表4安全性漏洞類型與再修復原因統計下載原表跨站腳木攻擊發牛再修復的次數最多，內存泄露發牛的次數最少，其他的都比 較平均。跨站腳本攻擊發生再修復的原因中，剔除4個登記或測試和1個誤診, 基本上毎種再修復的原因都有涉及，說明跨站腳本攻擊的安全性漏洞發生的原 因比較復雜，因此很容易出現遺漏或錯誤，修復方式也難以做到全面保護，在 修復這類安全性漏洞吋需要投入更多的精力。特別地，僅有的3個減弱漏洞的填 補的再修復都是跨站腳本攻擊的漏洞，一方面說明減弱漏洞的填補這

38、種再修復 本身就很少，另一方面也說明了跨站腳本攻擊安全性漏洞的修復方式較其他類 型的安全性漏洞更容易發生修復過強的情況。在對跨站腳本攻擊漏洞進行修復時, 注意修復的強度與范圍，防止其影響到其他功能，有助于減少這種再修復的發 生。內存泄露一般是因為內存使用和管理不當而產生的，所以在內存使用時必須進 行分配與釋放。內存泄露的安全性漏洞發生的原因并不復雜，修復方式也比較簡 單，同時數量較少。由各種類型的安全性漏洞修改功能的集中度與各種再修復原因的分布范圍可以 看岀，安全性漏洞發生再修復的可能性與兩個因素有關：1）發生原因尋找的難 度，找到發生的是哪種類型的安全性漏洞，為什么會發生這種安全性漏洞，發

39、生錯誤的代碼在什么文件、什么位置，這些信息越復雜，就越容易忽略或遺漏一 些信息而導致再修復;2）修復方式的復雜程度，比如修改的文件的多少、這些修 改文件之間的聯系、修改的代碼行數、修復的次數，修復方式越復雜，修復時越 草率，發生再修復的可能性就越大。4.4初始修復與再修復的對比4. 4.1修復過程的對比根據表5統計的數據，基本上所有發生再修復的安全性漏洞在初始修復時都是 一次修改和提交，使用的修復過程是“修復一測試”，而在誤診的初始修復中， 使用了 “修復一部分修復”和“修復一更好的修復”兩種修復過程。這說明，僅 僅使用“修復一測試”這種修復過程難以準確、全面地進行安全性防護，導致了 再修復的

40、發生。表5修復過程的對比下載原表在對漏洞進行登記或測試的再修復中，基本只有一次修改和提交，因為再修復 并不涉及代碼的修改。再修復屮除了使用“修復一測試”夕卜，其他修復過程大多 是以前修改錯誤或無效而重新修改，因為這種再修復是推翻以前的修復進行全 新的修復，相當于修復一個新的安全性漏洞。通過使用這些修復過程來提高修復 的安全性，可避免二次再修復的發生。使用更復雜、更有效的修復過程有助于全面找到安全性漏洞發生的原因并進行更 有效、更正確的修復，減小再修復發生的可能性。4. 4.2修改時間和修改者的對比根據表6統計的數據可知，除了以前修復無效或錯誤而重新修復的安全性漏洞， 其他類型的再修復時間大多較

41、初始修復時有所減少。這說明，初始修復只要不是 完全無用，都對再修復有著參考性的作用，可以幫助尋找被遺漏的安全性問題， 提供修復方式的參考。表6修復時間與修復者的對比下載原表并列關系有一定數量的再修復吋間更長的情況。并列關系其實是修復一些并列的 安全性問題，且修復方式可能不同，導致安全性問題的原因也可能不同，因此 需要更多的時間。在修改者對比方面，除了減弱漏洞的填補、對修復進行登記或測試、誤診這3 種再修復基木上都是非同一修復者外，其他的再修復是同一修復者的占大部分。 這是因為如果同一個修復者進行再修復就不用重新熟悉該安全性漏洞，對漏洞 發生的原因、原來的修復方式都有一定的了解，就可以有更高的再

42、修復效率，從 而節省時間與資源。4. 4.3修改模式的對比針對初始修復和再修復使用的修改模式進行的統計分析如表7所列，可以通過 得岀的規律對再修復進行修改模式的推薦。表7修改模式的對比下載原表對漏洞進行登記或測試和誤診這兩種再修復基木上不涉及安全性修改，因此再 修復吋無修改模式的使用。加強漏洞的填補屮，范圍加強再修復使用的修改模式基本包含了初始修復的修 改模式，因為再修復只是將初始修復的使用范圍變大，但修復方式不變。在填補原來沒有考慮到的漏洞中，線性關系的兩次修改模式基本相同，因為兩 次修復方式完全相同，只是作用于不同的地方。其他類型的再修復使用的修改模式與初始修復使用的可能相同也可能不同，因

43、 為再修復的修復方式與以前的不同，修改模式也可能不同。4. 4.4文件修改情況的對比 安全性漏洞的修復體現在文件、代碼的修改上。通過對比初始修復與再修復修改 的文件及其內容之間的區別和關系來找出各種再修復修改時的特點。根據對數據(見表8)的分析，主要有5種文件修改的情況:相同文件，不同內 容;相同文件，相似內容;不同文件，不同內容;不同文件，相似內容;無修改。無 修改說明再修復沒有對相關代碼進行任何改動。相同文件，相似內容，說明初始 修復與再修復修改的文件是相同的，對這些文件內容的修改也是相似的。相同文 件，不同內容，則是修改文件相同，但是對文件的修改是不同的內容，對修復 的作用也不同。剩下兩

44、種都修改的是不同的文件，但修改的內容和作用的區別與 上面的定義相似。對修復進行登記或測試和誤診兩種再修復不涉及代碼修改。范 圉加強和線性關系則全是兩次修復修改相同文件、相似內容，因為它們前后的修 復方式相同，且安全性問題比較集中。并列關系主要集中在“相同文件，不同內 容”和“不同文件，不同內容”兩種情況，說明修復方式基木上是不同的。表8文件修改情況的對比 下載原表5相關工作pamela bhattacharya等人通過對漏洞報告和漏洞修復的經驗研究，識別出漏洞 報告的優劣性，找岀了漏洞生命周期對漏洞修復的影響口1。michael gegick等 人則通過對漏洞報告自然語言的描述進行自動化分析，

45、能夠找出其屮的安全性 漏洞報告，避免了浪費在尋找非安全性漏洞報告上的時間宜。這些研究給我們 漏洞報告的實驗分析提供了研究方法的參考。丁羽等人回通過對學術界關于漏洞分類學(taxonomy)和漏洞分類 (classification)的調研，總結了安全性漏洞分類的幾個關鍵性問題。li zhenmin等人10使用自然語言處理分類工具對兩個大型開源項r約29000個漏 洞進行自動化分析，找到了漏洞的一些特性和規律，并發現了安全性漏洞數量 正在增加且大部分會造成嚴重的損失。yonghee shin等人11通過9種復雜性 度量標準找到安全性漏洞與非安全性漏洞之間的區別，并對安全性漏洞進行預 測。文章中提

46、供了安全性漏洞分類和漏洞在各修復階段的特點的參考1111。shahed zaman等人4針對firefox工程屮的漏洞，比較了安全性漏洞和功能性 漏洞在各方面的不同之處。研究發現，安全性漏洞修復得越快，修復時需耍的開 發人員越多，涉及到的文件也越多，再修復發生得越頻繁趙l這些研究都是對 安全性漏洞的特征、分類進行了分析總結，而木文主要集中研究安全性漏洞再修 復的修復特征，因此這些研究可為我們提供經驗參考。最后，還有一些預測方法的研究，這些預測方法與本文角度不同，他們一般是 通過漏洞的各類靜態或運行時信息來進行再修復的預測，而本文則主要是通過 漏洞修復信息來尋找通用的預測方法。t zimmerm

47、ann等人12通過開發人員對 再修復原因的分類、漏洞報告、修復人員的關系等方面，利用靜態分析模型對漏 洞再修復的性質與預測方式進行研究，其中的分類與預測方法給本文研究提供 了參考性建議。管銘等人曲通過靜態分析和動態分析兩種程序分析技術，研究 了在軟件開發周期屮安全性漏洞檢測的技術。到目前為止，對安全性漏洞的研究主要集屮在以下方面:識別安全性漏洞4, 13-14,預測安全性漏洞8, 15-16,對安全性漏洞進行分類9-10, 17,對 安全性漏洞報告8、性質18進行研究與比較,安全模式的應用19-20,安全 性檢測21-22等,而對再修復的研究卻寥寥無幾，基木上是通過漏洞的特征、 漏洞報告等信息

48、對漏洞的再修復進行預測11型。但是因為針對的是所有漏洞, 安全性這個特點和其特殊性沒有重點考慮，因此對安全性漏洞再修復知識的研 究十分稀少。結束語 本文通過對mozilla工程中2005年-2011年共48個發生了再修復的安 全性漏洞的經驗進行研究，分析安全性漏洞發牛再修復的原因、再修復的次數、 修改的提交數、修改的文件數、修改的代碼行數的增減、初始修復和再修復的對 比（使用的修改模式、使用的修復過程、修改的時間、修改者、修改文件內容）等 數據，首先發現了安全性漏洞發生再修復是普遍存在的，且與漏洞發生原因的 識別復雜程度和漏洞修復的復雜程度這兩個因素有關;其次，了解了初始修復的 文件、代碼的集

49、中程度是影響再修復的原因之一，并且使用更復雜、更有效的修 復過程可有效避免再修復的發生;最后，總結了幾種安全性漏洞發生再修復的原 因。本研究仍然存在一些未解決的問題:未能很好地識別安全性漏洞再修復與初始修 復之間在修復方式上的區別，這對自動化再修復的研究有一定的限制。未來可以 分析更新、更多的發生了再修復的安全性漏洞的數據，著重研究規律還不明確的 幾種再修復，嘗試找出它們的預測方式，并通過再修復的歷史數據找到前后兩 次修復在修復方式上存在的聯系與區別，從而得到自動修復它們的方法，并開 發出再修復預測與自動化修復的工具。參考文獻1 tan l, liu c, li z m, et al. bug

50、 characteristics in open source softwarejempirical software engineering, 2014, 19 (6) :1665-17052 haley c b, laney r, moffett j d, ct al. security requirements engineering:a framework for representation and analysisj1eee transactions on software engineering, 2008, 34 (1) :133-153.3 viega j, mcgraw g

51、. building secure software:how to avoid security problems the right waym. addison-wesley, new york, 2001.4 zaman s, adams b, hassan a e. security versus performance bugs:a case study on firefox c /zproceedi ngs of t he8 th work ing conf ere nee on mining software repositories. new york, ny, usa:acm,

52、 2011:93102.5 zeller a. why programs fail:a guide to system atic debuggingm. san francisco, ca, usa:morgan kaufmann publishers inc., 2005.8 geg1ck m, rotella p, xie t. identifying security bug reports via text mining:an industrial case study c /proceedings of the 7th international working conferenee

53、 on mining software repositories. washington dc, usa:ieee, 2010:11-20.9 ding y, zou w, wei t. research summarize of classificeition of security bugs in softwarcc/proceedings of the 5th conference on vulncrability analysis and risk assessment. 2012. (in chinese) 丁羽，鄒維，韋韜軟件 安全漏洞分類研究綜述c 信息安全漏洞分析與風險評估大會

54、.2012.10 lt z m, tan l, wang x h, et al. heive things changed now?an empirical study of bug charactcristics in modern opcn sourcesoftwarec/proceedings of the workshop on architectural and system support for improving software dependability.washington dc, usa:ieee, 2010:11-20.lllshin y, williams l. a

55、n empirical model to predict security vulncrabilitics using code complexity metricsc/proceedings ofinternational symposium on empirical software engineering and measurement. new york, ny, usa:acm, 2008:315-317.12 zimmermann t, nagappan n, guo p, et al. characterizing and predicting which bugs get re

56、openedc/proceedings of the 34th international conf ere nee on soft ware engin eer in g. weish ington dc, usa: ieee, 2012:1074-1083.13 guan m. the research of software security bug detection technology based on the analysis of applicationd.xi' an:northwestern polytechnical university, 2007. (in c

57、hinese)管銘.基于程序分析的軟件安 全漏洞檢測技術研究d西安:西北工業大學，2007.14 z1iang l, zeng q k the static detection tech no logy of software sccur ity bug j. software engineering, 2008, 34 (12) : 157-159. (in chinese)張林， 曾慶凱軟件安全漏洞的靜態檢測技術j計算機工程，200& 34(12) :157-159.15 thome j, shar l k, brtand l. security slicing for auditing xml, xpath, and sql injection vulnerabilitiesc/proceedings of the 26th ieeeinternational symposium on software reliability engineering. washington dc, usa:ieee, 2015:553-564.161shar l k, tan h b k, brtand l.mining sql injection and cross site scripting