アカウント名:
パスワード:
Damien Miller 氏によれば、暗号そのものは恐らく安全であろう、とのことです。http://permalink.gmane.org/gmane.os.openbsd.tech/22559 [gmane.org]
何かを仕込むとすればネットワーク関連のコードで、鍵データがパディングに混入するようにしたり、秘密データに隣接する部分を読むとき「うっかりはみ出す」ようにしたり、mbuf を「うっかり再利用する」ようにしたり、タイミング攻撃によるサイドチャネル (2000年当時はあまり知られていなかった) を用意したりといった可能性が思いつく、と書いています。
そのうちの幾つかは対策が取られていますが、すべて疑念を晴らすには地道なコード監査以外ないようです。
フレームの元だけどこのバックドアも含めてソースが配布されていたのだろうからオープンソースならコード監査が出来るから安全なんて神話だよね。
公開されているから安全というのは短絡的だと思う。でも、オープンソースだからこそ、ライセンス面などで安全性の検証可能性のハードルが低いとはいえる。
ソースの公開によって確保できるのはコードの検証可能性であり、この検証可能性によって安全な利用への道が”担保”されるだけで、保証はない。しかし、今回の指摘によって誰しもが当該コードを検証することは”可能”である。（クローズドソースなら契約上、検証さえできない場合がある。）少なくとも、検証を必要とする人間・組織がコードを直接検証できることはオープンソースの強みだろう。
もちろん検証する能力や資源は別の問題としてあるが、これはクローズドソースでも当てはまる。
>オープンソースだからこそ、ライセンス面などで安全性の検証可能性のハードルが低いとはいえる。
検証自体のハードルは低いかもしれない。でも、その検証の結果、まずいとなった場合、それに対応できるか？というのが、結構、面倒だと思うよ。
細かなパッチ程度で対応できたとしても、それが正式にコンパイルされ配布されるためのテストを受けて、さらにいくつもの配布先で対応するわけだろ？
>少なくとも、検証を必要とする人間・組織がコードを直接検証できることはオープンソースの強みだろう。
そういった検証を自分の責任でやらなあかんのかよ、しんどいこった...というユーザの方が多いと思うね。プロプライアリティなシステムは、その面で楽だよな..という風に考えられている様に思う。
どっちにせよ、バックドアだろうが、問題の数とそれを潰す工数が少ない方が好まれるとは思うけどね。
プロプライアリティなシステムは、その面で楽だよな..
これは、プロプラならベンダーが責任もって検証してくれそう（OSSだとコミュニティが責任持ってくれなさそう）という事なのか、ベンダーの責任に出来る（OSSだとコミュニティじゃなく選択したほうの責任にされる）という事なのか。それとも検証以前に、どこの誰ともわからん奴のコードが入り込まない（関わる社員の素性は明らかで監督もされている）が、OSSだとどこの誰とも素性のわからん、責任も持たず監督もされてない奴が入り込め、得体の知れなコードがコミットされるのを防げない、という話なのか。OSSだと悪意のあるやつでもやる気と技術をアピールすればコミュニティに入り込むのは容易であるが、プロプラだとそういう悪意のあるやつは社員になれないので安全という話なのか。要するに「検証可能性のハードルが低い」のと同時に「コードコミットのハードルも低い」のでは、オペラの社員になるよりモジラのコミッタになる方が楽、という話なのか。まあ、まじめな会社員の作るプロプラ＞ネット(≒匿名)の作るOSS、的なステロタイプが(特に日本で？)ありそうではあるが。
ただ、本当にベンダは責任もって検証してくれるの？とか、ベンダの責任に出来るといったって本当に責任とってくれるの？結果どうしてくれるの？とか、本当に社員の素性が明らかなの？下請けとか派遣とかは？とか、やる気と技術あるやつがアピールすれば入社くらい出来るんじゃないの？とか、そういう悪意持った奴の計画的犯行より、今回の様に買収とか出来心とか、それ以前に企業として組織ぐるみとか、そういう可能性を考慮しても、「プロプライアリティなシステムは、その面で楽」なのかどうか。
そんなこんなを考えると、大した違いはなさそうに思えて、それよりも自分でコードなり安全とする検証結果なりを検証することに比べたら五十歩百歩に思えたりする。
>そんなこんなを考えると、
ま、単純に言えば、顧客説明だな。どこの馬の骨ともわからない団体のわけのわkらん奴が描いたであろう、検証されていない上に悪意を防げない程度の試験と検証しか経ていないというパッチと、「○○社が提供している」パッチという比較になるわけな。
>それよりも自分でコードなり安全とする検証結果なりを検証することに比べたら五十歩百歩に思えたりする。
その５０歩の差が、世間では重要だったりするんだ。そして、自分で検証してそのコードがどうだめで、どういった危険があるか？を、いくつものシステムについて調べていくというのを、出来るのかい？このコードは問題だ...それを複数の顧客にちゃんと達意で示せないと「そんな、どこの馬の骨とも(中略)(パッチは当てられないな」で終わりなんだな、で苦労も一発でふっとぶわけだ。
最近はそれなりに、「RedHat社が当てろとか言っているパッチです」ということで、通りやすくなっているけどね。
Windowsは、MSのパッチなら当てようか？という意識が結構ある。これはなにもMSのパッチを信用しているからではないんだ。CodeRedやNimdaといった「当てなかったから酷い目にあった実績」があったからであって、unix/Linuxにはそれに比肩する程の規模の被害実績がないってことなんだけどね。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
※ただしPHPを除く -- あるAdmin
バックドアの余地は (スコア:5, 参考になる)
Damien Miller 氏によれば、暗号そのものは恐らく安全であろう、とのことです。
http://permalink.gmane.org/gmane.os.openbsd.tech/22559 [gmane.org]
何かを仕込むとすればネットワーク関連のコードで、
鍵データがパディングに混入するようにしたり、
秘密データに隣接する部分を読むとき「うっかりはみ出す」ようにしたり、
mbuf を「うっかり再利用する」ようにしたり、
タイミング攻撃によるサイドチャネル (2000年当時はあまり知られていなかった) を用意したり
といった可能性が思いつく、と書いています。
そのうちの幾つかは対策が取られていますが、
すべて疑念を晴らすには地道なコード監査以外ないようです。
Re: (スコア:0)
フレームの元だけどこのバックドアも含めてソースが配布されていたのだろうからオープンソースならコード監査が出来るから安全なんて神話だよね。
Re: (スコア:2, すばらしい洞察)
公開されているから安全というのは短絡的だと思う。でも、オープンソースだからこそ、ライセンス面などで安全性の検証可能性のハードルが低いとはいえる。
ソースの公開によって確保できるのはコードの検証可能性であり、この検証可能性によって安全な利用への道が”担保”されるだけで、保証はない。しかし、今回の指摘によって誰しもが当該コードを検証することは”可能”である。（クローズドソースなら契約上、検証さえできない場合がある。）少なくとも、検証を必要とする人間・組織がコードを直接検証できることはオープンソースの強みだろう。
もちろん検証する能力や資源は別の問題としてあるが、これはクローズドソースでも当てはまる。
Re: (スコア:2, すばらしい洞察)
>オープンソースだからこそ、ライセンス面などで安全性の検証可能性のハードルが低いとはいえる。
検証自体のハードルは低いかもしれない。
でも、その検証の結果、まずいとなった場合、
それに対応できるか？というのが、結構、面倒だと思うよ。
細かなパッチ程度で対応できたとしても、それが正式にコンパイル
され配布されるためのテストを受けて、さらにいくつもの配布先で
対応するわけだろ？
>少なくとも、検証を必要とする人間・組織がコードを直接検証できることはオープンソースの強みだろう。
そういった検証を自分の責任でやらなあかんのかよ、
しんどいこった...というユーザの方が多いと思うね。
プロプライアリティなシステムは、その面で楽だよな..
という風に考えられている様に思う。
どっちにせよ、バックドアだろうが、問題の数とそれを
潰す工数が少ない方が好まれるとは思うけどね。
Re:バックドアの余地は (スコア:0)
これは、プロプラならベンダーが責任もって検証してくれそう（OSSだとコミュニティが責任持ってくれなさそう）という事なのか、ベンダーの責任に出来る（OSSだとコミュニティじゃなく選択したほうの責任にされる）という事なのか。
それとも検証以前に、どこの誰ともわからん奴のコードが入り込まない（関わる社員の素性は明らかで監督もされている）が、OSSだとどこの誰とも素性のわからん、責任も持たず監督もされてない奴が入り込め、得体の知れなコードがコミットされるのを防げない、という話なのか。
OSSだと悪意のあるやつでもやる気と技術をアピールすればコミュニティに入り込むのは容易であるが、プロプラだとそういう悪意のあるやつは社員になれないので安全という話なのか。
要するに「検証可能性のハードルが低い」のと同時に「コードコミットのハードルも低い」のでは、オペラの社員になるよりモジラのコミッタになる方が楽、という話なのか。
まあ、まじめな会社員の作るプロプラ＞ネット(≒匿名)の作るOSS、的なステロタイプが(特に日本で？)ありそうではあるが。
ただ、本当にベンダは責任もって検証してくれるの？とか、ベンダの責任に出来るといったって本当に責任とってくれるの？結果どうしてくれるの？とか、本当に社員の素性が明らかなの？下請けとか派遣とかは？とか、やる気と技術あるやつがアピールすれば入社くらい出来るんじゃないの？とか、そういう悪意持った奴の計画的犯行より、今回の様に買収とか出来心とか、それ以前に企業として組織ぐるみとか、そういう可能性を考慮しても、「プロプライアリティなシステムは、その面で楽」なのかどうか。
そんなこんなを考えると、大した違いはなさそうに思えて、それよりも自分でコードなり安全とする検証結果なりを検証することに比べたら五十歩百歩に思えたりする。
Re:バックドアの余地は (スコア:1)
>そんなこんなを考えると、
ま、単純に言えば、顧客説明だな。
どこの馬の骨ともわからない団体のわけのわkらん奴が描いたであろう、検証されていない上に悪意を防げない程度の試験と検証しか経ていないというパッチと、「○○社が提供している」パッチという比較になるわけな。
>それよりも自分でコードなり安全とする検証結果なりを検証することに比べたら五十歩百歩に思えたりする。
その５０歩の差が、世間では重要だったりするんだ。
そして、自分で検証してそのコードがどうだめで、どういった危険があるか？を、いくつものシステムについて調べていくというのを、出来るのかい？
このコードは問題だ...それを複数の顧客にちゃんと達意で示せないと「そんな、どこの馬の骨とも(中略)(パッチは当てられないな」で終わりなんだな、で苦労も一発でふっとぶわけだ。
最近はそれなりに、「RedHat社が当てろとか言っているパッチです」ということで、通りやすくなっているけどね。
Windowsは、MSのパッチなら当てようか？という意識が結構ある。これはなにもMSのパッチを信用しているからではないんだ。
CodeRedやNimdaといった「当てなかったから酷い目にあった実績」があったからであって、unix/Linuxにはそれに比肩する程の規模の被害実績がないってことなんだけどね。
Re: (スコア:0)
検証なんて、そもそも、結果を期待してはいけません。基本的にテストセット作って、新バージョンが、旧バージョンと同等の動作をするかどうかしか確認していないことが、ほとんどです。当然、テストセットで網羅できていないケースは、数多くあり、制度を期待しては、いけません。バージョンアップに伴うバイナリーモジュールの検査なんて、そんなものです。
OSSの場合、でかいパッチが嫌われるのは、内容を把握しきれないことや、把握するための労力が大きいためです。コミュニティ内で、神のごとく信頼されている人物が、モジュールごと入れ替えるような大規模パッチを投稿してマージされた場合、悪意でバックドアを巧妙に仕込んだとしたら、検出することはかなり難しいと思います。これまでにも、多数のパッチを提供して、いつの間にか、議論の余地がある新機能を追加されていたなんてことも、よく聞く話です。