アカウント名:
パスワード:
その意味でこれって本当に脆弱性なの?
ローカルであっても他の人が書き込み可能となっているフォルダでは、 自分が作成して内容が改竄されていないファイル(ファイルにACLを設定しても)であっても フォルダに偽のDLLを置かれると被害を受けるんじゃないでしょうか。
ローカルであっても他の人が書き込み可能となっているフォルダ
仕様を悪用する同僚に罠張られるのが脆弱性?権限のない外部からってなら脆弱性だけど。。。
しかもそのDLLがアンチウイルスすり抜ける前提だよね?最低環境でもMSのDefenderやEssentialを。
わかりやすい例えをするならAutorun.infの仕様は脆弱性というのか?ってことと同レベルの論議ってことでよろ。
ターゲット型攻撃ならアンチウィルスソフトの迂回は基本的に容易です。autorunは無効化するだけで良いので容易に防げますが、dll hijackingは互換性との兼ね合いから対策が難しいかと。
更にdll hijackingだとインターネットに繋げるソフトウェアのdllを乗っ取ることで外向きのファイアーウォールを迂回できます。更に、偽のファイル共有サーバーを立てることでフォルダの表示からdllを隠しファイル以上に隠すことができます (dllに直接アクセスがあった時だけ内容を返すことが可能)。攻撃方法としては例えば、他の脆弱性(ネットワーク内のセキュリティ的に一番弱いPCが狙われる)で特定組織のファイル共有サーバーに感染させ、この脆弱性で容易に特定組織内へ感染拡大させることができます。
んー元米の流れからずれているので、あっている部分だけ確認。
autorunは無効化するだけで良いので容易に防げますが、dll hijackingは互換性との兼ね合いから対策が難しいかと。
対策ってのは「脆弱性」に対してって意味で使っていて、autorunも「脆弱性」ってことかな?
この元コメの流れは、今回の件はautorunのような「仕様の範疇」じゃないかな?ってことなんだ。
仕様の悪用方法は、そりゃ探せばいくらでもあるよね?
今回の件は「仕様」ではなく、絶
>「仕様の範疇」この仕様(Design=設計)が何を指しているか分かりません。ファイル共有へのアクセスが透過的なのはWindowsの仕様です。今回の問題は酷いWindowsのDLL読み込みの仕様に対して対策をしていなかった多くのアプリケーションが脆弱だという話です。この脆弱性は設計から来るものではなく、アプリケーションの局所的な問題から来るものです。約48%のSMBサーバーがマルウェアに感染しています [net-security.org]。この脆弱性は組織内アウトブレーク [nikkeibp.co.jp]を引き起こす可能性のある致命的なものです。
今回の件はアプリケーション側での解決法がありますが、それが無い場合はシステム側の仕様の脆弱性です。AutoRunについては酷い仕様ですが、Microsoftは脆弱性では無いと言っていますね。AutoRunからのウィルス感染は多いのですが、あの悪名高いそれは仕様です [hatena.ne.jp]ということでしょう。そもそもWindows自体がぜいじゃk(ryまぁUSBメモリ型でキーボードコマンドを送り込むハードウェアのようにOSに依存しない攻撃法もあるので、ソフトウェアでは防げない問題もあります。結局はリスク管理の問題ですが、防げることは防ぐべきです。
>仕様の悪用方法は、>そりゃ探せばいくらでもあるよね?Officeのマクロ付きファイルでは警告がでるようになりました。ダウンロードしたプログラムを起動すると警告が出るようになりました。仕様か否かに関わらず脆弱性は毎日発見されては対策されています。
>”突破されたら”なんでもありなんでもありじゃないです。仕様の隙間を突いていかないといけません。如何に攻撃を困難にするかが重要です。Windowsだと互換性維持の為に継ぎ接ぎだらけで隙間も多いですが、Linuxなどだと一貫性があって隙間は少なく堅固です。
んーLINUXと比べてどうこうって主張だから、合ってるのにちょこっとずれた話になってるのかな?
今回の件はWINDOWS仕様なので、LINUXの仕様前提でってのはなしにしよう。(個人的にもCUI・GUI両方LINUX使ってるんで言いたいことはわかります)
ようはね、WebDavにしろ、Autrun.infのことにしろ、ローカルと同等の領域として扱っているから、WINの仕様として、やばいものも実行できちゃってるわけですよ。
flashファイル開いたらウィルスに感染させるとが出来るなら
なので、ここだけはNG。ローカルにflash保存しての話限定であれば、この話とかみ合うけど、普通はネット越しのローカル扱いされない領域での話だから。
でね、ローカルと同等の領域として扱うってことは、そちらの主張からだと「その文化そのものが脆弱性」ってことでしょ。その論議は宗教論議になるからやめましょう。
お言葉を借りれば、まさにこれ、「WebDavを切る、信頼のおけない領域と接続しない等々」「頼できないCD-ROM/R/フラッシュメモリ/etc...を挿さないという運用」そうすることで対応することでしょってのが、こちらの主張なのですよ。
「俺達WINユーザーは知らずに危ない方法を選んでたんだー」って話になるだけでいいんじゃないかな?(個人的にもXP・VISTA・7使ってるんで一応わたしも俺達に含まれます)
てことで、ローカルと同等の領域として扱う文化のWINは、招き入れる境界をリテラシィかポリシィかできっちりやるか、外部を扱う安全な別な手段を生み出すか、さぁ選べって言われるべき状況なんじゃなかなと。
そういう意味で、「機能や仕様の脆弱性だー」って話とは違うんじゃない?ってこと。
無論、LINUXと比べりゃ、UACありのWINでさえ根本的に難ありってのはわかるけどさ、そこは切り分けて話そうよ。今回はWIN限定の問題ってことで、一つご容赦を。
いわんとしている事がいまいち理解出来ないのだけれど。対処方法は何も一つに限った事ではないでしょう。OS側、アプリケーションの開発側、ユーザー側、それぞれがそれぞれに色々なポリシー持ってて、色々考えてる訳だけれど、それらに不整合や考えの及ばなかった所があると思うわけ。そして、それぞれの立場での対処方法もあると思う。Windowsの文化も昔から少しずつ変わってきてるし、アプリケーション側で対処出来ることもあるだろうし、あと、何よりこういうシチュエーションをどれくらいの人が認識できていたのか。
というか、こんな抽象的なことをグダグダ書いて
いわんとしている事がいまいち理解出来ないのだけれど。
うん、残念ながら元コメからの流れをご理解いただけていないようです。
DLLサーチの仕様は、ローカル(スタンドアローンでもいいや)では便利なので、WINでは旧来から使われてきた伝統なのですよ。
この元コメの流れで提議されているのは、イントラでも、管理者信頼できないネット越しでも、フォルダとして開いたら、ローカルと同程度と扱うってことが一番の問題なんだよね?ってこと。
今回の対策もDLLサーチ塞いでも気休めでしかない。だって、ローカルと同程度に扱うことをやめないんだから、作る側も使う側もローカルで可能なことは、できることが前提で
>DLLサーチの仕様は、>ローカル(スタンドアローンでもいいや)では便利なので、>WINでは旧来から使われてきた伝統違います。互換性維持の為に残されてきた悪習です。カレントディレクトリからdllが読めて便利なことなんて全くといって良いほどありません。# 実行ファイルと同じフォルダからのdll読み込みとは違いますよ?
>今回の対策もDLLサーチ塞いでも気休めでしかない。気休めではありません。根本的な対策です。
>ローカル以外をフォルダとしてつなぐときは、>サンドボックスとして扱うローカルでも人から貰った圧縮ファイルなど危険なものはいくらでもあります。
一度反映されたコメントが数時間後になぜか消えていたので、ちょいと端折りつつ再書き込み。何が悪くて消えれたのかな?
今回の件は、ローカルなら便利なWINの仕様だけれども、使い方を間違えて、信頼できない外部をローカル同等としてマウントしているだけだから、そういう使い方の間違いを仕様の欠陥とは言わないんじゃないかな。といわんとしております。
信頼できない外部をマウントしないように、リテラシィかポリシィできっちりやるか、それとも別な方法で安全にマウントするか、今回の件の議論はこの二つであるべきってのが元コメからの流れ。
別な方法とし
頭に血が上っているように見えます・・・的をよく狙って一発で打ち抜くのが、いいコメントだと思います。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
UNIXはシンプルである。必要なのはそのシンプルさを理解する素質だけである -- Dennis Ritchie
そもそも (スコア: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, 参考になる)
>「仕様の範疇」
この仕様(Design=設計)が何を指しているか分かりません。
ファイル共有へのアクセスが透過的なのはWindowsの仕様です。
今回の問題は酷いWindowsのDLL読み込みの仕様に対して対策をしていなかった多くのアプリケーションが脆弱だという話です。この脆弱性は設計から来るものではなく、アプリケーションの局所的な問題から来るものです。
約48%のSMBサーバーがマルウェアに感染しています [net-security.org]。この脆弱性は組織内アウトブレーク [nikkeibp.co.jp]を引き起こす可能性のある致命的なものです。
今回の件はアプリケーション側での解決法がありますが、それが無い場合はシステム側の仕様の脆弱性です。
AutoRunについては酷い仕様ですが、Microsoftは脆弱性では無いと言っていますね。AutoRunからのウィルス感染は多いのですが、あの悪名高いそれは仕様です [hatena.ne.jp]ということでしょう。そもそもWindows自体がぜいじゃk(ry
まぁUSBメモリ型でキーボードコマンドを送り込むハードウェアのようにOSに依存しない攻撃法もあるので、ソフトウェアでは防げない問題もあります。結局はリスク管理の問題ですが、防げることは防ぐべきです。
>仕様の悪用方法は、
>そりゃ探せばいくらでもあるよね?
Officeのマクロ付きファイルでは警告がでるようになりました。ダウンロードしたプログラムを起動すると警告が出るようになりました。
仕様か否かに関わらず脆弱性は毎日発見されては対策されています。
>”突破されたら”なんでもあり
なんでもありじゃないです。仕様の隙間を突いていかないといけません。如何に攻撃を困難にするかが重要です。
Windowsだと互換性維持の為に継ぎ接ぎだらけで隙間も多いですが、Linuxなどだと一貫性があって隙間は少なく堅固です。
Re:そもそも (スコア:1, すばらしい洞察)
んーLINUXと比べてどうこうって主張だから、
合ってるのにちょこっとずれた話になってるのかな?
今回の件はWINDOWS仕様なので、
LINUXの仕様前提でってのはなしにしよう。
(個人的にもCUI・GUI両方LINUX使ってるんで言いたいことはわかります)
ようはね、WebDavにしろ、Autrun.infのことにしろ、
ローカルと同等の領域として扱っているから、
WINの仕様として、
やばいものも実行できちゃってるわけですよ。
なので、ここだけはNG。
ローカルにflash保存しての話限定であれば、この話とかみ合うけど、
普通はネット越しのローカル扱いされない領域での話だから。
でね、ローカルと同等の領域として扱うってことは、
そちらの主張からだと「その文化そのものが脆弱性」ってことでしょ。
その論議は宗教論議になるからやめましょう。
お言葉を借りれば、まさにこれ、
「WebDavを切る、信頼のおけない領域と接続しない等々」
「頼できないCD-ROM/R/フラッシュメモリ/etc...を挿さないという運用」
そうすることで対応することでしょってのが、
こちらの主張なのですよ。
「俺達WINユーザーは知らずに危ない方法を選んでたんだー」
って話になるだけでいいんじゃないかな?
(個人的にもXP・VISTA・7使ってるんで一応わたしも俺達に含まれます)
てことで、ローカルと同等の領域として扱う文化のWINは、
招き入れる境界をリテラシィかポリシィかできっちりやるか、
外部を扱う安全な別な手段を生み出すか、
さぁ選べって言われるべき状況なんじゃなかなと。
そういう意味で、
「機能や仕様の脆弱性だー」
って話とは違うんじゃない?ってこと。
無論、LINUXと比べりゃ、
UACありのWINでさえ根本的に難ありってのはわかるけどさ、
そこは切り分けて話そうよ。
今回はWIN限定の問題ってことで、一つご容赦を。
Re: (スコア:0)
いわんとしている事がいまいち理解出来ないのだけれど。
対処方法は何も一つに限った事ではないでしょう。
OS側、アプリケーションの開発側、ユーザー側、それぞれがそれぞれに色々なポリシー持ってて、色々考えてる訳だけれど、それらに不整合や考えの及ばなかった所があると思うわけ。
そして、それぞれの立場での対処方法もあると思う。
Windowsの文化も昔から少しずつ変わってきてるし、アプリケーション側で対処出来ることもあるだろうし、あと、何よりこういうシチュエーションをどれくらいの人が認識できていたのか。
というか、こんな抽象的なことをグダグダ書いて
Re: (スコア:0)
うん、残念ながら元コメからの流れをご理解いただけていないようです。
DLLサーチの仕様は、
ローカル(スタンドアローンでもいいや)では便利なので、
WINでは旧来から使われてきた伝統なのですよ。
この元コメの流れで提議されているのは、
イントラでも、管理者信頼できないネット越しでも、
フォルダとして開いたら、ローカルと同程度と扱うってことが
一番の問題なんだよね?ってこと。
今回の対策もDLLサーチ塞いでも気休めでしかない。
だって、ローカルと同程度に扱うことをやめないんだから、
作る側も使う側も
ローカルで可能なことは、
できることが前提で
Re: (スコア:0)
>DLLサーチの仕様は、
>ローカル(スタンドアローンでもいいや)では便利なので、
>WINでは旧来から使われてきた伝統
違います。互換性維持の為に残されてきた悪習です。カレントディレクトリからdllが読めて便利なことなんて全くといって良いほどありません。
# 実行ファイルと同じフォルダからのdll読み込みとは違いますよ?
>今回の対策もDLLサーチ塞いでも気休めでしかない。
気休めではありません。根本的な対策です。
>ローカル以外をフォルダとしてつなぐときは、
>サンドボックスとして扱う
ローカルでも人から貰った圧縮ファイルなど危険なものはいくらでもあります。
Re: (スコア:0)
一度反映されたコメントが数時間後になぜか消えていたので、
ちょいと端折りつつ再書き込み。
何が悪くて消えれたのかな?
今回の件は、
ローカルなら便利なWINの仕様だけれども、
使い方を間違えて、信頼できない外部を
ローカル同等としてマウントしているだけだから、
そういう使い方の間違いを仕様の欠陥とは言わないんじゃないかな。
といわんとしております。
信頼できない外部をマウントしないように、
リテラシィかポリシィできっちりやるか、
それとも別な方法で安全にマウントするか、
今回の件の議論はこの二つであるべきってのが元コメからの流れ。
別な方法とし
Re: (スコア:0)
一部のコメントが表示されなくなる/.の
バグ仕様です。Re: (スコア:0)
頭に血が上っているように見えます・・・
的をよく狙って一発で打ち抜くのが、いいコメントだと思います。
Re: (スコア:0)