行政院國家科學委員會專題研究計畫成果報告
資源測試的理論及應用平台開發
The Theory of Resource Testing and its Application Platform
Development
計畫編號：NSC 96-2221-E-110-038
執行期限：96 年 8 月 1 日至 97 年 7 月 31 日
主持人：鄭炳強 國立中山大學資訊管理學系
Email:
jeng@mail.nsysu.edu.tw
一、 中文摘要 隨著網際網路的發展，許多駭客利用 軟體弱點攻擊的手法使得軟體測試面臨 嚴峻的挑戰。根據 CSI/FBI 調查報告顯 示，阻斷式服務攻擊名列過去三年中造 成重大損失的網路攻擊前五名，而其中 利用軟體資源不當耗用的弱點往往是攻 擊者最常使用的手法。雖然目前有一些 針對軟體資源耗用漏洞所發展的測試方 法，但其所呈現的結果卻相當的原始。 本研究回到軟體測試的定義。發現傳統 的軟體測試之所以無法有效發現軟體弱 點，其原因在於傳統測試的目的在於發 現程式的邏輯錯誤，而資源不當耗用並 不屬於邏輯問題。本研究從為軟體測試 加上一個新的定義，並從資源耗用的角 度提出兩個基本測試準則。測試人員可 依照這些測試準則並結合現有工具對程 式進行更有效地資源耗用測試，以找出 程式在資源耗用上不健康的行為。 關鍵詞：軟體測試、記憶體洩漏、資 源測試 AbstractFollowing the expansion of internet infra-structure, network attacks that exploit some software vulnerability are becoming more and more popular. The report by CSI/FBI shows that Denial-of-Service remains in the top 5
highest loss due to network attacks in the past 3 years. Among them, exploiting the software vulnerabilities are the commonest techniques being used in an attack. Although there are some methods proposed to detect the resource usage vulnerability in recent years, the results are still primitive. My research returns back to the fundamental; we give software testing a new definition based on resource usage analysis, and propose 3 useful test criteria. Testers could use them as guidance in existing tools to test the resource usage of the program. With the help of these criteria, testers can find out the unhealthy usage of software resource efficiently.
Keywords: Software Testing, Memory
Leakage, Resource Testing
二、緣由與目的 在已過軟體發展的歷史裡，軟體測試 曾有許多不同的定義。50 年代的軟體測 試被定義為「程式員在他們的程式裡尋 找缺陷所做的行為」[1] 。到了 60 年代 末和 70 年代初，軟體工程開始萌芽。當 時的軟體測試變成儘可能依據程式碼路 徑，或者透過列舉輸入資料集的方式， 對軟體做徹底的測試。
80 年代的軟體測試被給予包括預防 缺陷等擴大性的含義。例如，根據 Boris Beizer [2]的說法，設計適當測試案例的 行為是已知最有效的缺陷預防方法之 一。並且由於測試成本的快速增加，人 們也開始認識到，測試需要經過計畫及 管理。 90 年代初期軟體測試的思想從偵測 轉為預防，能夠提早測試軟體品質的技 術受到重視。透過審查、排演等複核方 法，軟體測試被重新定義為「計劃、設 計、建構、維護、執行軟體測試，以及 維護測試環境」[3]。 上面的歷史回顧可以發現，軟體測試 的意義會隨著時代、環境、及需要而跟 著調整與改變。那麼，現今的軟體測試 是否符合我們的需求呢？讓我們來看一 下今日的軟體測試做些什麼。 典型的軟體測試主要有兩類[2]：功能 性測試(Functional Testing)與結構性測試 (Structural Testing)。功能性測試又稱為 黑箱測試(Black-Box Testing)，主要目的 就是針對系統功能做測試，不考慮系統 內部的結構，把程式當作是個黑盒子， 只考慮輸入值和輸出結果是否符合系統 所期望的規範。結構化測試又稱為白箱 測試(White-Box Testing)。顧名思義，白 箱測試主要針對程式的結構來設計測試 案例。結構測試的目的，可用測試涵蓋 率(test coverage)來表達，亦即測量程式 執行所經過的片斷，是否可以完整地覆 蓋所有程式的結構。 上述兩種測試無論哪一種，它們所要 偵測的都是程式的行為表現，希望尋找 出其中潛在的缺陷（fault）。因此，這 兩類測試依照我們的術語，都可被歸類 為『行為測試』，亦即檢驗程式所表現 出的行為是否符合預期。 但除了驗證邏輯行為的表現之外，軟 體測試是否就沒有其它方面需要注意了 呢？從安全的角度來看，許多日常的電 腦應用如今都已轉移到網路上執行（例 如，Google 已經在網路上提供大部分 Microsoft Office 軟體的基本功能），在 四周充滿惡意駭客伺機攻擊的情形下， 如何驗證軟體的安全性顯然也是一個重 要的測試目標。 或許有人會認為，透過偵測並阻擋惡 意網路攻擊的方式也可避免系統遭受破 壞。這或許是事實，但道高一尺魔高一 丈，根本的問題還在於軟體本身是否存 在有弱點，可被駭客加以利用。倘若本 身不犯錯，則駭客再厲害也無可奈何。 這才是網路軟體應思考的安全重點，也 是軟體測試無可逃避的責任。 什麼是軟體潛在的弱點？我們知道 今日的電腦由於功能強大，因此工程師 們在開發程式時，通常只注意邏輯指令 的安排，很容易忽略軟體程式的執行是 需要消耗系統資源的（如佔用之記憶 體、請求之服務等）。一般的假設是這 些資源要就有，而多數時候也的確如 此；因此程式的一切運作如常，使得我 們忽略了它的存在。這就形成了潛在的 漏洞：「當系統資源不足時程式所出現 的異常行為」。這就是駭客攻擊的巧門， 而一般的軟體測試也不知道要如何偵測 此一情況。 三、結果與討論 問題描述 資源耗用上所產生的系統問題，常見 的情況有軟體老化(Software aging)[4]等 現象。例如，經由長時間重複地執行某 些程式會造成系統執行速度變慢，甚至 更嚴重時出現意外的軟體錯誤或是當機 的情形。而背後的原因又以記體洩漏的 情況最為嚴重。
然而要如何測試呢？首先我們必須 知道，資源使用不當並不是一種錯誤， 因為它只是浪費了一些系統資源，並不 會反映在系統的邏輯行為上。當使用者 執行該程式時，依然可以得到預期的結 果。因此若要尋找隱藏在程式中的安全 漏洞，必須發展出一種新的測試技術， 且其測試目標非關乎程式邏輯的正確 性，而在於驗證程式在資源使用上的「健 康性」，以確保程式連上網路執行時， 某些地方不會被駭客利用來攻擊。 資源測試(Resource Testing) 為了回應以上的問題，這裡我們正 式定義了一個新型的軟體測試：『資源 測試』，並說明其意義與特性。 傳統行為測試所在意的，是程式邏 輯的正確性，至於達到某項任務所耗用 的系統資源，則不在其關心的範圍。資 源測試正好與此相反，它是從資源耗用 的觀點來觀察程式在各種系統資源使用 上的表現，目標是尋找資源使用不當的 現象。至於程式在行為上的表現，則不 屬於其關心的範圍。因此，資源測試與 行為測試在目標上是兩種互補的軟體測 試活動。 其次，資源測試與行為測試在幾個 面向上不同。第一，資源測試的錯誤行 為不明顯。經過分析，我們發現記憶體 的不當使用包含三種情況：記憶體洩漏 （memory leak）、緩衝區溢位（buffer overflow）以及雙重釋放（double free）。 當這些問題發生時，系統並不一定立刻 失效（failure）。第二，資源測試不需要 考慮全部的執行路徑，我們只需要關心 記憶體資源有變化的相關指令或運算即 可。最後，資源測試關心的是系統的狀 態而非程式的邏輯。因此通常需要輸入 多組測試資料（multiple test runs）來執 行，而非一般測試通常只要一組測試資 料（single test tun）即可。
從以上分析可以看出，資源測試與 行為測試是兩種不同類型的測試：目標 不同、特性不同，並且測試手段也不同。 因此我們需要建立一套全新的測試規範 與準則（test criteria），以便能回答諸如， 我們需要輸入怎樣的測試案例，如何才 能發現系統資源使用的恰當與否，以及 何時測試才可以結束等問題。 由於資源的誤用，通常是由程式碼 的疏忽所引發的。因此，在某個面向上 它類似於結構測試；除非以適當的測試 資料涵蓋，執行過必要的程式碼，否則 我們就無法確知是否已全面檢驗過該程 式的資源使用情形。另一方面，由於許 多的程式運算並不牽涉到資源耗用的變 化，因此我們又可省略掉某些程式段落 的查核。 我們分析了資源耗用的生命週期模 型來探討上述問題的答案。基本上資源 的耗用遵循以下的模式：取得－運算－ 釋放，不斷地循環（參考圖一）。以記 Create function Modify function Dispose function Start End 圖一、系統資源耗用模型
Memory block created
All the paths which pass both the create and dispose-free node should be tested. return 憶體洩漏和雙重釋放的錯誤來看，其實 是同一問題的兩個不同面向；前者是取 得了記憶體但沒有釋放，而後者是釋放 了一次以上。無論何者，其背後都牽涉 到要求（e.g., malloc()函數）與釋放（e.g., dispose()函數）記憶體的有關指令，而錯 誤就發生在這兩者其中之一的指令誤用 上。 另 一 種 情 況 則 發 生 在 運 算 （ e.g., modify()之類用戶提供的函數）相關的指 令上；程式師在計算的過程中不小心變 更了記憶體大小卻不自知。 綜合以上分析，最後我們可得出兩 個資源測試的準則：基本涵蓋（basic coverage）與建立與無釋放對（create and dispose-free pair）。前者類似於語句涵蓋 準則（statement coverage criterion），其 要求較簡單，只要所有與釋放以及（資 源）運算有關的指令都經過測試案例驗 證至少一次即可。 第二個準則較為複雜，首先它需要 辨認出從程式結束點循路徑反推，能夠 走 得 最 遠 的 無 釋 放 節 點 （ dispose-free node），亦即從此一節點以下不會有釋 放記憶體之類的指令。一旦找出這樣的 節點，我們就可以將所有的建立（create） 與無釋放節點（dispose-free node）配對 （參考圖二）。第二個準則要求所有這 樣的組合都需要經過測試驗證。 至於測試結果的驗證（test oracle）， 則是另一個需要解決的問題。由於資源 耗用的變化不會顯現在程式的輸出行為 上，因此很難以人為加以判斷。所幸市 面上有一些記憶體分析工具可用，例如 purify[5]或其他類似軟體[6, 7]可以分析 資源耗用的變化。 為了驗證我們的測試準則是否有 用，我們設計了一個實驗，並選擇一個 網路上公開的資料庫 CVE（Common Vulnerabilities & Exposures）[8]作為我們 驗證的對象。該資料庫共有 78 支程式， 但扣除其中一些非開源碼或過於老舊的 程式之後，我們留下了其中 21 支程式加 以檢驗。幸運的是，這些程式全都可透 過以上我們所建議的兩項測試準則加以 發掘。（詳細資料可參考表一） 此外，在實驗的過程中，我們並且 整理出資源不當使用的各種程式類型片 return return return 1 2 3 4
Memory block disposed
5
6 7 8
9
段。未來此一部份可以當作教材提醒程 式 設 計 師 注 意 ， 或 者 作 為 經 驗 法 則 （heuristic rules）實作在軟體測試輔助工 具裡，以提升測試的效率。然限於空間， 這裡我們省略這些類型的介紹，未來將 會在適當的論文裡發表。 四、計畫成果自評 雖然我們將資源測試當作全新的議 題來處理，但是與資源有關的測試實務 過去已經存在。例如，所謂的效能測試 （Performance testing）、負載測試（Load testing），或壓力測試（Stress testing） 等，都是對軟體的效能（performance） 表現進行測試。只是它們所針對的都是 某些特定的情況。例如，效能測試用於 評估分散式系統，或者多層式系統的各 節點間的負載壓力，以供分散各節點負 載之用；負載測試與壓力測試，則是要 了解系統的穩定性及最大的壓力忍受 度，以及測試系統的崩潰底限與崩潰後 的恢復能力[9-12]。軟體老化的研究[4, 13]，某種程度也與本研究所探討的議題 相關。 雖然以上這些研究都觸碰到軟體的 效能表現與系統資源的使用，但多數這 類研究並未如我們一樣，從全面性的角 度來看待資源使用不當的問題，並且也 沒有提出清楚的測試準則。因而其結果 通常只能應用在某些特殊的情況或假 設，並且由於其終止程式測試的判斷， 一般設定為直到系統當機或時間終了， 因此不但耗時而且也無助於分析根源問 題之所在。當我們能夠清楚地定義出『資 源測試』的概念後，前面的這些測試實 務未來都將受惠於我們所提出的測試準 則與方法。 隨著服務導向的應用程式日趨複 雜，傳統的軟體測試方法已不足以應付 今日網路安全的需求。而一般程式設計 者易於忽略的系統資源使用不當的弱 點，因此常被攻擊者所利用。在本計劃 的創新，在於我們首先提出資源測試的 新概念，並定義了兩個重要的測試準則 與可用的測試先知（test oracle）。 雖然如此，這裡所做的只是起步。 未來的研究者可以繼承這裡的結果繼續 擴充，或者利用我們所提出的測試準 則，建構一個合適的測試環境，尤其是 針對嵌入式系統這類對於資源使用十分 敏感的應用，如手機等加以測試。我們 預期未來這樣的需求會愈來愈多。 本研究完全達到先前第一年計畫書 所規劃的目標（應用平台開發實作部分 屬於第二年的目標）。學術應用價值以 如前面闡述。我們會在最近的未來將本 成果寫成 SCI 學術論文發表。 五、參考文獻
[1]. Hetzel, B., The Complete Guide to Software Testing, QED Information Sciences, Wellesley, Mass. 1988.
[2]. Beizer, B. 1990 Software Testing Techniques. John Wiley & Sons, Inc. [3] Hetzel, B., "Software Testing: Some
Troubling Issues and Opportunities", BCS Special Interest Group in Software Testing, Dec 6, 1991. p. 707-726. [4] Garg, S., et al. A Methodology for
Detection and Estimation of Software Aging. in Proceedings of the 9th International Symposium on Software. 1998.
[5] Hastings, R. and B. Joyce, Purify: Fast detection of memory leaks and access errors. 1992. p. 125-136.
[6] Valgrind. http://www.valgrind.org/. [7] David, E., Static detection of dynamic
memory errors. 1996, ACM Press. p. 44-53.
[9] Lionel C, Briand, Yvan Labiche, Marwa Shousha. Using genetic algorithms for early schedulability analysis and stress [8] CVE. http://cve.mitre.org/.
表一：CVE 相關程式的測試結果列表
Num CVE# Version Related criteria Related problem
CVE-2002-0069
1 Squid 2.4 STABLE3 Create-dispose free pair Memory leak
2 CVE-2002-1232 Ypserv 2.2 Basic Memory leak
3 CVE-2003-0032 Libmcrypt 2.4.10 Basic Memory leak
4 CVE-2003-0132 Apache 2.0.44 Create-dispose free pair Memory leak
5 CVE-2004-0113 Apache 2.0.48 Basic Memory leak
6 CVE-2004-0222 openBSD 3.4 Create-dispose free pair Memory leak
7 CVE-2004-0427 Linux 2.4.25 Create-dispose free pair Memory leak
8 CVE-2004-1335 Linux 2.6.9 Basic Memory leak
9 CVE-2004-2395 Passwd 0.68 Basic Memory leak
10 CAN-2004-0642 MIT Kerberos 5 1.3.4 Create-dispose free pair Double free
11 CVE-2004-2660 Linux 2.6.9 Create-dispose free pair Memory leak
12 CVE-2005-0096 Squid 2.5 STABLE 7 Create-dispose free pair Memory leak
13 CVE-2005-2800 Linux 2.6.13 Basic Memory leak
14 CVE-2005-3858 Linux 2.6.12 Basic Memory leak
15 CVE-2005-2970 Apache 2.1.8 Create-dispose free pair Memory leak
16 CVE-2006-0451 Fedora directory server Basic Memory leak
17 CVE-2002-0059 Zlib 1.1.3 Basic Double free
18 CVE-2003-0015 CVS 1.11.4 Basic Double free
19 CVE-2007-1521 PHP 4.46 Create-dispose free pair Double free
20 CVE-2007-1522 PHP 5.2.0 Basic Double free
testing in real-time systems. Genetic Programming and Evolvable Machines, pages 145-170 Volume 7, Number 2 / June, 2006.
[10] McGee, P. and Kaner, C. 2004. Experiments with high volume test automation. SIGSOFT Softw. Eng. Notes 29, 5 (Sep. 2004), 1-3.
[11] Berndt, D. J. and Watkins, A. 2005. High Volume Software Testing using Genetic Algorithms. In Proceedings of the Proceedings of the 38th Annual Hawaii international Conference on System Sciences (Hicss'05) - Track 9 - Volume 09 (January 03 - 06, 2005). HICSS. IEEE Computer Society, Washington, DC, 318.2.
[12] Jian Zhang and S. C. Cheung, Automated test case generation for the stress testing of multimedia systems, Software: Practice and Experience, vol 32 Issue 15 pages 1411-1435, 2002.
[13] Y. Huang, C. Kintala, N. Kolettis, and N. D. Fulton. Software Rejuvenation: Analysis, Module and Applications. In Proc. of 25th symposium on Fault Tolerant Computer Systems, pages 381-390, Pasadena, California, June 1995.
