アカウント名:
パスワード:
その意味でこれって本当に脆弱性なの?
ローカルであっても他の人が書き込み可能となっているフォルダでは、 自分が作成して内容が改竄されていないファイル(ファイルにACLを設定しても)であっても フォルダに偽のDLLを置かれると被害を受けるんじゃないでしょうか。
ローカルであっても他の人が書き込み可能となっているフォルダ
仕様を悪用する同僚に罠張られるのが脆弱性?権限のない外部からってなら脆弱性だけど。。。
しかもそのDLLがアンチウイルスすり抜ける前提だよね?最低環境でもMSのDefenderやEssentialを。
わかりやすい例えをするならAutorun.infの仕様は脆弱性というのか?ってことと同レベルの論議ってことでよろ。
ターゲット型攻撃ならアンチウィルスソフトの迂回は基本的に容易です。autorunは無効化するだけで良いので容易に防げますが、dll hijackingは互換性との兼ね合いから対策が難しいかと。
更にdll hijackingだとインターネットに繋げるソフトウェアのdllを乗っ取ることで外向きのファイアーウォールを迂回できます。更に、偽のファイル共有サーバーを立てることでフォルダの表示からdllを隠しファイル以上に隠すことができます (dllに直接アクセスがあった時だけ内容を返すことが可能)。攻撃方法としては例えば、他の脆弱性(ネットワーク内のセキュリティ的に一番弱いPCが狙われる)で特定組織のファイル共有サーバーに感染させ、この脆弱性で容易に特定組織内へ感染拡大させることができます。
んー元米の流れからずれているので、あっている部分だけ確認。
autorunは無効化するだけで良いので容易に防げますが、dll hijackingは互換性との兼ね合いから対策が難しいかと。
対策ってのは「脆弱性」に対してって意味で使っていて、autorunも「脆弱性」ってことかな?
この元コメの流れは、今回の件はautorunのような「仕様の範疇」じゃないかな?ってことなんだ。
仕様の悪用方法は、そりゃ探せばいくらでもあるよね?
今回の件は「仕様」ではなく、絶
あなたにはこのコメントを進呈したい。 http://srad.jp/security/comments.pl?sid=504147&cid=1808212 [srad.jp] 曰く「セキュリティホールとは欠陥であり脆弱性とは仕様上の欠点です。」「平文で通信されるプロトコルはすべて脆弱であるといえますがいずれもそれ自体がセキュリティホールというわけではありません。」#「仕様上の」とありますが、使用上ではない欠点は欠陥という意味合いでしょう
加えて、欠点をもつ仕様、つまり脆弱性は多くの仕様にありますが、そのレベルは様々です。それを正しく認識し、場面に合わせて適切に使用している限りはセキュリティーホール
んーLINUXと比べてどうこうって主張だから、合ってるのにちょこっとずれた話になってるのかな?
今回の件はWINDOWS仕様なので、LINUXの仕様前提でってのはなしにしよう。(個人的にもCUI・GUI両方LINUX使ってるんで言いたいことはわかります)
ようはね、WebDavにしろ、Autrun.infのことにしろ、ローカルと同等の領域として扱っているから、WINの仕様として、やばいものも実行できちゃってるわけですよ。
flashファイル開いたらウィルスに感染させるとが出来るなら
なので、ここだけはNG。ローカルにflash保存しての話限定であれば、この話とかみ合うけど、普通はネット越しのローカル扱いされない領域での
いわんとしている事がいまいち理解出来ないのだけれど。対処方法は何も一つに限った事ではないでしょう。OS側、アプリケーションの開発側、ユーザー側、それぞれがそれぞれに色々なポリシー持ってて、色々考えてる訳だけれど、それらに不整合や考えの及ばなかった所があると思うわけ。そして、それぞれの立場での対処方法もあると思う。Windowsの文化も昔から少しずつ変わってきてるし、アプリケーション側で対処出来ることもあるだろうし、あと、何よりこういうシチュエーションをどれくらいの人が認識できていたのか。
というか、こんな抽象的なことをグダグダ書いて
一度反映されたコメントが数時間後になぜか消えていたので、ちょいと端折りつつ再書き込み。何が悪くて消えれたのかな?
いわんとしている事がいまいち理解出来ないのだけれど。
今回の件は、ローカルなら便利なWINの仕様だけれども、使い方を間違えて、信頼できない外部をローカル同等としてマウントしているだけだから、そういう使い方の間違いを仕様の欠陥とは言わないんじゃないかな。といわんとしております。
信頼できない外部をマウントしないように、リテラシィかポリシィできっちりやるか、それとも別な方法で安全にマウントするか、今回の件の議論はこの二つであるべきってのが元コメからの流れ。
別な方法として話もっていくなら、例えば外部をマウントする際は、サンドボックスみたいにするようにしできたらとか、そういう方向の解決策を模索する。
でないと、「間違った使い方を悪用する手法が実証できた」てのが続々とでてきそうじゃない。
その上、今回みたいに、ローカルの仕様巻き込んで修正されちゃうから、ローカルでまっとうに使っていた人や、信頼できる所をまっとうに使っていた人まで、とばっちり受けちゃうでしょ。間違った使い方をする人のせいで。
だから根本的な問題をちゃんと見ようってだけ。ただし、今回はWIN限定だから、LINUX的に見ていろいろダメすぎってのはなしでってことです。
WINの文化的仕様を理解しかねるって意味なら、生温かく見守っていてくださいませ。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
にわかな奴ほど語りたがる -- あるハッカー
そもそも (スコア:0)
ダブルクリックで開くこと自体に
リテラシの問題があるんじゃないのかなぁ。
そうさせないためのポリシィ設定してない環境とか。
信頼済みネットワーク内で刺されたらご愁傷様ってことで。
そうでないと、Side By Side以前の通例がネックになるんじゃない?
DLLバージョン依存アプリはEXEとともに
動作確認済みバージョンのDLL置いておくケースは珍しくなかったしさ。
それを無視してMSに対策しましたとかされても
弊害でまくりな気がするんだけど。。。だいじょうぶなん?
Re: (スコア:0)
ユーザーがダブルクリックしたとは限らないんじゃないですかねえ。
Re: (スコア:0)
アプリがユーザーの把握してない外部フォルダ開いたらってこと?
しかもWEBDAV/SMB/SSHFS/etc...で。
それってそのアプリの仕様自体どうなのよ?
ユーザーが指定した外部を
WEBDAV/SMB/SSHFS/etc...でつなぐなら、
ユーザーがそこは安全かもって許容してるわけだよね?
そこにウイルス仕込まれてってことなら、
DLLだろうがファイル自体だろうが食らうでしょ。
DLLロード前提の仕様なんだから、
接続先を把握・許容が必要なんじゃない?
どこにどんな方法でつながれるかわからないアプリって時点で、
お話にならないと思うんだが。。。
アプリ
Re: (スコア:0)
ローカルであっても他の人が書き込み可能となっているフォルダでは、
自分が作成して内容が改竄されていないファイル(ファイルにACLを設定しても)であっても
フォルダに偽のDLLを置かれると被害を受けるんじゃないでしょうか。
Re: (スコア:0)
仕様を悪用する同僚に罠張られるのが脆弱性?
権限のない外部からってなら脆弱性だけど。。。
しかもそのDLLがアンチウイルスすり抜ける前提だよね?
最低環境でもMSのDefenderやEssentialを。
わかりやすい例えをするなら
Autorun.infの仕様は脆弱性というのか?
ってことと同レベルの論議ってことでよろ。
Re: (スコア:0)
ターゲット型攻撃ならアンチウィルスソフトの迂回は基本的に容易です。
autorunは無効化するだけで良いので容易に防げますが、dll hijackingは互換性との兼ね合いから対策が難しいかと。
更にdll hijackingだとインターネットに繋げるソフトウェアのdllを乗っ取ることで外向きのファイアーウォールを迂回できます。更に、偽のファイル共有サーバーを立てることでフォルダの表示からdllを隠しファイル以上に隠すことができます (dllに直接アクセスがあった時だけ内容を返すことが可能)。
攻撃方法としては例えば、他の脆弱性(ネットワーク内のセキュリティ的に一番弱いPCが狙われる)で特定組織のファイル共有サーバーに感染させ、この脆弱性で容易に特定組織内へ感染拡大させることができます。
Re: (スコア:0)
んー元米の流れからずれているので、
あっている部分だけ確認。
対策ってのは「脆弱性」に対してって意味で使っていて、
autorunも「脆弱性」ってことかな?
この元コメの流れは、
今回の件はautorunのような
「仕様の範疇」じゃないかな?
ってことなんだ。
仕様の悪用方法は、
そりゃ探せばいくらでもあるよね?
今回の件は「仕様」ではなく、
絶
Re: (スコア:-1, オフトピック)
あなたにはこのコメントを進呈したい。
http://srad.jp/security/comments.pl?sid=504147&cid=1808212 [srad.jp]
曰く「セキュリティホールとは欠陥であり脆弱性とは仕様上の欠点です。」「平文で通信されるプロトコルはすべて脆弱であるといえますがいずれもそれ自体がセキュリティホールというわけではありません。」
#「仕様上の」とありますが、使用上ではない欠点は欠陥という意味合いでしょう
加えて、欠点をもつ仕様、つまり脆弱性は多くの仕様にありますが、そのレベルは様々です。それを正しく認識し、場面に合わせて適切に使用している限りはセキュリティーホール
Re: (スコア:1, すばらしい洞察)
んーLINUXと比べてどうこうって主張だから、
合ってるのにちょこっとずれた話になってるのかな?
今回の件はWINDOWS仕様なので、
LINUXの仕様前提でってのはなしにしよう。
(個人的にもCUI・GUI両方LINUX使ってるんで言いたいことはわかります)
ようはね、WebDavにしろ、Autrun.infのことにしろ、
ローカルと同等の領域として扱っているから、
WINの仕様として、
やばいものも実行できちゃってるわけですよ。
なので、ここだけはNG。
ローカルにflash保存しての話限定であれば、この話とかみ合うけど、
普通はネット越しのローカル扱いされない領域での
Re: (スコア:0)
いわんとしている事がいまいち理解出来ないのだけれど。
対処方法は何も一つに限った事ではないでしょう。
OS側、アプリケーションの開発側、ユーザー側、それぞれがそれぞれに色々なポリシー持ってて、色々考えてる訳だけれど、それらに不整合や考えの及ばなかった所があると思うわけ。
そして、それぞれの立場での対処方法もあると思う。
Windowsの文化も昔から少しずつ変わってきてるし、アプリケーション側で対処出来ることもあるだろうし、あと、何よりこういうシチュエーションをどれくらいの人が認識できていたのか。
というか、こんな抽象的なことをグダグダ書いて
Re:そもそも (スコア:0)
一度反映されたコメントが数時間後になぜか消えていたので、
ちょいと端折りつつ再書き込み。
何が悪くて消えれたのかな?
今回の件は、
ローカルなら便利なWINの仕様だけれども、
使い方を間違えて、信頼できない外部を
ローカル同等としてマウントしているだけだから、
そういう使い方の間違いを仕様の欠陥とは言わないんじゃないかな。
といわんとしております。
信頼できない外部をマウントしないように、
リテラシィかポリシィできっちりやるか、
それとも別な方法で安全にマウントするか、
今回の件の議論はこの二つであるべきってのが元コメからの流れ。
別な方法として話もっていくなら、
例えば外部をマウントする際は、
サンドボックスみたいにするようにしできたらとか、
そういう方向の解決策を模索する。
でないと、
「間違った使い方を悪用する手法が実証できた」
てのが続々とでてきそうじゃない。
その上、今回みたいに、
ローカルの仕様巻き込んで修正されちゃうから、
ローカルでまっとうに使っていた人や、
信頼できる所をまっとうに使っていた人まで、
とばっちり受けちゃうでしょ。
間違った使い方をする人のせいで。
だから根本的な問題をちゃんと見ようってだけ。
ただし、今回はWIN限定だから、
LINUX的に見ていろいろダメすぎってのはなしでってことです。
WINの文化的仕様を理解しかねるって意味なら、
生温かく見守っていてくださいませ。
Re: (スコア:0)
一部のコメントが表示されなくなる/.の
バグ仕様です。