アカウント名:
パスワード:
その意味でこれって本当に脆弱性なの？
ローカルであっても他の人が書き込み可能となっているフォルダでは、 自分が作成して内容が改竄されていないファイル（ファイルに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の文化も昔から少しずつ変わってきてるし、アプリケーション側で対処出来ることもあるだろうし、あと、何よりこういうシチュエーションをどれくらいの人が認識できていたのか。
というか、こんな抽象的なことをグダグダ書いて
いわんとしている事がいまいち理解出来ないのだけれど。
うん、残念ながら元コメからの流れをご理解いただけていないようです。
DLLサーチの仕様は、ローカル(スタンドアローンでもいいや)では便利なので、WINでは旧来から使われてきた伝統なのですよ。
この元コメの流れで提議されているのは、イントラでも、管理者信頼できないネット越しでも、フォルダとして開いたら、ローカルと同程度と扱うってことが一番の問題なんだよね？ってこと。
今回の対策もDLLサーチ塞いでも気休めでしかない。だって、ローカルと同程度に扱うことをやめないんだから、作る側も使う側もローカルで可能なことは、できることが前提で
>DLLサーチの仕様は、>ローカル(スタンドアローンでもいいや)では便利なので、>WINでは旧来から使われてきた伝統違います。互換性維持の為に残されてきた悪習です。カレントディレクトリからdllが読めて便利なことなんて全くといって良いほどありません。# 実行ファイルと同じフォルダからのdll読み込みとは違いますよ?
>今回の対策もDLLサーチ塞いでも気休めでしかない。気休めではありません。根本的な対策です。
>ローカル以外をフォルダとしてつなぐときは、>サンドボックスとして扱うローカルでも人から貰った圧縮ファイルなど危険なものはいくらでもあります。local exploitは見つかり次第全て潰す必要があります。予防や対策にサンドボックスを使うというのは悪くない案です。完璧では無いですが。
>ローカル同様に扱うのは>WIN自体の仕様であり文化LinuxでもGTKならgvfs層で同様に扱われています。問題はそこではありません。Windowsがダメなところは実行ファイルのアイコンの仕様などもっと別の所にあります。酷い仕様と脆弱性とが合わさって、リスクが上がるのです。
>外部フォルダの扱い方が間違ってたんだから今回の脆弱性は外部フォルダの問題ではありません。圧縮ファイルを解凍したものや、USBメモリ、光学ディスクでも起こります。
頭に血が上っているように見えます・・・的をよく狙って一発で打ち抜くのが、いいコメントだと思います。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
あと、僕は馬鹿なことをするのは嫌いですよ (わざとやるとき以外は)。-- Larry Wall
そもそも (スコア: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)
うん、残念ながら元コメからの流れをご理解いただけていないようです。
DLLサーチの仕様は、
ローカル(スタンドアローンでもいいや)では便利なので、
WINでは旧来から使われてきた伝統なのですよ。
この元コメの流れで提議されているのは、
イントラでも、管理者信頼できないネット越しでも、
フォルダとして開いたら、ローカルと同程度と扱うってことが
一番の問題なんだよね？ってこと。
今回の対策もDLLサーチ塞いでも気休めでしかない。
だって、ローカルと同程度に扱うことをやめないんだから、
作る側も使う側も
ローカルで可能なことは、
できることが前提で
Re:そもそも (スコア:0)
>DLLサーチの仕様は、
>ローカル(スタンドアローンでもいいや)では便利なので、
>WINでは旧来から使われてきた伝統
違います。互換性維持の為に残されてきた悪習です。カレントディレクトリからdllが読めて便利なことなんて全くといって良いほどありません。
# 実行ファイルと同じフォルダからのdll読み込みとは違いますよ?
>今回の対策もDLLサーチ塞いでも気休めでしかない。
気休めではありません。根本的な対策です。
>ローカル以外をフォルダとしてつなぐときは、
>サンドボックスとして扱う
ローカルでも人から貰った圧縮ファイルなど危険なものはいくらでもあります。local exploitは見つかり次第全て潰す必要があります。
予防や対策にサンドボックスを使うというのは悪くない案です。完璧では無いですが。
>ローカル同様に扱うのは
>WIN自体の仕様であり文化
LinuxでもGTKならgvfs層で同様に扱われています。問題はそこではありません。
Windowsがダメなところは実行ファイルのアイコンの仕様などもっと別の所にあります。酷い仕様と脆弱性とが合わさって、リスクが上がるのです。
>外部フォルダの扱い方が間違ってたんだから
今回の脆弱性は外部フォルダの問題ではありません。圧縮ファイルを解凍したものや、USBメモリ、光学ディスクでも起こります。
Re: (スコア:0)
頭に血が上っているように見えます・・・
的をよく狙って一発で打ち抜くのが、いいコメントだと思います。
Re: (スコア:0)