「ワームのコードを公開するな」これって正論？ 52
臭いものに蓋をしたいだけでわ 部門より
時を同じくして複数のタレコミがあったこのネタ…
まず、Jeanreno 曰く，"CNETのこのこの記事によると、 ウィルスやワームの蔓延は、ソフトの不具合を利用して不正 侵入するための見本プログラムを公開しているセキュリティー 会社やハッカーだそうです。 そんな事言う暇があるなら自社の製品のセキュリティー ホールを埋める努力を怠るなって感じですがどうなんで すかね？"
同じことはユーザにも言えるだろう。使わない自由も選択できるのだ。もっとも、そう言い切れない事情もあるにはあるだろうが…
また、argon 曰く，"CNET にて 「MSからハッカーへ：「コードを公開するな」 という記事によると コピーペーストすれば、そのまま実行されてしまうような悪意の見本プログラム、 ソースコードを報告書で公開しないでほしいという主張の論説 「It’s Time to End Information Anarchy」が発表されたとのこと。 ソースが公開していない以上、ソースを持ってるところが対策するまでは 空爆され放題というのは当たり前ですが、この主張はもっともなのでしょうか？ 歴史的になぜ見本コードが公開されてきたのかというと、 そもそも再現コードなしでは欠陥の存在を認めない配布元に コードを公開することで確かな証拠を提示して、 修正を行わせる圧力をかけるためだったと思うのですが、 再現コードを見せることなしに対応してくれるのでしょうか？"
そして、kiyotan 曰く，"CNET Japan Tech Newsの記事によると、
マイクロソフトのセキュリティー対応センターの責任者、スコット・カルプが、
セキュリティーホールの具体的な攻撃方法を示したサイトにもワーム攻撃の責任があるという趣旨の論説を発表したそうだ。
元ネタはここ。
なかなかの名文です。
しかし、そんな世の中になったら情報が地下に潜るだけでないの？
ついでに一番困るのはMSそのものだと見た。"
だろうな。
確かに（Re:簡単に被害が出るものほど公開して欲しく (スコア:5, すばらしい洞察)
これほどまでに模倣犯、愉快犯は出なかったでしょうね。
小麦粉さえあれば誰でも愉快犯にはなれますからね。
仮に直接疑似クラックコードを公開しないという風習が根付いた時、
最大の問題はソフトメーカーがどれくらい誠実に対応してくれるか、
ですよね。
「このようなセキュリティホールがある。
これを利用するとこのような被害が考えられる」
とメーカーに報告した時、
「そのようなセキュリティホールはあるかもしれませんが、
被害はあなたの想像の域を出ませんね。」
と対応されたらやっぱ自分で実際にやっちゃうしか無いもんなぁ。
で、そんな対応するソフトメーカー相手だと
自分がクラッカー扱いされかねないだろうし、
個人だとやっぱり相手にされない可能性も高いし、
自衛策も兼ねてウェブで公開して賛同者も多少集めてから
もう一度メーカーと接触するよなぁ、自分なら。
きっと、「仕様です」を始めとするなめきった
ユーザーに対する扱いがなければもう少し世の中
違ってたんだろうなぁ．．．
Kiyotan
問題はモラルじゃないんだが (スコア:5, 興味深い)
もちろん、Microsoftがモラルを説くのは、自由です。 でも、所詮モラルですから、従わないのも、自由です。 異なるモラルを持ってる人は単に従わない。それだけです。 また、そのレベルの話であれば、それは尊重される べき意見として素直に受け止められるでしょう。 この延長として、例えば専門的な教育の場で "full disclosure っていうのは cracking tool 作りとは違うんだよ"ということを きっちり教えるカリキュラムをつくるとか、 Microsoftがそういうのに助成金を出すとか、 そういうこともまた、問題ないですね。
問題はMicrosoftが求めていることは、 そういうレベルの話ではなく、 exploit tool が公開*できない*、 そういう秩序形成をめざした動きだ、ということです。 方法は、法的規制かもしれないし、業界規制 (というか、ISPによる検閲とか)かもしれないし、 また違うかもしれないが、そういう「強制力」が ある方法でなければ、ここでのMicrosoftの主張は 「絵に書いた餅」でしかないわけです。
このような「規制」のなかで、 技術的な意味においてのfull disclosureと、 exploit codeそのものの公開、これを厳密に区別できるでしょうか？ いや、できないでしょう。 もちろん、区別できるケースはあります。 例えばbuffer overflowを起こせることの証明と、 それを利用して任意のプログラムを実行できるコードは 一応違うレベルのものなので、前者だけで十分だ、 とは言えるでしょう。 でも、例えば Nimdaがメールでの感染に利用した セキュリティホールの問題なんて、 技術のfull disclosure とexploit codeの間に ほとんど距離がないですよね。
ですから、そのような規制が強制力のあるものとして現実化した場合、 「守るのに必要な」セキュリティ情報が 場合によっては出てこなくなる可能性が高いわけです。
また、問題によっては、 「穴」を「穴」と認識するかどうかとか、 その穴が実はベンダーにとっては意図したことであったりするとか、 そういうベンダーとユーザの利益が一致しない ケースというのも、世の中にはありえるわけです。 「情報を隠す」方向のルール作りが行われると、 このようなケースでベンダー側が過剰に有利になれる、 という問題もあるわけです。
MSの理解は間違えている (スコア:5, すばらしい洞察)
新しいコンセプトを持ったワーム作者は、それなりにネットワークとプログラムに詳しい人間だろう。少なくとも MSが想定するようなレベルの低い連中ではない。 あとはワームが広がれば、その ワームを捕獲し解析するのは簡単 だし、そのコードに悪意のコードを加えるのも簡単な作業だ。Code Red亜種がいい例である。どんなに秘密を守っても、ワームの方からやってくる。探す必要もない。
MSの主張は現状を正しく分析していないし、何の解決にもなっていない。 あくまでMSお得意の もっともらしい理由をつけて 他人に責任を押し付ける プロパガンダの類にしかなりえない代物だ。
WindowsであれUNIXであれ、プラットフォームが根本的なレベルからセキュリティ強化をする方法しか対処方法はない。もしMSが本当にこの程度の現状分析しかもち得ないレベルならば、この先はさらに危うい。なぜなら 誤った問題を解いても誤った答えにしかならない からだ。
すずきひろのぶ
狼少年? (スコア:4, すばらしい洞察)
これってMSが閉じられたMLとかの世界、じゃなくてメディアを通して
一方的に自分の言いたい事を広域プロパガンダした、って事が重要なんでしょうね。
過去「急いで直すの面倒臭いからバグ見つけてもこっそり教えてくれ」と
散々主張してきたけれども誰もそんな主張は聞いてくれなかったから
会議室の外で「おーい、こいつらは犯罪者を助長してる悪い連中で
善玉のおいらの言う事聞かないから困ってるんだー」と大声を張り上げだした、
ってなイメージ。
外では自分の方が有名だから世間は味方に付いてくれるかも、なんて踏んでるんでしょう。
実際MS社のtechnet内のコンテンツなら普通のちょっとパソコン好きの人なんかも読む機会があっても
これに対する反論が投稿されるであろうフォーラムに目を通すのは一部の人だけだと思いますし。
#しかし一連のテロ騒ぎに便乗して自己の利益を追求する団体の多い事よ...凄く嫌だ
情報を公開する側のモラル (スコア:4, すばらしい洞察)
ソフトウェアのベンダー（この場合はマイクロソフト）にソフトウェアのバグ修正を求めるのであれば、世の中に不具合の概要を公開し、ベンダーにはexploitなコードを送って対応を求めれば、それで十分な圧力になると思います。ベンダーが対応しなければ、「この製品にはこんな問題があるのにベンダーは対応しようとしない」と声高に主張すればいい。
私たちの多くは具体的なexploitコードを知らなくても、セキュリティ問題に対するマイクロソフト社の対応に不満を持っていたし、クラッカーによる具体的な被害がなくてもセキュリティパッチは公開されているし、セキュリティ情報はかなり検索しやすくなったし、そんなこんなでマイクロソフト社のセキュリティ問題に対する対応は随分改善されてきた。そうでしょう？
逆に、ベンダーに概要を説明して「後は自分たちのソースを見て不具合箇所を見つけ出して直してくれ」と更なる努力を要求し、世の中にはコピー＆ペーストで利用できるコードを公開していたのでは、クラッカーを助長していると言われても仕方ないかも。
製品を買わせておいてあとは知らん振りでは許せない、というのも分かりますが、クラッカーの行為はユーザーを害するものであってexploitコードの公開はそれを助長している、というのもそれはそれで正当な論理のように感じられます。情報を公開する側にもセキュリティ問題の一端を担っているというモラル（and/or責任意識？）が必要だと思います。
ちょっと乱暴な例ですが、炭そ菌の培養方法をテレビで具体的に報道してしまうと、現状の「偽」炭そ菌情報の一部は本当の炭そ菌被害になってしまうのではないでしょうか？
余談ですが、セキュリティ情報を公開する側が今回のマイクロソフトの要請にどう対応するかは、公開する側の判断に委ねられるべきだと思います。公開する側、される側、両者がナアナアではない独立した立場を保持することは重要だと思うので。
Re:どうせなら (スコア:4, すばらしい洞察)
というような機関はソフトウェアベンダから一切の補助を受けない・けさせない必要があるでしょう． でもそんな機関を誕生させられるかしら? ボランティアベースの運営だと 現状と殆ど変わらないですから マイクロソフト社が文句を言いつづけるという構図は変わらないでしょう．
今回のテロに便乗して
- 自らの息がかかった(一見)第三者機関を擁立する
- セキュリティーホールの存在を報告すること
自体を違法とするためのプロパガンダ
あたりがねらいだと僕は見ました.Koichi
Re:情報を公開する側のモラル (スコア:4, すばらしい洞察)
Microsoft はその通達を受けてから 3 ヵ月以上放置し、Bagtraq などで騒がれてようやく重い腰を上げ、しかし、それでも最初の通達から半年以上経ってからようやくパッチを出した、という過去の経歴があった記憶があります。
Apache などであれば危険なコードを公開せずとも、それを修正する参考 patch を送りつけるなどしてやれば迅速に修正されますし、他のメーカでもこれほど放置することはなかなか考えられません。
同じソース非公開物でも、シェアウェアなどの場合には現象が確認できてから数日中には大体修正版も出ます。規模が違うのはわかっていますが。
たとえ穴を突くコードを、ソースを開示せずバイナリだけで確認できるようにしても、通信が発生するなら tcpdump などで見てしまえば無意味ですし、スクリプト系の欠陥に至っては実行されるコード自体がテキストになってしまいますので誰でも読めてしまいます。
場合によっては「こんな感じの穴がある」という情報だけでそれなりの技量がある人には大きな手掛かりとなるので、穴の存在自体を広く知らしめる事自体ができなくなり相手に握りつぶされる可能性が高くなります。
どうしても対応してくれない場合の最終手段としては、攻撃方法の開示もやむを得ないという気はしますね。
もちろん、見つけたらいきなり開示というのはさすがに問題があるとは思いますが。
もしそういった情報が (スコア:4, 興味深い)
現状、セキュリティコンサルタントによって公開されないようになると、
１．この種の情報は「地下に潜る」ため、いっそう追跡困難になる。つまりアマチュアではなく、職業クラッキングする人が仕事がやりやすくなる。情報がないので防ぎようもなくなる。
２．M$社はじめソフトウエアメーカーがセキュリティに配慮しない「怠惰」が始まる。
ということになるような気がする。
簡単に被害が出るものほど公開して欲しくない (スコア:3, 参考になる)
原爆の作り方なんて大々的に公開されていますが、
なんと言ってもウランもプルトニウムも入手できない。
その点、ソースあるいはスクリプトであれば、そのへんの小学生だって、ウィルス作れます。
非公開にしたってだめじゃん？ (スコア:3, 興味深い)
「性善説vs性悪説」まで下がっていきますよねぇ。
「ワームを作る取っ掛かりになるコードがある」
ってときに
「じゃーワーム作ってばら撒いてやろう」
と考えるような性悪クラッカーは、
コードが公開されてなくても
「オレはワーム作ってばら撒くぜぇ」
ってことになるんじゃないのか。
非公開にしたところで、
お手軽クラッカーは減るかもしれないけど、
よりタチの悪い(スキルの高い)クラッカーが増えそうですけど。
反面、お手軽なハンターも減るでしょうし。
仮にこの手のコードが非公開になったとしても、
セキュリティーツールの会社なんかでは研究を続けるわけで、
結局は地下情報になってばら撒かれることになりはしないか？
考えすぎか？
技術的にも矛盾がある (スコア:3, 参考になる)
倫理的な切り口が多いようですが、技術の点でも問題があります。
実行可能なファイルの挙動を解析できないようにするのが目的です。とならば、この世から解析が容易なインタプリタ言語や中間コードを生成する言語を撲滅しなければなりません。しかし、これは.NETのCommon Language Runtimeの目標とは反しています(CLR Engineが解釈するMSILもまた中間コード)。
MSILがどのようなものになるかははっきりしないものの、機械語よりも抽象度の高いものになるのは間違いないでしょう。ということは、MSILの挙動を解析し、ソースと等価なものを得ようという動きは必ず出ます。これが成功してしまえば、ソースが手に入ったのと同じ結果です。
以上の観点から見ると、Scott Culpのarticleは技術上のごく小さな問題しか取り扱っていません。結局は角をためて牛を殺してしまう結果にしかなりません。
そんなことが通ったら (スコア:2, すばらしい洞察)
仮に、ワームの被害が減っても、情報を盗む目的で 行われるクラックは減らないでしょう。 むしろ、セキュリティーホールが放置されることで、そういった目に 見えない被害は増えるかも。
もっとも、目に見えない被害が増えてもMSは痛くないのかもしれないが。
今更 (スコア:2, 参考になる)
蒸し返すのか、って素直な感想
以下にクライアントとの認識が食い違っているかを
再々度自ら宣言してるような物ですな。
#あ、読んでないのかひょっとして(笑)
情報公開のやり方がカギ？ (スコア:2)
しかし、実情として、完全なソフトウェアを作成することは実装される機能が多いほど難しくなるです。何らかのバグはつきものと言ってもいいかもしれないですの。となると、バージョンアップやパッチで対応することになるかと思うですが、これもまた現実には次のような問題があるように感じますです。それは、多くのユーザはパッチをあてないということですの。
仮にパッチを作ったとして、ユーザが対応しなければ結局クラックされてしまうことになって、最終的には話題にのぼってしまうことになるですの。さらに、パッチを作成するのには多少なりとも時間がかかってしまうですから、そもそもパッチが完成するまでの間は、ソフトウェアは攻撃の脅威に曝されることになるかと思うです。
そこで、次のアプローチはどうかと考えるです。曰く、クラッカーを減らすこと。
もともと、こういったセキュリティやソフトウェアそのものの情報は、割と高度なもので、ものによってはアンダーグラウンドのものになるかと思うですが、少なくともある程度の知識や経験が必要とされるのではないかと思うです。
しかし、情報がいきなり公開されることによって、いわゆる初心者クラッカーとでも呼ぶ人たちが、たいした知識などもなくウィルスやワームを作成するなどして、クラック行為をすることが可能になってしまうですの。そうなると、パッチ作成までの時間稼ぎも難しくなるし、そもそもパッチをあてないユーザも多い状況では、新たな被害が増えることも懸念されるです。
だからといって、情報が公開されないとなると、セキュリティホールを埋めることはおろか、ソフトウェアの改善や新しい機能の実装という面に関しても影響がでてしまうとも限らないですの。
決してクラッカーはいなくならないと考えると、表向きに情報を非公開としたとしても闇で流通してしまうです。なれば、非公開もナンセンスかと思うですの。
ソフトウェアを作成し、提供している側には、もちろんよりセキュアなコードでソフトウェアを作成することが求められるとともに、パッチを迅速に提供すべきと思うです。しかし、パッチすらあてないユーザも多い、また初心者クラッカーもいるだろうというところで、攻撃部分のコードをいきなり公開しないようにする、という行動はひとまずの効果があるかとは思うです。
ただし、だからといって、人の口に戸はたてられず。こういった攻撃コードなどの情報も例外なく地下では流通するのでしょうし、脆弱部分があるということは攻撃され得るということですの。最終的にはよりセキュアなコードで作成してもらうのはともかくとして、ユーザ側も対応を怠りないようにするしかないかとは思うです。
情報を一切公開しないというのではなくて、情報公開の手順、やり方次第で何か上手い方法が見つかりそうかなあと思うですの。
-------- SORAMINE Yukino
Re:予防法 (スコア:2, 参考になる)
＃この情報自体はクラッキングの危険性とは少し趣を異にするものですが、たまたま手元にURIがあったので。
こういうハウツーをあわせて提供できなければ、セキュリティの穴だけを指摘してもユーザーにとっては利益より危険の方がより増すことになるのではないでしょうか。ソース公開という圧力のかけ方は、ベンダーにパッチを作らせることを重要視するあまり、ユーザーの安全を確保するという視点を欠いているように思えてなりません。
…というのが、ワタシの言いたいことの骨子なのだとさっき気づきましたので補足しておきます。
両刃の剣 (スコア:2, すばらしい洞察)
こーんな問題があるからセキュリティパッチ
あてなきゃダメなんですよ
っつって重要性を説いた上で継続的にWindowsを使わせるか
こーんな問題があるからWindows使っちゃダメなんですよ
って他ＯＳに乗り換えさせるか
どっちにも使えそう :-P
後者のアクションを起こすシステム屋が多そうだとの判断から、
Ｍ＄としては公開を停止させたいのでは？
# 実際にＭ＄がそう考えたかどうかは知らんがね
WindowsだろうがUNIX(Linux)だろうが穴が見つかったら
パッチあててかなきゃいけないのは一緒なんだけど...
Re:僭越ながら追加させていただきます (スコア:2)
パッチが複雑怪奇にリリースされてるので、何に効果の有る何を適用しているのか訳わからん状態の場合もあるでしょうし、MSからの情報だけでは信頼できないって事もありますし...。
その意味では、やっぱりMicrosoftは「ユーザーに信頼される」とはどういう事なのか、もう一度考え直してから、今回のような発言をするべきだなあ。
Re:予防法 (スコア:2)
ソースを持たないで修正できますか？
問題点があることを指摘されて、誰もがすぐに理解できますか？
問題点を具体的に説明するにはどんな方法がありますか？
問題が解決したこと、未解決であることを確かめるにはどういう方法がありますか？
第三者が自分のところで問題があるかどうかを確かめるにはどういう方法がありますか？
「ユーザーの安全を確保するという視点」から上記の点を考えてもらえれば、
「誰もが問題点を再現検証できるようにして、その製品の使用中止を勧告する」
がもっとも有効な対策だと思いますがいかがですか？
Re:予防法 (スコア:2)
は？どこが横暴なんですか？
それを言ったら、鍵を掛けずに外出している間に泥棒に入られた人に「鍵を掛けないからだ」と言うのは乱暴ですか？それとも泥棒に入るやつが世間にいるのが悪いのでしょうか？
＞個人の財産権がかかっているという点では同じ
だから、結局は自分で自分の財産を守るしかありません。
Re:予防法 (スコア:2)
自分の財産は自分で護るのが普通ではないですか？
お忘れかもしれませんが、「いちユーザーのワタシ」の問題を「ユーザーの自己責任に転嫁するという姿勢」なのは、
マイクロソフトさんの方針の方です。「ベンダーの信用」は、始めから問題にしていないみたいですよ。
「ウイルス/ワーム対策はいたちごっこ。セキュリティ・ホールが皆無の製品を提供するのは，残念だが難しい。
このことを念頭において，利用者全員が常にウイルス情報にアンテナを張って欲しい」
Re:予防法 (スコア:2)
勧告されようがされまいが、自分の責任において使用すればよろしいのでは？
仕事ならそれを指示する人の責任でしょう。
もちろん二次感染の踏み台や温床になった場合の責任も引き受ける覚悟で。
知らなかったからといって攻撃の対象から外してもらえるわけではないので、
弁解の理由にならないというのが昨今の常識だと思っていますが。
というか、誰かに弁解するつもりですか。
「勧告を速やかに知ることができる環境にいられるわけではない」でしょうが、
いないなら直接的な攻撃を受けることも少ないでしょうから、多少は時間的余裕があるでしょう。
いつでも攻撃をうけられるような環境にいながら未対策ならば、
自業自得と言われてもしかたないのではないですか。
そんな勧告があったとして、その OS を使って得る利益が被る損失を上回るなら
使うのも自分の判断でしょう。勧告は命令でも法律でもないですから。
Firewall の中で Virus Checker を常駐するというのは広く試みられている
対策のひとつですが、そういうコストを受忍できるぐらいのメリットがあると
考えられているわけでしょう。
だんだん HAMみたいな「ネットワーク機器運転免許」が必要な気がしてきた :-)
これが妥当な仮定かどうかが焦点のひとつですね。
Copy & Paste しただけで Worm として動くようなものを配布しているのでない限り、
Worm 作成者にはそれなりの技量が要求されますよね。そういう技量を持っている人には、
参考コードがついていようがいまいが同じじゃないですか。
対策の役に立つ効用の方が遥かに大きいと考えます。
「COCOMに違反して部品を輸出して、ソ連の潜水艦の音が小さくなった」といじめられた
東芝のことを思い出しました。本当に東芝の部品を使っていたんでしょうかね。
潜水艦の音が小さくなったというのも、美国がそう主張してるだけだったのですが、
現実に東芝は経営に打撃を受けましたね。
Re:予防法 (スコア:2)
ですよね。
「できればやってます」で通じないなら「できるなら、やってごらん」の方が効果的かな？
おそらくは「自分にはできない」というないものねだりでしょうけど、
このストーリーのコメントを参考に順に考えていけば、
隠していいことはないだろうという結論になるのを期待しておきます。
Re:予防法 (スコア:2)
乱暴かどうかはどうでもいいですが、譬え話はいくらでも都合よくつくれますので、
議論には使わない方がいいですよ。鍵の話を私の主張を補強するように用いることもできます。
----
今日では事務所や住宅の錠前は、とある窓屋によるものが使われている場合が多い。
これはその窓屋が販売している窓が人気があり、窓を購入するとその錠前がついているからだ。
だが、この錠前はかなり脆弱だった。
いくらかでも錠前に関心のあるものは、この窓屋の商品に問題点が多いと知っている。
問題点は次々に見つかるというのに、指摘されてもその窓屋は認めようとしない。
具体的に指摘すると、問題の存在を話すからいけないというのにはあきれるほかない。
その窓屋は自分の錠前が安全だと繰り返し主張しており、
多くの人がその宣伝を鵜呑みにして確かめもせずそのまま使っているのが現状である。
だが、そうしている間にも問題のある錠前を堂々と開けて事務所や住宅に侵入して悪さをする訪問者がいる。
ときには、1分に100回以上の訪問者がくることもある。
訪問者の中には、我が家を新しい住まいとして、他所へ出稼ぎに行こうと企んでいるものもいるらしい。
私の錠前はもっと安全なものだが、残念ながら隣人の問題だらけの錠前は開いたままのようだ。
隣人の窓から来た訪問者がしつこくノックするのを聞いて悲しい思いをした。
時折、その窓屋は改良しましたという案内とともに、接ぎ当てを配布する。
その接ぎ当てを使って安心している人も多いが、問題点が放置されたままのことも多い。
接ぎ当てが配布されていることすら知らないで寝ている人もいるようだ。
自分の錠前が役に立っているかどうかは、その錠前を使っている自分が確認しないといけないのだ。
錠前が安全かどうか確認するために、錠前の試験方法を調べている人たちがいる。
問題点が見つかると、その錠前を使っている大勢のひとに知らせるべく発表するのだが
傍目で見て錠前の抉じ開け方を調べていると勘違いする人がいて迷惑しているそうだ。
私は自分の錠前が安全かどうかを調べるために、試験方法が提供されることに感謝している。
この窓を使わなければ、どれだけゆっくり眠れるだろうと考える。
この窓はどこをどう直したら安全になるのか見当もつかないので、危険を回避するに廃棄するしかない。
それではこの窓の代わりになるものはないだろうか。
どうやら、この窓の代わりになるものの設計図を配っている人たちがいるらしい。
この窓にはいろいろな飾り物がつけられるので、使えないと家族は不平をいうかもしれないが、
他のものを使う方が結果として家族のためになるのだと説得してみようと思った。
まずは、自分の部屋の窓を取り替えた。
Re:予防法 (スコア:2)
部品じゃなくて、ＮＣ加工機です。
それでスクリューを作ってたのです。
Re:予防法 (スコア:2)
部品そのものじゃないとすると、もっと気の毒な気がします。
内通者から情報をとったんでしょうかねえ。
Re:予防法 (スコア:2)
＃NCでないと絶対に加工不可能な形状だったらしいです。
更にそのNCのメーカーまで特定できるんだそうです。NCに使われる刃物の形状の差で加工表面が違うので、それで判るらしいのですが．．．．音だけでそこまで解析可能ってのが？？ですねぇ。
Re:そんなことが通ったら (スコア:1, 参考になる)
MSは顧客の損害に大して全責任を負いませんから痛くも痒くもないですね。
んで、最近のホットトピックス（藁
http://www.microsoft.com/japan/technet/security/prekb.asp?sec_cd=MS01-051
見ても、「問題を緩和する要素 :」などと書いてしきりに言い逃れしようとしてるんだよね。実際にどのような被害が起こりうるのか、具体的な危険性を書くべきなのに。
こんな態度の企業の何を信頼せよと言うんだろう。具体的なコードを公開しないで迅速に修正が公開される保証など何処にも無いというのに。
でも (スコア:1)
正しく使えば穴が防げるし、間違った使い方をすれば害を与えるし、そういった意味では銃刀等と似てますよね。
ただその為には利用者だけじゃなく銃刀等と同様に販売(開発)側も何らかの責任を担うのが当然で、問題の主たる原因が見えていても放置している MS がそれだけしか言わないなら益々呆れられて馬鹿にされるだけだろうに。
必要なコスト (スコア:1)
大事にならないと対処しないというのは、古今東西どこの世界にもあるわけで。
ベンダーだけではなくエンドユーザーもね。
CodeRedにせよNimdaにせよ、大事になってるからパッチを当てた、という人は多いはずです。
セキュリティホールを調査研究する方は公開して危険性を知らせる。
セキュリティホールを公開されたベンダーは、それをふさぐパッチを全力で開発する。
グローバルにセキュリティの意識（およびコスト意識）を保ちつづけるためには、ある種の緊張関係が常に必要な気がします。
意識を保つためには「被害すらも必要悪」というのは極論かもしれませんが。
正論かもしれんが・・・・・ (スコア:1)
どうしようもないよなぁ。
CodeRed にしろ、Nimda にしろ、それなりに手の込んだものは、簡単には模倣できないのは普通だ
と思ふ。
そして「攻殻」の世界へ (スコア:1)
実に簡単に敵コンピュータにウィルスを送り込んだり、
敵コンピュータをクラックして情報を盗み出したり、
敵コンピュータに接続されてる電子機器を操ったり、
という奴。
できるわけねぇだろ、と思っていたが、今後MSの独占とセキュリティホールの放置が続けばあるいは可能かもな。
どこに行っても同じOS、立ち上がってる無用のサーバ、そして放置されっぱなしの簡単に見つかるセキュリティホール。
ちょっとした技術者なら攻撃できるんだけど、一般人は攻撃できないからそんなセキュリティホールがあるなんてことすら知らない
(そもそもセキュリティなんて興味ない。当たり前に守られてると思ってる)。
意外といいところをついてたんだな。
＃ウィルスの攻撃でディスプレイが爆発することはないだろうが(笑
# mishimaは本田透先生を熱烈に応援しています
Re:狼少年? (スコア:1)
というわけで、たぶんMSの金科玉条の1つとして、
有名な「相手の正体が見えない状態での主張は、無視する！」
ってのが有るんじゃないかな(笑)
誰がどう言い放った情報であろうがそれは問題じゃなく、
問題はいつでもその「内容」であろうに…。
#つーわけで、アノカワだというだけでいじめるのは、あかんよ(笑)
相手に正体が掴まれるってのが、時として何らかの意味で
相手の支配下に入ることを意味したり、するのでねえ。
しばしば困るよね。
まずは信頼を培うことでは (スコア:1)
信頼されるよう努力することはexploitコードの公開の 有無にかかわらず出来る事だけど、公開を止めてから 「やっぱり信頼するに足りませんでした」ってわけには いかないんですし。
現状、exploitコードの公開は止められていないけど、 決して十分早いタイミングでセキュリティパッチが出ているとは言えませんし。特に日本語パッチは。
そういった状況で公開によって圧力をかける事を否定するのはちょっと怖いですね。
まぁ、開発側との信頼関係がないソフトウェアを使いつづけている（使いつづけざるを得ない）と言うのも、 双方にとって不幸だな...とは思いますが。
ライセンス (スコア:1, おもしろおかしい)
まぁ (スコア:1)
#クラッキングの絶対数は減りそうですが、悪質なのは増えそう…
基本的に、悪質なコードを発表しないで各ベンダーが迅速に穴をふさいでくれればいいんですけど。
最近話題になったMS01-051のパッチでも、あいかわらずハイビットシェルコードが入ってるとイントラネット扱いらしいし…。
ちゃんと対応してくれんと、こういった意見を言っても穿った回答しかできんよ。
基本的には、コードの発表は駄目よんってーのは賛成できるんですが、ベンダー側の迅速かつ適当な対応があるってのが条件かな。
Re:情報を公開する側のモラル (スコア:1)
＃もちろん、セキュリティ情報を公開してくださっている多くの人がそういうつもりではないことは重々承知しております。しかしクラッカーにとっては好奇心を刺激されるというか、そんな感じなのではないかと（勝手に）想像しますが…
最近、ウイルスやセキュリティーホールに関するテレビやニュースサイトの報道に対してWeb上でツッコミが入っているのをよく見かけますが、ツッコミの内容はおおよそ
- セキュリティーホールの説明が間違っている、あるいは不十分
- 防御策についての情報がなく徒に不安をあおっている
の2タイプに大別できるような気がしています。ならば、一次情報源となるヒトやそれを広めるヒトには、少なくとも防御策についての情報をあわせて公開するようにしてほしい。そうしないと、ワタシのようなただのユーザーにはセキュリティホールの塞ぎようがなくただ危険に身を晒してベンダーのパッチ公開を待つだけになってしまいます。元記事のカルプ氏の論説にあった例えを借りれば、頭痛のタネになるかぜウイルスの公開だけではなくアスピリンや効果的な予防法（うがい、とか？（笑））も公開してほしい。ということです。
予防法 (スコア:1)
ＭＳ製品などは、特にね。
で、代替手段の提案をしたところで、即効性のあるものでなく、100%代替できるものでもないことが大半で
すしね。
結局、バグフィックスを促すように、製作者になんらかの圧力をかけることしか、できないでしょう。
ソースが公開されていれば、別ですけど。
Re:そんなことが通ったら(補足） (スコア:1)
「く」が要るのでは？
僭越ながら追加させていただきます (スコア:1, すばらしい洞察)
今回のMS01-051の件でも、類似の脆弱性が即座に発見されました。 各ユーザで検証できなくなると、このような手抜きパッチに対して盲目的に信頼すること以外の選択肢が失われます。
まあ、そのほうがM$にはありがたいんでしょーけど。
「ワームのコードを公開するな」 に対して (スコア:1)
といいたいです。
コードの公開によって、対策をする側は、パッチの確認ができます。
パッチを充てても抜けがあったり、バージョン確認があてにならないポカが毎度のようにある限り、安全を守る側は確認できる環境が必要です。
＃nimdaのコードを公開してくれた方、有難うございました。
＃早急な防御のチェック、未対応が発覚、早急なデータ更新と、無事に乗り切れました。
By シャム
そして「パトレイバー」の世界へ (スコア:1)
Bill GatesがE.hobaに見えるんですが、目の錯覚ですよね。
Re:予防法 (スコア:1)
たしかBagtraqなどでは、
ベンダー側に通告してから1週間ぐらいたってから、
その手のコードを公開するのが通例になっているはずです。
その場合、対応すべきは明らかにベンダー側でしょう。
また、かつてのJavaVMの問題みたいに、
分かる範囲内での対処方も出されることも、少なくないです。
しかしながら、コードが分からない以上、
弱点を発見した側の対応には限界があるのです。
Re:予防法 (スコア:1)
使用中止を勧告されても使用中止できない人はどうなりますか？「OSに穴があるからそのOSを使わないように」と勧告されても、とっさに他のOSを使える人はいいですがそうじゃない人はexploitコードの公開によってPCを使えなくなってしまいますよね。それにそのOSのユーザー全員がその勧告を速やかに知ることができる環境にいられるわけではないですよね。
exploitコードを公開しておいて、それを流用したクラックが発生した場合に被害者に対して「我々の勧告に従わなかったからだ」と言うのは、ピッキングの方法を公開して鍵の交換を促し、鍵を交換せずに泥棒の被害を受けた人に「鍵を交換しなかったからだ」と言うのと同じくらい横暴だと思うのですが。それともピッキング被害に遭うような鍵を作った業者が悪いのでしょうか？
＃ 乱暴な喩えだというツッコミは却下。どっちも個人の財産権がかかっているという点では同じです。
高木浩光氏他の論文、クロスサイトスクリプティング攻撃に対する電子商取引サイトの脆弱さの実態とその対策のように、脆弱性とそれによってもたらされる危険を明らかにし、開発者とユーザーの両方を啓蒙するやり方はあるはずです。脆弱性とそれを突くコードだけを公開してあとは（情報収集のコストも含めて）ベンダーの信用問題とユーザーの自己責任に転嫁するという姿勢は、いちユーザーのワタシとしては身勝手に感じられてなりません。
Re:情報を公開する側のモラル (スコア:1)
残念ながらそれは事実誤認のようです。
誤解を招きそうなタイトル (スコア:0)
「ワームに流用されそうなコードを公開するな」のような…
って投稿しようとしたらタイトル変わってる?
ん? 変わってない?
どうせなら (スコア:0)
勧告を出した場合24時間以内に対応せよという規則があれば
少しはよくなるのかもしれない…
MSには求めても無駄かもしれないが
Re:情報を公開する側のモラル (スコア:0)
まあ、それができりゃいいとは思うけど、そんなもん、初めからわかってりゃ公開してるでしょうよ。
その穴をどうやって塞ぐかは多くはその製品の開発元じゃなきゃわかんないんじゃないの？ソース非公開の製品ならなおさら。
Re:予防法 (スコア:0)
だから、出来ればやってるっつってんだろ。
Re:両刃の剣 (スコア:0)
単にやってみせるつもりがダウンしちまって修復におおわらわと。
まさに諸刃の剣。
Re:予防法 (スコア:0)
ふざけるな！ いや、もとい、ふざけないで下さい。何様のおつもりでいらっしゃいますか？
>脆弱性とそれによってもたらされる危険を明らかにし
しつけぇぞ！！ もとい、しつこくていらっしゃる。
いろんな例を出してこられなくても、それができればやってますと言っているではありませんか。それも何度も。