開放源碼與資訊安全

網絡效應是否有效？                  

開放源碼是否具安全性的優勢？這一直是有爭議的話題。咸信微軟在世界各國推展政府分享源碼計畫，其目的就是為了減低政府單位對於微軟系統的不信任感，藉由可信賴者檢視原始碼細節，希冀掌握系統核心真實用意。但分享或開放源碼果真能化解資訊安全的疑慮？另外一個話題是開放與封閉源碼的安全爭論。有人以為封閉源碼比較安全，因為實作細節不公開，可以避免被破解。有人以為開放源碼比較安全，因為所謂的「網絡效應(Many Eyeballs Phenomenon)」─“With enough eyeballs, all bugs are shallow” (Eric Raymond)，只要有足夠的人注意、檢視源碼，所有問題都會被發掘，包括資訊安全的問題。

我們希望澄清這些爭議。微軟分享源碼計畫也是基於「網絡效應」，想藉由多方人員的源碼檢視、化解隱藏暗門(trapdoor)疑慮，而國內在微軟分享源碼計畫之前，也多有這樣的共識，常疾呼國人必須掌握自己的核心程式碼（包括作業系統、IC Card OS）、重要密碼系統必須由國人掌握原始碼。這些都是基於相同的「網絡效應」而起的想法。

幾個論點

我們不想潑冷水，也不因自己是開放源碼的擁護者、而大力擁護「網絡效應」對於資訊安全的幫助。但希望大家不要過度期望。這有幾個論點：

一、網絡效應對於分享系統穩定性、不符規格的程式問題(bug)有極大的助益，但對於系統安全方面的問題則幫助有限。原因是因為網絡上許許多多的「眼球」通常會因多方面的測試環境與使用方式，發現導致系統不穩、當機、不符規格的狀況，也因此可以迅速通報。但系統安全方面的 bug 通常是「刻意製造」極為誇張的輸入資料才能被發現，再多的「普通眼球」都比不上一個「刻意」的技術黑手(hacker)。對於「刻意」的黑手用戶，有無源碼已經沒有顯著差別。我們通常這樣區分兩類的程式問題，一個是有關穩定性(reliability)的「天災」，另一個是有關安全性(security)的「人禍」。前者通常可經由合法或不正常的輸入驗證，但後者卻必須由蓄意製作的惡意輸入(maliciously corrupted input)才能發覺，後者的輸入範圍遠超過前者。

二、封閉源碼對於資訊安全的保護有限。這可由兩方面探討。一是現代密碼學的概念與重要原則─不要藉由隱藏方法或不公開實作來增加系統的安全性，唯一必須保持機密的是「金鑰（key）」。同樣的，對於資訊系統也千萬不要以為隱藏實作可以免於被破解。第二是反向工程 (reverse engineering) 的工具與方法進展神速，有無原始碼已經無顯著差別。

三、若有意留下暗門或後門，幾乎不可能被發現。我們一般以為留暗門就是安插一段類似木馬的程式，經由「網絡檢視」，可以找出木馬所在。這是錯誤的想法。若有意留暗門，可以使用多種幾乎不可能被發現的方式佈放。一種是有意的「語意錯誤（semantic error)」程式片段，例如在 C 程式碼中，等號 (equality, ==)與分派符號(assignment, =)常被錯用，因此在程式中「故意錯用 assignment」，如 if (pass = aStrangeConstant)。而另一種超級後門撰寫方式，稱為「溢寫」(buffer overflow) 型木馬，也就是故意留下有溢寫問題的程式碼，撰寫很容易，引用 strcpy() 、 gets() 等程式庫函式即可。更複雜者，甚至留下多重呼叫後的溢寫問題(經由 pointer aliasing, incompatible type binding)，這就幾乎不可能經檢測而得、遑論網絡的人工檢視了。

結論

不要因為資訊安全而有開放源碼或不開放源碼的決策考量[1]。上述論點已經澄清幾個相關問題，是否開放源碼與資訊安全沒有必然的關係。很多人以為微軟的安全弱點多，因此以為封閉源碼軟體比較不安全，有人辯護說微軟的使用者較多，因此較容易發現安全問題。這樣的論點事實上卻又與「網絡效應」相矛盾，因為微軟並未開放源碼，至於微軟的安全弱點數量是否較多，我們並無客觀數據可以佐證。微軟宣稱，多數弱點是公司內部經由正規檢測而得，技術黑手透過反向編譯修補（patch）檔案而找出問題。不管事實如何，資訊安全的決策考量仍不應受制於源碼開放與否。

更積極的作法

開放源碼的安全不應再寄望於網絡效應，就如同微軟曾為了宣示對安全的重視程度，一度停止所有程式開發工作幾個月、專注於程式品質與安全的檢視。封閉源碼的龍頭老大，其內部的「網絡效應」應該甚為驚人，但真正成效有限、仍必須不斷釋出「security patch」。開放源碼的安全也不能寄望於功能的精簡（通常越精簡越安全），Mozilla 社群常引以為傲，因為不支援 ActiveX 而躲開 IE 為人詬病的安全威脅，卻也因此排除了為數甚多的潛藏用戶。不管是開放、分享、或封閉源碼，其安全都應值基於軟體品質的提昇，微軟研究單位進行之 ESP 計畫[2]可以自動檢測上百萬行程式，這類正規品質驗證系統適用於開放或封閉源碼。不要再陷入利用分享源碼以排除木馬的迷思，自行開發或寄望掌握源碼，其後果常是引入更多的軟體缺陷。更積極的方式是重視軟體品質（Software Quality）、導入正確的程式安全(Secure Programming)開發原則。我們也因此在交通大學資工系設立軟體品質實驗室，積極從事正規化的品質驗證研究，藉此提升軟體安全與可靠性。

參考資料

1.      John Viega, Gary McGraw, Chapter 8, Building Secure Software, Addison-Wesley Pub Co; 1st edition (September 24, 2001).

2.      Error detection via Scalable Program Analysis, http://research.microsoft.com/esp/