アカウント名:
パスワード:
そんな神話は最初からなかった
安全、という話じゃなくて、脆弱性が発見されたら公開される、って方じゃないっけ?
プロプラだと脆弱性を某ハッカーが見つけた場合、繰り返し悪用されるだけで、その実態をどのように公開するか?の道筋がわからん。
> 安全、という話じゃなくて、脆弱性が発見されたら公開される、って方じゃないっけ?
いや、オプソ教信者は、皆が監視してすぐに直されるから安全と主張していた。
ところがだ、memcopyの境界チェックすっ飛ばしなんか、調べようと思えばソースを簡単にチェックできるものなのに、長期に渡って、そして広範囲で使われるようになっても、誰も気づかなかった。
いや、気付かなかったわけではなかった…。
> プロプラだと脆弱性を某ハッカーが見つけた場合、繰り返し悪用されるだけで、> その実態をどのように公開するか?の道筋がわからん。
オープンソースなので、OpenSSL
>ところがだ、発見者は脆弱性を公開・指摘することをせずに悪用していた
この悪用していたのは”オープンコミュニティに参加していた本人なの?”
違うでしょ。「発見者(悪意あるハッカー)が通報せずに悪用する」リスクそのものはプロプラでも、オープンソースでも同じ。
どちらが安全か?という議論は「善意の発見者が通報した後、どういうシナリオになる(なりうるか)」で議論すべき事では?
ただ、それ以外に「ソースが公開されているからパッチが誰でも作れる=(安全係数)」だけでオープンソース優位と見るのは間違いだと私も思います。それ以外に
「今回のように”ソースが公開されているからこそ悪用可能な不具合をみつけ悪用する人”」もいるわけで。
> この悪用していたのは?オープンコミュニティに参加していた本人なの??> 違うでしょ。
えっと、大丈夫ですか?オープンコミュニティに参加している本人に限定するオープンソースならば、クローズドソースのソフトウェアでも開発者数は大して変わらない。
違うでしょ?オープンコミュニティが何を示しているのか意味不明だけど、そうじゃない関係ない人もソースコードが見れるんでしょ?脆弱性をソースコードから見つけることができるんでしょ?その脆弱性を開発コミュニティに指摘することなく悪用することができるでしょ?
> 「発見者(悪意あるハッカー)が通報せずに悪用
ところがだ、OpenSSLはオープンソースであり、修正したらすぐ公開された。悪意の攻撃を計画する奴は、修正個所のコードを見てすぐに攻撃コードを開発して使い始めた。ほとんど修正版への対応が進まないうちから攻撃が大量に発生してしまった。
チェック方法まとめ:OpenSSLの「Heartbleed」脆弱性は2年前から存在、「最悪のケースを想定して対処を」と専門家 [atmarkit.co.jp]より,
>ソフトバンク・テクノロジーの辻伸弘氏によると、「既に実証コードがリリースされているため攻撃を行うハードルはとても低い」。>「この脆弱性は、さかのぼると2年前から存在していたことが確認さ
> >ソフトバンク・テクノロジーの辻伸弘氏によると、「既に実証コードがリリースされているため攻撃を行うハードルはとても低い」。> >「この脆弱性は、さかのぼると2年前から存在していたことが確認されている。
> あなたの描くシナリオとはだいぶ違っているようですね.
???あなた、大丈夫?
2年前にはこの脆弱性が混入していて、誰でもソースコードを見て発見することができたわけ。そして米NSAのように、いち早く発見して悪用していた勢力もあるわけ。
やっと最近になってコミュニティが問題に気付いて修正し、公開したが、その公開情報から実証コードを作った人が居るという話。実際には実証コードが作られる前から、最悪の場合は2年前から実証コードではなく攻撃コードが使われていたわけ。
どこをみて、「シナリオとはだいぶ違っている」と思えた?
> オープンソースに限ったことじゃないよね.この2,3年で古いFlashやAdobe Reader,> java経由のアウトブレイクがどんだけあったことか.> #ネタにマジレス(であってほしい)
コンピュータの脆弱性やセキュリティに限らず、実社会での防犯セキュリティでも同じなのだけど、あなたみたいにセキュリティの問題に対して、できるだけ影響が小さいように解決する方法を気にしない、セキュリティに無頓着な人にはわからないかもしれないけれど、まず問題の詳細を公表する前に問題の解消を先にした方が安全なのだよ。
ATMに脆弱性が見つかり、カードを裏返しに入れると残高が100倍に増える現象が見つかったとしよう。銀行は「残高が100倍に増えてしまうので、カードを裏返しに入れないでください」と最初に発表するだろうか?そうではなく、この問題を直してから発表する、あるいは直したうえで発表すらしないだろう。
ソフトウェアの脆弱性を見つける難易度って言うのがある。
一番難易度が低いのは、オープンソースなソフトが修正され、修正版がリリースされた時に、修正版とのソースコードのdiffを取って見れば一発だ。これは初球プログラマーでもできレベルで、問題公開後に作られた攻撃コードはこのレベルを起点にしてる。
次に簡単なのは、修正されていないオープンソースを調べ上げ、脆弱性を探すこと。今回のHeartBleedの発見前の悪用が、これに当たる。
その次に難しいのは、クローズドなソフトの修正パッチがリリースされた時、修正パッチをリバースエンジニアして問題点を見つける方法。これはいくらか時間がかかる。
一番難しいのは、クローズドなソフトをブラックボックスとしてテストして脆弱性を見つける方法。これは賞金が貰えるレベル。
よって、オプソでセキュリティアップデート版がリリースされたら、クローズドよりも大急ぎでアップデートしないといけないわけ。
オプソ信者は、程度の差を無視して「クローズドも同じだろ」ってしか主張できないが、程度の差は重要だよ。
おっしゃることの意味は分かっているつもりなんですが、1点だけ……。
オープンソースの場合には攻撃方法が公開されているも同然なので急がなければいけないのはその通りなのですが、クローズドソースの場合、脆弱性が発見の経緯とかアップデートされるまでに放置された期間とかが示されないことも多いので(外部の専門家から多数の報告がされた後とか、攻撃があった後とかってこともあります)、やっぱり急がなければいけないのは同じですよね。# オプソっていうとモルヒネにしか聞こえないので、この略はやめてほしい
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
ハッカーとクラッカーの違い。大してないと思います -- あるアレゲ
オープンソースの方が安全 (スコア:5, すばらしい洞察)
そんな神話は最初からなかった
Re: (スコア:0)
安全、という話じゃなくて、脆弱性が発見されたら公開される、って方じゃないっけ?
プロプラだと脆弱性を某ハッカーが見つけた場合、繰り返し悪用されるだけで、その実態をどのように公開するか?の道筋がわからん。
Re: (スコア:2, 参考になる)
> 安全、という話じゃなくて、脆弱性が発見されたら公開される、って方じゃないっけ?
いや、オプソ教信者は、皆が監視してすぐに直されるから安全と主張していた。
ところがだ、memcopyの境界チェックすっ飛ばしなんか、調べようと思えばソースを簡単にチェックできるものなのに、長期に渡って、そして広範囲で使われるようになっても、誰も気づかなかった。
いや、気付かなかったわけではなかった…。
> プロプラだと脆弱性を某ハッカーが見つけた場合、繰り返し悪用されるだけで、
> その実態をどのように公開するか?の道筋がわからん。
オープンソースなので、OpenSSL
Re: (スコア:3, 興味深い)
>ところがだ、発見者は脆弱性を公開・指摘することをせずに悪用していた
この悪用していたのは”オープンコミュニティに参加していた本人なの?”
違うでしょ。
「発見者(悪意あるハッカー)が通報せずに悪用する」リスクそのものはプロプラでも、オープンソースでも同じ。
どちらが安全か?という議論は「善意の発見者が通報した後、どういうシナリオになる(なりうるか)」で議論すべき事では?
ただ、それ以外に「ソースが公開されているからパッチが誰でも作れる=(安全係数)」だけでオープンソース優位と見るのは間違いだと私も
思います。それ以外に
「今回のように”ソースが公開されているからこそ悪用可能な不具合をみつけ悪用する人”」もいるわけで。
Re: (スコア:-1)
> この悪用していたのは?オープンコミュニティに参加していた本人なの??
> 違うでしょ。
えっと、大丈夫ですか?
オープンコミュニティに参加している本人に限定するオープンソースならば、クローズドソースのソフトウェアでも開発者数は大して変わらない。
違うでしょ?
オープンコミュニティが何を示しているのか意味不明だけど、そうじゃない関係ない人もソースコードが見れるんでしょ?
脆弱性をソースコードから見つけることができるんでしょ?
その脆弱性を開発コミュニティに指摘することなく悪用することができるでしょ?
> 「発見者(悪意あるハッカー)が通報せずに悪用
Re: (スコア:0)
ところがだ、OpenSSLはオープンソースであり、修正したらすぐ公開された。
悪意の攻撃を計画する奴は、修正個所のコードを見てすぐに攻撃コードを開発して使い始めた。
ほとんど修正版への対応が進まないうちから攻撃が大量に発生してしまった。
チェック方法まとめ:OpenSSLの「Heartbleed」脆弱性は2年前から存在、「最悪のケースを想定して対処を」と専門家 [atmarkit.co.jp]より,
>ソフトバンク・テクノロジーの辻伸弘氏によると、「既に実証コードがリリースされているため攻撃を行うハードルはとても低い」。
>「この脆弱性は、さかのぼると2年前から存在していたことが確認さ
Re:オープンソースの方が安全 (スコア:0)
> >ソフトバンク・テクノロジーの辻伸弘氏によると、「既に実証コードがリリースされているため攻撃を行うハードルはとても低い」。
> >「この脆弱性は、さかのぼると2年前から存在していたことが確認されている。
> あなたの描くシナリオとはだいぶ違っているようですね.
???
あなた、大丈夫?
2年前にはこの脆弱性が混入していて、誰でもソースコードを見て発見することができたわけ。
そして米NSAのように、いち早く発見して悪用していた勢力もあるわけ。
やっと最近になってコミュニティが問題に気付いて修正し、公開したが、その公開情報から実証コードを作った人が居るという話。
実際には実証コードが作られる前から、最悪の場合は2年前から実証コードではなく攻撃コードが使われていたわけ。
どこをみて、「シナリオとはだいぶ違っている」と思えた?
> オープンソースに限ったことじゃないよね.この2,3年で古いFlashやAdobe Reader,
> java経由のアウトブレイクがどんだけあったことか.
> #ネタにマジレス(であってほしい)
コンピュータの脆弱性やセキュリティに限らず、実社会での防犯セキュリティでも同じなのだけど、あなたみたいにセキュリティの問題に対して、できるだけ影響が小さいように解決する方法を気にしない、セキュリティに無頓着な人にはわからないかもしれないけれど、まず問題の詳細を公表する前に問題の解消を先にした方が安全なのだよ。
ATMに脆弱性が見つかり、カードを裏返しに入れると残高が100倍に増える現象が見つかったとしよう。
銀行は「残高が100倍に増えてしまうので、カードを裏返しに入れないでください」と最初に発表するだろうか?
そうではなく、この問題を直してから発表する、あるいは直したうえで発表すらしないだろう。
ソフトウェアの脆弱性を見つける難易度って言うのがある。
一番難易度が低いのは、オープンソースなソフトが修正され、修正版がリリースされた時に、修正版とのソースコードのdiffを取って見れば一発だ。
これは初球プログラマーでもできレベルで、問題公開後に作られた攻撃コードはこのレベルを起点にしてる。
次に簡単なのは、修正されていないオープンソースを調べ上げ、脆弱性を探すこと。
今回のHeartBleedの発見前の悪用が、これに当たる。
その次に難しいのは、クローズドなソフトの修正パッチがリリースされた時、修正パッチをリバースエンジニアして問題点を見つける方法。
これはいくらか時間がかかる。
一番難しいのは、クローズドなソフトをブラックボックスとしてテストして脆弱性を見つける方法。
これは賞金が貰えるレベル。
よって、オプソでセキュリティアップデート版がリリースされたら、クローズドよりも大急ぎでアップデートしないといけないわけ。
オプソ信者は、程度の差を無視して「クローズドも同じだろ」ってしか主張できないが、程度の差は重要だよ。
Re: (スコア:0)
おっしゃることの意味は分かっているつもりなんですが、1点だけ……。
よって、オプソでセキュリティアップデート版がリリースされたら、クローズドよりも大急ぎでアップデートしないといけないわけ。
オープンソースの場合には攻撃方法が公開されているも同然なので急がなければいけないのはその通りなのですが、クローズドソースの場合、脆弱性が発見の経緯とかアップデートされるまでに放置された期間とかが示されないことも多いので(外部の専門家から多数の報告がされた後とか、攻撃があった後とかってこともあります)、やっぱり急がなければいけないのは同じですよね。
# オプソっていうとモルヒネにしか聞こえないので、この略はやめてほしい