2.4. 오픈 소스가 保安에 유리한가?

保安에 對한 오픈 소스 方法의 影響에 關해서는 保安 專門家들에 依해 많은 論議가 있어왔다. 主要 爭點들中의 하나는 오픈 소스가 攻擊者와 防禦者를 包含해 모든 사람이 檢討할 수 있게끔 소스 코드를 드러낸다는 것으로 分別있는 사람들은 이 狀況의 窮極的인 影響에 關해 異議를 갖고 있다.

다음은 이 主題를 考察해왔던 사람들로부터 若干 引用한 것이다. Bruce Schneier 은 賢明한 엔지니어들은 ``保安課 關聯된 모든 것을 위해 오픈 소스 코드를 要求"해야 한다고 主張하며 [Schneier 1999] 또한 오픈 소스 소프트웨어를 保安敵으로 만들기 爲해 充足되어야 하는 必須 條件들의 一部를 論議하고 있다. Advanced Encryption Standard (AES) 暗號化 알고리듬 開發者인 Vincent Rijmen 은 리눅스의 오픈 소스 本質이 더욱 많은 사람들이 保安 脆弱性 (vulnerability) 을 調査할 수 있을뿐만 아니라 더욱 重要하게 모델이 사람들에게 더욱 분명한 코드의 作成과 標準을 固守하게끔 하기 때문에 이들의 發見 및 修正을 더욱 쉽게 만드는 優秀한 方法을 提供한다고 믿고 있다. 따라서 이는 保安 檢討를 손쉽게 한다 [Rijmen 2000]. Elias Levy (Aleph1) 은 記事 Is Open Source Really More Secure that Closed? 에서 오픈 소스 소프트웨어를 保安敵으로 만드는데 있어 問題點들의 一部를 論議하고 있는데 그의 要約은 다음과 같다:

그래서 모든 이것이 오픈 소스 소프트웨어가 保安에 脆弱하게 될 때 非公開 소스 소프트웨어보다 좋지 않다는 것을 의미하는가? 그렇지 않다. 오픈 소스 소프트웨어는 틀림없이 이에 對應되는 非公開 소스 소프트웨어보다 더욱 保安敵으로 될 可能性을 갖고 있다. 그러나 誤解하지 마라 單純히 오픈 소스라고해서 保安을 保證하지는 않는다.

John Viega 의 記事 The Myth of Open Source Security 도 또한 이 爭點을 論議하고 있는데 다음 方式으로 要約된다:

오픈 소스 소프트웨어 프로젝트는 非公開 소스 프로젝트보다 더욱 保安敵으로 될 수 있다. 그러나 오픈 소스 프로그램을 保安敵으로 만드는 바로 그것, 卽 소스 코드의 可溶性과 많은 數의 使用者들이 保安 구멍을 찾아 修正할 수 있다는 事實이 사람들로 하여금 保安에 對해 잘못된 認識을 갖게 할 수 있다.

Michael H. Warfield 의 Musings on open source security 는 保安에 對한 오픈 소스 소프트웨어의 影響에 對해 더욱 더 肯定的이다. Fred Schneider 는 오픈 소스 코드를 檢査하는 많은 사람들이 시스템 保安을 損傷시킬 수 있는 버그들을 識別하는데 成功할 것이라고 믿을 理由가 없다고 말하며 ``코드內의 버그들이 支配的인 攻擊 方法은 아니다"라고 主張하면서 오픈 소스가 保安에 도움이 되지 않는다고 믿고 있다 [Schneider 2000]. 그는 또한 오픈 소스는 構築 過程의 制御를 排除한다고 主張하고 있는데 그러나 모든 主要 오픈 소스 프로그램들이 名聲있는 ``所有者" 의 하나 또는 若干의 公式 버전을 갖고 있듯이 오픈 소스의 實際 構築 過程에는 制御가 있다 . Peter G. Neumann 은 ``오픈 박스 소프트웨어 (아마도 但只 어떤 條件下에서만 소스 코드를 얻을 수 있는) 가 實際로 시스템 保安을 向上시킬 것인가? 나의 答은 可能性이 考慮될 수 있음에도 不拘하고 바로 그것에 依한 것은 아니다"라고 말하면서 이를 論議하고 있다 [Neumann 2000]. TruSecure Corporation 은 오픈 소스 會社인 레드햇의 後援下에 왜 그들이 오픈 소스가 保安에 더욱 效果的이라고 믿는지에 對한 論文을 作成하였다. Natalie Walker Whitlock's IBM DeveloperWorks article 는 또한 贊反 兩論을 論議하고 있다. Brian Witten, Carl Landwehr 과 Caloyannides [Witten 2001] 은 소스 코드를 使用可能하게 하는 것은 시스템 保安에 유리하게 作動한다고 暫定的으로 결론지은 記事를 IEEE 소프트웨어에 發表하였다; 그들은 다음과 같이 言及한다:

우리는 이 論議로 부터 네 가지 追加的인 結論을 이끌어 낼 수 있다. 첫番째 소스 코드에 對한 接近은 使用者들로 하여금 시스템 保安을 向上시키도록 한다 -- 使用者들이 向上시킬 能力과 資源을 갖고 있다면. 두番째 어떤 境遇에 있어 오픈 소스 生命 週期가 惡意的이지 않은 缺陷에 對해 덜 脆弱한 시스템을 만들어냄을 制限된 테스트가 나타내고 있다. 세番째 세가지 運營 體制에 對한 調査는 한가지 오픈 소스 運營 體制가 12個月에 걸쳐 알려졌지만 패치되지 않은 脆弱性의 形態에 두가지 所有權이 있는 運營 體制가 經驗한 것보다 더욱 적은 露出을 經驗하였다. 마지막으로 非公開 所有權이 있는 시스템 開發 모델은 덜 保安的인 시스템이 더욱 利益이 되지 않는 限 더욱 保安的인 시스템을 配置하고 支援하는 것에 對해 妨害에 直面해 있다. 이러한 結論에도 不拘하고 이 重要한 問題에 對한 論議는 發達 段階에 있으며 顧客에게 넘겨지는 保安을 反映할 수 있는 metrics (測定 基準) 를 切實히 必要로 하고 있다.

때때로 存在하지만 알려지지 않은 脆弱性은 惡用될 수 없으며 그래서 시스템은 實際로 保安的임이 特히 言及되고 있다. 理論上 이는 옳지만 問題는 一旦 누군가가 脆弱性을 發見한다면 發見者가 이의 受精을 돕는 代身 團地 脆弱性을 惡用할 수도 있다는 것이다. 따라서 脆弱性이 알려지지 않았다고 해서 實際로 脆弱性이 없어지는 것은 아니다; 이는 單純히 脆弱性이 언제든 惡用될 수 있는 時限 爆彈임을 意味한다. 根本的으로 누군가 自身이 發見한 脆弱性을 惡用하는 問題는 오픈 및 非公開 소스 시스템 모두에 對한 問題이다. 소스 코드가 없는 시스템이 이러한 意味에서 더욱 保安的이다고 論議되어 왔는데 이는 攻擊者가 얻을 수 있는 情報가 적기 때문에 攻擊者가 脆弱性을 發見하는 것은 더욱 어려울 것이다. 이에 對應되는 論議는 攻擊者는 一般的으로 소스 코드를 必要로 하지 않으며 그들이 소스 코드를 使用하길 願한다면 소프트웨어의 소스를 再生性하기 爲해 디셈블러를 使用할 수 있다는 것이다. 非公開 코드가 保安 脆弱性에 對해 어떻게 調査될 수 있는가에 對한 한가지 論議에 對해서는 Flake [2001] 을 보라. 反對로 防禦者는 소스 코드가 없다면 普通 問題를 찾지 못할 것이며 따라서 소스 코드가 없다는 것은 攻擊者와 比較해 防禦者를 不利한 處地에 놓이게 한다.

때때로 要求되는 한가지는 사람들이 脆弱性에 對한 警告를 公表하여 이를 論議하지 않아야 한다는 것이다. 이는 理論上 좋게 보이지만 問題는 攻擊者가 이미 많은 채널을 통해 脆弱性에 對한 情報를 流布한다는 것이다. 要約하면 이러한 接近 方法은 防禦者를 攻擊당하기 쉽게 만드는 反面 攻擊者를 沮止하기 위해 할 수 있는 일은 없다. 過去에 會社들은 脆弱性 發表를 積極的으로 妨害하려고 했지만 一般的으로 脆弱性이 (脆弱性이 修正되어야 한다고 强力하게 主張할 수 있는) 使用者에게 널리 알려지고 나서야 會社들이 脆弱性을 修正했음을 經驗을 통해 알 수 있다. 이것이 ``完全한 發表" 贊成論의 모든 重要한 要素이다. Gartner 그룹은 ``Commentary: Hype is the real issue - Tech News" 라는 CNET.com 技士에 率直한 註釋을 달았는데 다음과 같이 말하였다:

마이크로소프트사의 컴퓨터 保安 對應 센터 管理者 Scott Culp 의 意見은 情報에 對해 오래된, 進行中인 戰爭에서의 흔한 後斂句를 되풀이하고 있다. 情報의 配布에 關한 道德性의 論議는 過去로 거슬로 올라가서 매우 잘 알려져 있다. 몇 世紀前에 例를 들어 敎會는 太陽이 太陽系의 中心이라는 코페르니쿠스와 갈릴레오의 理論을 억누르려고 하였다... 마이크로소프트 製品內의 最近의 수많은 脆弱性을 ``情報 保安 專門家"의 탓으로 돌리려는 Culp 의 試圖는 아무래도 率直하지 않다. 아마도 이는 그러한 製品을 構築했던 會社에 對한 非難을 빗나가게 하려는 試圖를 나타내고 있다... 모든 關係者의 努力이 繼續的으로 改善이 進行되는데 도움이 된다. 脆弱性이 더욱 널리 알려지면 질수록 더욱 빠르게 修正될 것이다.

오픈 소스 프로그램에는 하나의 會社에 依해 適用된 制御가 없기 때문에 사람들이 트로이 木馬 (Trojan Horses) 및 다른 惡意있는 코드를 揷入할 수 있도록 한다고 때때로 論議되어 왔다. 트로이 木馬는 오픈 소스 코드에 揷入될 수 있으며 이는 事實이다. 그러나 이는 所有權이 있는 코드內에도 揷入될 수 있다. 不滿을 품거나 買收된 雇用人이 惡意있는 코드를 揷入할 수 있으며 많은 會社에서 오픈 소스 프로그램에서 보다 덜 發見될 것같다. 結局 組織 外部의 누구도 코드를 檢討할 수 없고 코드를 內部的으로 檢討하는 會社는 거의 없다 (또는 檢討한다 하더라도 檢討된 코드가 實際로 使用되고 있는 코드임을 確信할 수 있는 사람은 거의 없다). 非公開 소스 會社가 나중에 告訴당할 것이라는 생각은 거의 證明되지 않았다 ; 거의 모든 라이센스는 모든 保證을 否認하며 法院은 一般的으로 소프트웨어 開發 會社가 法的 義務가 있다고 判決하지 않는다.

볼랜드社 (Borland) 의 Interbase 서버가 이에 該當하는 재미있는 境遇인데 1992年과 1994年 사이에 볼랜드社는 그들의 데이타베이스 서버인 ``Interbase" 에 意圖的으로 ``백도어 (back door)" 를 揷入했는데 이 백도어는 모든 로컬 또는 遠隔 使用者에게 모든 데이타베이스 客體의 造作 및 任意의 프로그램들을 設置할 수 있도록 했으며 어떤 境遇는 ``루트" 權限으로서 머신을 制御할 수 있게까지 하였다. 이 脆弱性은 적어도 6年間 製品에 그대로 있었는데 어느 누구도 이 製品을 檢討할 수 없었으며 볼랜드社는 이 脆弱性을 除去할 動機가 없었다. 그리고 나서 볼랜드社는 2000年 7月에 소스 코드를 公開했으며 ``Firebird" 프로젝트가 이 소스 코드를 갖고 作業을 하기 始作해 2000年 12月 Interbase 와 關聯된 深刻한 이 保安 問題를 暴露하였다. 20001年 1月 CERT 는 CERT advisory CA-2001-01 로 이 백도어의 存在를 公表하였다. 脈빠지는 것은 바로 백도어가 單純히 프로그램의 아스키 덤프 (ASCII dump, 一般的인 크래커의 手法) 를 檢査함으로써 쉽게 發見될 수 있다는 것이다. 이 問題가 오픈 소스 開發者가 코드를 檢討하는 동안 發見되었다면 빠르게 패치되었을 것이다. 勿論 패스워드를 알려지지 않게 保管함으로써 프로그램은 安全한 狀態로 있었고 소스 오픈이 프로그램을 덜 保安敵으로 만들었다고 主張할 수도 있다. 著者는 이를 터무니 없는 主張이라고 생각한다. 왜냐하면 아스키 덤프는 대수롭지 않은 일이고 標準 攻擊 技法으로 잘 알려진 것이기 때문에 모든 攻擊者가 脆弱性을 公表할만큼 갑작스런 衝動을 가지지는 않았을 것이다 - 事實 이 脆弱性이 많이 惡用되지 않았음을 確信할 어떠한 方法도 없다. 소스가 오픈된 後 소스 코드는 여러番 檢討되었으며 脆弱性이 發見되어 修正되었음은 明白하다. 이를 특징짓는 한가지 方式은 元來 코드는 脆弱했고 처음 소스가 오픈될 때 이 脆弱性을 惡用하는 것은 더욱 쉬웠지만 結局 이러한 脆弱性은 修正되었다고 말하는 것이다.

소스 코드를 오픈했을 때의 長點은 攻擊되어지는 소프트웨어 뿐만아니라 脆弱性 評價 스캐너에도 擴張된다. 脆弱性 評價 스캐너는 設定된 시스템에서 意圖的으로 脆弱性을 찾아낸다. 最近의 Network Computing 의 評價는 가장 優秀한 스캐너 (다른 무엇보다 가장 規則에 맞는 脆弱性을 發見했다) 는 오픈 소스 스캐너 人 Nessus 임을 알아냈다 [Forristal 2001].

그래서 最終 結果는 무엇인가? 著者는 個人的으로 프로그램의 소스가 처음 오픈될 때 種種 脆弱性이 露出되어 모든 使用者에 對해 덜 保安的으로 始作하지만 時間이 지난후 (假令 몇年後) 에는 非公開 프로그램보다 더욱 保安敵으로 될 可能性을 갖는다고 믿고 있다. 但只 프로그램의 소스를 오픈하는 것이 갑자기 프로그램을 保安敵으로 만드는 것은 아니며 오픈 소스 프로그램을 保安敵으로 만든는 것은 保證되지 않는다:

• 첫番째 사람들은 正말로 코드를 檢討해야 한다. 이는 論議되는 主要 要點中 하나이다 - 사람들이 正말로 오픈 소스 프로젝트에서 코드를 檢討할 것인가? 모든 種類의 要因들이 檢討量을 줄일 수 있다: 특수한 用途에 맞는 製品인가 (niche) 또는 거의 使用되지 않는 製品인가 (勿論 이 製品이 檢討될 可能性은 거의 없다), 開發者가 적은가, 그리고 거의 使用되지 않는 컴퓨터 言語를 使用하는가. 分明히 한사람이 開發하며 다른 어떤 寄與者度 없는 프로그램은 이러한 種類의 檢討를 받지 못한다. 한便 主要 著者와 가끔 코드를 調査하고 寄與하는 많은 다른 사람이 있는 프로그램은 코드를 檢討하는 (最小限 寄與를 하는) 다른 사람들이 있다고 넌지시 말한다. 一般的으로 더욱 많은 檢討者가 있는 境遇 누군가 缺陷을 識別할 可能性이 一般的으로 더욱 높다 - 이것이 ``many eyeballs" (많은 檢討者) 理論의 基礎이다.

  特히 檢討 可能性을 줄일 수 있는 한가지 要因은 實際로 오픈 소스로 하지 않는 것이다. 어떤 벤더들은 發表한 소스 (disclosed source, 또한 소스를 얻을 수 있는 source available) 프로그램들을 오픈 소스라고 티를 내고 싶어하지만 프로그램 所有者가 相當히 獨占的인 權限을 갖기 때문에 다른 사람들이 코드 所有者를 위해 無料로 作業할 마음을 더욱 갖지는 않을 것이다. 별나게 MPL 과 같은 非對稱 權限을 갖는 오픈 소스 라이센스도 이 問題를 갖고 있다. 結局 사람들은 다른 어떤 사람이 自身들의 結果에 對해 自身은 갖고 있지 않은 權限을 갖는다면 自發的으로 參與할 것 같지는 않다 (Bruce Perens 는 ``누가 다른 누군가의 無報酬 雇用人이 되길 願하는가?" 라고 말하고 있다). 特히 動機를 갖고 있는 大部分의 檢討者들은 프로그램을 修正하려고 하는 사람인 境遇가 많기 때문에 이러한 參與하려는 意欲을 妨害하는 것은 檢討者들의 數를 저하시킨다. Elias Levy 는 오픈 소스 保安에 對한 그의 記事에서 이 誤解를 하였다; 그가 例를 들었던 破壞된 소프트웨어 (예, TIS 의 Gauntlet) 는 그 當時 오픈 소스가 아니었다.

• 두番째 코드를 開發 및 檢討하려는 사람들은 保安的인 프로그램의 作成 方法을 알아야 한다. 바라건대 이 冊이 도움이 될 것이다. 分明히 많은 檢討者가 있더라도 아무도 찾지 못한다면 檢討者의 數는 重要하지 않다. 사람들이 코드 變更의 調査 方法을 안다면 모든 사람이 保安的인 프로그램의 作成 方法을 알 必要는 없음을 注目해라.

• 세番째 一旦 發見된다면 이러한 問題點들은 빠르게 修正되어 配布될 必要가 있다. 오픈 소스 시스템은 問題點들을 빠르게 修正하는 傾向이 있지만 配布가 늘 순조로운 것은 아니다. 例를 들어 OpenBSD 開發者들은 保安 缺陷에 對해 매우 優秀한 檢討를 하지만 確認된 問題點들을 元來 開發者에게 늘 알려주지는 않는다. 따라서 한 시스템에는 修正 버전이 있지만 다른 시스템에는 缺陷이 남아있는 것도 可能하다.

오픈 소스의 다른 長點은 問題點을 發見하는 境遇 卽時 이를 修正할 수 있다는 것이다.

要約하면 오픈 소스 소프트웨어가 保安에 미치는 影響은 많은 卓越한 專門家들이 더욱 保安敵이 될 可能性이 있다고 믿고 있음에도 不拘하고 保安 共同體에서 아직도 主된 論議 對象이라는 것이다.