觀點

弱點研究是否道德?

2009 / 06 / 29
Bruce Schneier、Marcus Ranum 譯者 ■ 林佳明
弱點研究是否道德?

    想要控制某個人的電腦,標準的方法就是攻擊電腦裡所安裝軟體程式上的弱點。在1960年代當緩衝區溢位成為第一個攻擊電腦的攻擊程式,以上的說法就開始成為定律。在1988年當Morris蠕蟲在網際網路上透過Unix的弱點來攻擊電腦,以上的說法就代表著事實,而且直到現在大部分的惡意程式還是一樣採用同樣的方法透過網路利用弱點來進行攻擊。

   弱點是軟體的錯誤,在規劃與設計時的錯誤,以及更大多數的時候是在程式撰寫上的錯誤。任何大型軟體套件都會有著數千個以上的錯誤。這些弱點在我們的軟體系統中沉睡,等待被發現。一旦這些弱點被發現, 它們就可以被用來攻擊系統。這也是安全更新著眼的重點:排除已知的弱點。但是有許多的系統沒有安裝安全更新,導致網際網路上還充斥著許多含有已知弱點可被攻擊的系統。

   新的弱點也是炙手可熱的商品。當駭客發現了一個新的弱點就可以將之拿到黑市上進行販賣、利用這個發現來勒索廠商、或者是不顧後果的將之公開。就算是他不打算進行以上的任一行為,事實上這個弱點還是被某人知曉,進而增加了每一個使用這項軟體使用者的風險。基於這樣的理由,研究新的弱點是否合乎道德?

  安全工程師使用和其他工程師不同的角度來觀看世界。不同於聚焦在系統如何運行,他們專注於系統是如何失效的、系統是如何可以被造成失效,以及如何預防或者避免再一次的失效。大部分的軟體弱點不會在正常的操作中浮現,只在某個攻擊者傳送攻擊程式時才會顯現。因此安全工程師必須以攻擊者的角度進行思考。

  有的時候缺乏安全定見的人會認為自己可以設計出安全的產品,事實上卻是他們無法設計出安全的產品。您可以檢視目前社會上對於所有期望設計出安全產品的結果是什麼,像是印度蛇油加密(註)、軟體、網際網路協定、投票機、以及儲值卡和其他支付系統。這些產品中有許多系統都會有某個人來負責肩負起它們產品中的「安全」,不過看來他們都沒有被教導要以駭客的角度進行思考。

  這個定見是難以被傳授的,而是由某些您可能已經擁有或者未擁有的東西所形成的。但是為了訓練人們擁有這個定見,他們必須一再不停的去搜尋並尋找安全弱點。不論是在哪一個領域這條規則都是事實。好的密碼破解者會在其他人的演算法與協定中發現弱點。好的軟體安全專家在其他人的程式碼中找出弱點。良好的機場安全設計師會找出破壞機場安全的新方法。其他各個領域也是如此。

  當某個人展示我不認識的人的安全設計時,我會問的第一個問題是, 「這個設計師曾經破壞過什麼?」 任何人都可以設計出他自己無法破解的安全系統。因此當某人宣告:「這是我的安全系統,而且是連我也無法破壞的系統。」您的第一個反應應該要是:「你是誰呀?」 如果他是某個曾經破壞過多個類似系統的人,他的系統才值得留意。如果他不曾破壞過任何東西,那麼這個系統也不會有多好。

  弱點研究是必要的,因為它可以訓練我們下一個世代的電腦安全專家。是的,最近在軟體與機場被發現的弱點將我們暴露在風險之下,但是它們也提供了更可靠的資訊讓我們了解現行安全的強度。當然在處理一個新弱點的時候總是或多或少要面對責任與法律上的問題。但是壞份子正在持續不斷的搜尋新的弱點,如果我們期望要能夠讓我們的系統安全,我們就需要良好的安全工作人員扮演這些壞份子的部份角色。對我而言,問題不在於弱點研究是否道德。如果有人擁有能夠深入並分析問題的能力,卻反而要求他不准進行弱點研究這樣就合乎道德了嗎?

Marcus Ranum反面觀點

  M o r r i s蠕蟲所使用的其中之一的弱點是B S Dfingerd(8)所存在的緩衝區溢位弱點。Bruce認為找出並公告弱點可以幫助改善軟體的品質,但是最近20年來的軟體發展(請勿稱呼為軟體工程)情況卻明顯的駁斥了這個觀點。

  我們不但還是存在著緩衝區溢位的問題,而且在任何一個單一分類中的弱點從來沒有被消除過。那些提倡弱點 「研究(research)」的簇擁者犯了一個基本的錯誤: 如果您想要改進什麼,您必須針對問題的類型來尋找解決方法,而不是針對單一的事件。一般來說,目前弱點「研究(research)」的狀況還停留在「針對一個軟體重要的程式片段來尋找弱點以吸引他人的目光、取得廠商的感謝函、以及從弱點市場中獲利。」這不是「研究」,完全只是單純的「尋找(search)」。

  弱點競賽中的經濟體系並沒有包含「讓軟體變得更好」這個選項。然而,它真正達成的是「讓軟體變得更貴」。當我過去開始投入軟體產業的時候,當時10%的維護費用已經是令人驚訝的高標了,但是現在的公司卻需要投入20%到25%的維護費用。為什麼會這樣?弱點競賽讓廠商找到了可以綁住用戶的新理由,如果您停止購買維護服務並且停止產品定期升級的輪迴,那麼駭客就可以透過您這些過期的軟體來進行破壞。

  我同意Bruce其中的一個觀點,就是您必須以失效模式(failure modes)的角度來進行思考並建立起預防失敗的機制。或者是,像Bruce所說的「以駭客的角度進行思考」。所以事實上一切都跟了解失效模式有關,不論是駭客所引發的錯誤或者是使用者的輸入錯誤,軟體必須要能夠進行正確的動作。一切都是程式撰寫時應注意的事項:輸入檢查、失效安全(fail safely)、不去期望使用者閱讀手冊等。

  但是我們不需要有數千個知道怎麼學壞蛋思考的人,我們最多只需要數十個這樣的人才就好。新型態的錯誤類型並不常發生,我記得最近一個嚴重的問題是Paul Kocher對於CPU/timing攻擊公開金鑰(public-key)原理的論文。當他在1996年公佈這個消息的時候,密碼學團體便新增這類型的問題到它們的研究工作清單中並處理這類問題。為什麼軟體發展沒有做出類似的反應?以緩衝區溢位這個類型的問題為例,我們可以看見像是微軟這樣的軟體巨人花費數百萬嘗試找出程式碼中的每一個緩衝區溢位來減少這類型的弱點,卻不真正想辦法去解決這個問題。

  對於弱點競賽,人們犯下最大的錯誤就是認為「揭露問題可以帶來幫助」。 我可以證明這是多麼錯誤的想法,就簡單的以Web 2.0為例。

  我們在設計Web 2.0的時候,是否在過去20年的程式撰寫經驗中取得任何教訓?當然沒有!我甚至無法說出Web 2.0是有經過設計的。如果說展示哪些弱點可以被使用能夠鼓勵軟體開發者更小心的進行程式撰寫,那麼在Web 2.0上根本沒有發生過這樣的結果。

  信任模式(Trust model)那是什麼東西?弱點「研究者(researchers)」已經磨練好它們的武器準備好面對接下來的盛宴。如果我們真的關心讓軟體更加安全,我們應該改善軟體發展環境,讓開發者能夠輕易的寫出安全的程式碼,使用最少的資源來修正所有類型的弱點。

  如果Bruce的觀點是弱點「尋找」能夠教導我們如何產生更好的軟體,那麼軟體應該除了變得更貴更複雜之外還有變得更好。可是事實上,令我害怕的是軟體只有變得更貴更複雜卻沒有更加安全。

Marcus Ranum是Tenable Network Security的CSO,亦是知名的安全技術改革者與講師。更多資訊歡迎造訪其網站 www.ranum.com。

Bruce Schneier是BT Counterpane的CTO,也是Beyond Fear一書的作者。更多資訊歡迎造訪其網站
www.schneier.com


編註:印度蛇油加密(snake-oil cryptography)意指某些不安全的商業加密產品。