WindowsにおけるDLLハイジャック脆弱性、多くのメジャーなソフトウェアにも 106
いまそこにある危機 部門より
あるAnonymous Coward 曰く、
世間を騒がせつつあるDLLハイジャックの脆弱性であるが、セキュリティ診断ツールMetasploitの開発版においてこの問題をチェックする機能「webdav_dll_hijacker」が追加され、簡単にこの脆弱性を発見できるようになった（Metasploitのブログ記事、本家記事）。
問題となっている脆弱性は、アプリケーションがリモートの共有ディレクトリ内にあるファイルを開く際にそのファイルと同じディレクトリにあるDLLをロードしてしまうというもの。webdav_dll_hijackerではLinux上でWebDavサーバーを実行させ、Windows側からそこにあるファイルを開くことで診断を行うという。もし脆弱性がある場合、ソフトウェアがサーバー側にあるDLLを読み出そうとするため、サーバー側にアクセスのログが残る。これをチェックすることで脆弱性を発見する、という原理だそうだ。
実際、これによって脆弱性のあるソフトウェアが数多く発見されたという。脆弱性の見つかったソフトウェアはアドレス帳などのWindows付属ソフトウェアを始め、Adobe製品、Autodesk製品、Google Earth、Mozilla Thunderbird、Opera、Safariなど多種多様に渡る。また一覧に乗っていなくても、まだ webdav_dll_hijacker が試されていないだけだったり、特殊な条件下でのみDLLを脆弱性のある方法で読み込むという可能性もあるので、安心はできない。
この脆弱性はUSBメモリなどのドライブや圧縮ファイルを解凍したもの、WebDavやSMBなどのリモートネットワーク共有経由でも影響を受ける。
Windowsには動的ライブラリ（DLL）を相対指定で読み込もうとすると最初にカレントディレクトリから探すという仕様があり、脆弱性の原因はその仕様を考慮しないでソフトウェアが作られたことにある。Linuxなどでは動的ライブラリ（*.so）をカレントディレクトリから探すということはしないため、この問題は基本的に発生しない（リンカオプションのrpathや環境変数のLD_LIBRARY_PATHを故意に弄ったりしない限り）。
アドレス帳の脆弱性を使ったデモ動画もあるので興味のある方はどうぞ。
2000年からわかっていた問題 (スコア:2, 興味深い)
Windowsには動的ライブラリ（DLL）を相対指定で読み込もうとすると最初にカレントディレクトリから探すという仕様
2000年の時点でこんな記事が…「WindowsのDLL呼び出し順序に由来するセキュリティ・ホール - DLLを呼び出す「順序」が元凶 [nikkeibp.co.jp]」
それにしても酷い仕様だ。
Re:2000年からわかっていた問題 (スコア:5, 参考になる)
15年前のソフトも動かせるってのはそういう事です。
まぁ、その記事はかなり古い(10年前ですよ!)ので今セキュリティ的にサポートされてるXP SP3以降であれば、問題はかなり低減されています。
この問題が発生するのは、自分がそのDLLを使う事が解っているのに、DLLを適切に入れてないケースです。
ぶっちゃけ、自分が何を使ってるのか解ってない、構成管理が出来ていない、適切にセットアップ出来てないケースです。
最近の大規模化してるアプリだとまぁ、ありがちではありますが・・・
例えばVBアプリケーションやDirectXアプリケーションなんかはランタイムDLLの一部が無くてもとりあえず動いちゃったりするので、今一度確認してみると良いでしょう。
(そのまま使い続けてるケースは少ないとは思いますが)
もしくは、機能拡張可能な仕様としているが、現在その機能拡張が導入されていないといったケースでしょうか？
普通は、該当DLLファイルの実態があるかを確認してからロードすべきだというツッコミをしたくなりますが、
エラー処理に任せてとりあえずロードしてみる男気あふれるアプリは要注意ですね。
昔のOSにはあったが今は無くなった機能を呼び出すケース、
最近のOSのみにある機能を呼び出す系統のアプリをXPで呼び出すケースも要注意です。
(Vista以降のAeroとか、Win7のタスクバー拡張とかそういう新しいOS限定の機能にも対応してそうな奴)
他に注意すべきは、プラグインによる拡張可能なアプリケーションやIME、フックを利用するキーボード/マウス系に始まる各種便利ツール類です。
これらは、アプリケーションプロセスに寄生しますが、そのDLL内から更に別のDLLを呼び出す可能性があります。
この場合、本体アプリケーションに問題が無くても、その寄生されている拡張が原因で脆弱性を持った状態に作り変えられてしまう現象が起こり得ます。
普通は自アプリケーションのフォルダを絶対指定するとは思いますが、インストール時に環境変数のPATHに追加するだけという手を抜いてるケースだと危険性が高くなります。
特にXP SP2より前、SP1とか2kとかだとカレントディレクトリが優先して呼ばれますし、
また、ショートカットなどでアプリケーションのOS互換性設定(Vistaより前のXP SP3等)してると、カレントディレクトリが先に来ますのでかなり不味いですね。
ちなみに、上記の問題が無いアプリケーションをお使いであれば、User権限で暮す、UACをONはそこそこ効果的な対策になりえます。
アプリのインストール先をProgram Filesにしてあれば通常アプリケーションからDLLを改ざんされなくなりますし、
ユーザーがうっかりコピーして入れる事も基本的にありませんので。
とりあえず、Hotfix:(KB2264107)入れてカレントディレクトリからの読み込むを無効にしちゃう [microsoft.com]のが一番お手軽ですね。
動かなくなったアプリは既に実は死んでたのが表面化したということで。
Re:2000年からわかっていた問題 (スコア:1)
セルフ追記。
日本語にはまだ対応してない、多言語対応アプリも要注意かもしれません。
リソースをDLLで持っていて読み取り方法が不味く、システム言語ファイルをとりあえず最初にロードするタイプだと合わせ技で食らうかもしれません。
アプリ名_langid.dll例えば"lang0409.dll"とか、
"AppName.1033"(拡張子は必ずしもDLLとは限らない)とか、
AppLang.enu(GetLocaleInfo [microsoft.com]+LOCALE_SABBREVLANGNAME [microsoft.com]とかで文字な場合もある)とか
みたいな感じのファイルがアプリのフォルダにがあったら要注意だと思います。
Re:2000年からわかっていた問題 (スコア:1)
Windowsが機能追加して「MSめ、同じ名前のDLLを標準で組み込みやがった畜生！」とかいうケースがあるので、絶対パスってます。
Re:2000年からわかっていた問題 (スコア:1)
大切な前提として「ユーザーが消した」「セットアップが不完全」ってのが検出できて適切に縮退する事です。
中途半端に動くのが一番怖いので。
あと、どうせ他のリソース(iniとかxmlやら)は絶対パスで読まないと駄目なので絶対パスを構築する関数が用意済みってのもあるかしら。
Re:2000年からわかっていた問題 (スコア:2, 参考になる)
Dynamic-Link Library Search Order (Windows) [microsoft.com]
最近のWindowsでは Safe DLL search mode という機能が導入されて改善されたはず
と思ったら優先順位が変わっただけで相変わらずカレントディレクトリが検索パスに入ってるし。
ACLだの整合性レベルだのUIPIだの導入してる癖になんでこんなところは雑なんだ。
その辺は (スコア:2)
.Netのアセンブリですべて解決しようとしているのでしょう。
そう簡単に移行できずにいるようですが。
Re:2000年からわかっていた問題 (スコア:1, 興味深い)
弄れないんだと思う。
なんか今に始まったホールのような言い方してる人は、
多分駄目SIの人間で、こうやって世間を騷がして、皆の問題して
誤魔化そうとしてるんだと思う。
日経*とかスッラッシュドットとか人事紺猿系のサイトって最近その為の
サイトになってたりする。
Re: (スコア:0)
最初は .exe の場所では。
カレントディレクトリは2番目。(ただし、最近のWindowsだとsystem32, system, windowsに次ぐ5番目)
Re: (スコア:0)
プラグインをロードするときに、フルパス指定せずに、相対パスで読み込んでいるとか、そういう類の話だと思われるんですが。
# リンク先はちょっと目を通したぐらいじゃ理解できませんでした。
Re: (スコア:0)
Windows では OS 自体の仕様になっちゃってますが
Unix 系でも開発者がユーザに
LD 系の環境変数を変えさせるという
「仕様」にしちゃってる例はよく見られます
#昔はこーゆーのは root の仕事でしたなぁ
WebDAV (スコア:1, 参考になる)
Re: (スコア:0)
なんで1発目のコメントに「既出」が付くの？
関連ストーリーのコメントとダブることすら許されないの？
Re: (スコア:0)
ウェブダブなだけに
なんちゃって
DLL相対指定時にカレントを対象にする仕様自体はいいとして (スコア:1)
ファイルの関連付け実行でカレントがそのファイルのある場所になる意義は何も無いはず。
と思ったが、ファイルダイアログの開始フォルダがカレントになるから、こっちのほうが使い勝手よくなるのね。
ついでに、これWindowsのファイル実行APIじゃなくてexplorer(SHELLDLL_DefView)の仕様だから、explorerでファイル実行しない人はあんま関係ない。
Re:DLL相対指定時にカレントを対象にする仕様自体はいいとして (スコア:1)
と思ったが、ファイルを実行するときに、大抵はexe(だけじゃないけど)とそれ以外を分けてないだろうから、explorerじゃなくても、普通はファイルのあるフォルダをカレントとして実行するよね、っていうか、今試したら自分のプログラムもしてた。
Re: (スコア:0)
カレントディレクトリと無関係の開始ディレクトリも指定できるから指定してカレントディレクトリは変更しないようにフラグを指定したほうが安全。
だけどわざわざそんな面倒なことをしてるアプリはほとんどないって話ね。
『Windowsアプリケーションにおける』だよね (スコア:1)
Re: (スコア:0)
Re:『Windowsアプリケーションにおける』だよね (スコア:2)
カレントディレクトリを検索しないと動かないシステムが一杯でてきたりして
つまりどういうことだってばよ！？ (スコア:0)
Windowsの多くのソフトが危うくて危険が険しいと言うことですか。
WebDavとかいうのが一番悪いというわけではなく、
WindowsのDLL読み込み順序の仕様が致命的なミスを誘うようになってたと言うことですか？
よくわからんのですが、例えばある解凍ソフトがあるDLLを使う場合に、
そのDLLと同名の悪意を持ったDLLを解凍ソフトの.exeと同じフォルダに配置して、
解凍ソフトを実行した場合に悪意を持ったDLLが読み込まれて問題が起きると言うことですか？
その場合は.exeと同じ場所(もしくは環境変数で指定されている場所など)に
悪意を持ったDLLを置かせないよう、気を付けていれば問題ないのですか？
Re: (スコア:0)
>解凍ソフトの.exeと同じフォルダ
この場合、適当な圧縮ファイルをダブルクリックすると解凍ソフトが立ち上がると思うが、
その時その圧縮ファイルと同じフォルダに悪意のある名前のDLLが有れば、それが実行されてしまう。
そしてWebDavのおかげでそのフォルダがネットの向こうにあっても構わない。
Re: (スコア:0)
より正確に言えば、解凍ソフトの.exeが置かれているフォルダに目的とするDLLが存在せず、かつ、圧縮ファイルの置かれたディレクトリにその名前と同名の悪意のあるDLLファイルが置かれている場合、でしょ。DLLのサーチ順序は、カレントディレクトリよりもEXEファイルが置かれているディレクトリの方が先ですから。
要するに攻撃者が攻撃を成功させるためには「.EXEのあるディレクトリから該当するDLLを削除したのちに」、悪意のあるDLLとそれをキックするための文書ファイルを送り付けなきゃいけないわけで、サーチ順序の最初にある「.exeが置かれているフォルダ」というのを無視した議論なんじゃないのかねぇ
Re:つまりどういうことだってばよ！？ (スコア:1, 参考になる)
> 「.EXEのあるディレクトリから該当するDLLを削除したのちに」
それは不要でしょう。XPなんかだと、カレントディレクトリの方がシステムディレクトリや環境変数PATHの検索より優先順位が高いので、
・「Windowsのシステムが提供するDLL」などのシステムディレクトリにあるDLL
・複数アプリケーションで共有するためなどの理由で、EXEファイルとは別の、PATHの通ったディレクトリに置いてあるDLL
については、同名のDLLによる差し替えが可能になります。それで十分驚異的。
タレコミに上がっている実行例ではwab32res.dll が狙われています。
Re:つまりどういうことだってばよ！？ (スコア:3, 参考になる)
だからこれが間違いだってば。なんでこの程度のこと確認しないの?
すでに他の人にも指摘されているけど、Windows XPについてはSP2から、以下の順序でサーチされる [microsoft.com]んだってば。
要するに、この爆弾を起爆するには、カレントディレクトリよりも上位にある同名のDLLを全部削除しなきゃ駄目。少なくとも、XPsp2以降またはWindows2000sp4はね。
Re:つまりどういうことだってばよ！？ (スコア:1)
・あるアプリが、DLL不足の状態でインストールされていて起動しない、もしくは、プラグイン不足のような形で特定の機能のみ使えない
・そのアプリが何らかの拡張子に関連づけされている
という状況で、例えば、 不足しているDLLと同名の「悪意のあるDLL」と同じディレクトリに置いてある、その拡張子のファイルを開こうとすると、悪意のあるDLLが読み込まれる。
動かないアプリになんかの拡張子が関連づけられたままPCを使ってるとか、にもかかわらずその拡張子のファイルを開けようとするとか、 問題となってるDLLの名前を悪意を持った第3者が知ってるとか、条件がいろいろと不自然だけど。
強いて挙げるなら、その状況を作為的に作る事は出来そうな気もする。 例えば、
・「この動画を見たければ、再生ソフト○○をインストールすべし」と促すウェブページを作る
・促すソフトとしては、普通に流通しているフリーウェアからいくつかの条件を満たす物を選ぶ
・条件とは、「インストールするとデフォルトで拡張子.fooに対して関連づけされる」「プラグインのDLLを追加すると.foo形式のファイルの内、再生出来るコーデックが増える」
・「ソフトをインストールしたらこのリンクをクリックすると動画再生開始」のようなリンクを作り、リンク先をWebDavで公開された.foo形式のファイルにする
・リンク先は、追加のプラグインDLLが無いと再生出来ないコーデックな.foo形式のファイルで、同じWebDavフォルダ上には、偽の追加プラグインDLLが置かれている
・偽の追加プラグインDLLがロードされ、悪意のあったコードが実行される
回りくどいけど。「これを我がウェブページからダウンロードしてインストールせよ」と言われると怪しいから絶対触らないけど、有名なフリーウェア紹介サイトへのリンクになっていれば怪しさ半減。ついでに、インストールさせるツールは何の細工もない優良なソフトウェアなので、ウィルスチェッカの類に検知されない。でも悪意を持ったDLLの方もウィルスチェッカの検査を通るだろうから脅威が大幅に増えるわけではないかな。
# デフォルト設定のまま常用してるとあるツール、ある操作をすると
# 「プラグインhogehoge.DLLが見つかりません」の類のエラーが出る。
# このツールに対する攻撃をされるとちょっと危ないかな、とか思ったとこからの連想検討。
# そのツールが、フィッシング詐欺やらのターゲットになるぐらいのシェアを持ってるかどうかは不明だけど。
Re:つまりどういうことだってばよ！？ (スコア:1, 参考になる)
・なぜか存在していないDLLを探している（しかしエラーにならない）
・他所のDLLを利用しようとして失敗してる（けどエラーにならない）
・多言語対応でその言語版に存在しないDLLを探している（というか読めるDLLにより何言語版か決めている）
・Windowsの古いバージョンにしか存在しないDLLを探している（既にない機能への対応が残ってる）
理由は色々あると思います。
・フリー/有料とか通常/上位版とか別アプリとの連携機能とかを取り合えずDLL呼んで成功/失敗で分けてる
・別アプリへのプラグイン追加でexeの場所が違うからPATHで対応/プラグイン呼び出しか否か判断/バグってるけどエラーでなくて気がついてない
・95/2000対応時代の古いコードを削除する必要がないからそのまま今でも残ってる
とか。
あと、攻撃手法もWebDav経由でドキュメント開くだけじゃなくて
・safariにある（あった？）プロンプトなしでファイルをダウンロードさせるバグと（同様のバグと）組み合わせるとデスクトップフォルダにdllを仕込むことでデスクトップのドキュメント開くと発動する様になる
・自分のFacebookのページと称して、カレントディレクトリを指定してoperaで開くショートカットを示し、operaがサーチするdllにより攻撃する
があるそうだ。
Re: (スコア:0)
実行ファイルが置いてあるディレクトリに不正なDLLファイルがある時点で、サーバ提供者に悪意があるかサーバがクラックされている可能性があるので
実行ファイル自体も細工がされている可能性があるし、これのどこが脆弱性なのかな？と思う。
それなら、UNIX系で何らかの理由で外部鯖のPATHが優先される設定環境において、
外部鯖がクラックされて標準的なコマンドと同名の悪意あるコマンドファイルが置かれた場合も同じじゃないかと思う
（コマンドの絶対パス確認コマンドやらチェックサムコマンドが乗っ取られたら分からないし）
Re: (スコア:0)
Windowsかどうかなんて、関係ない。もちろんDLLかEXEかなんてのも関係ない。
マシンにコードを食わせればなんでもしてくれる
Re: (スコア:0)
脅威的とか何を騒いでるの？
って思う。
何かのキャンペーンなの？
Re: (スコア:0)
カレントディレクトリがとくに危険なのは、誰でも自由に書き込めるディレクトリでも簡単にカレントに設定できる(どころか何も考えていない多数のアプリが無雑作に設定してることすらある)から。
(デフォルト管理者のXPではほとんど無意味な配慮ですが)誰でも書き込めて攻撃者がパスを予測できるような場所にアプリケーションをインストールするなってことですね。
# Chromeェ…
> XPなんかだと、カレントディレクトリの方がシステムディレクトリや環境変数PATHの検索より優先順位が高いので、
XP SP2からデフォルトでシステムディレクトリよりは後回しになった。PATHよりはまだ早いみたいだけど。
http://msdn.microsoft.com/en-us/library/ms682586(v=VS.85).aspx [microsoft.com]
叩いてやるよ (スコア:1, 参考になる)
だから他の人が指摘してるけど、XPSP2以降はそんな検索順序じゃねぇ。
XPSP2未満だと既にサポート外だから最初から危険。
纏めるっていうなら伝聞だけでなくちゃんと調べろ。
流言蜚語をばら撒くな、馬鹿。
http://msdn.microsoft.com/en-us/library/ms682586(v=VS.85).aspx [microsoft.com]
へのリンクがこれだけ指摘されているのに何言っているんだ。
http://srad.jp/security/comments.pl?sid=505937&cid=1816531 [srad.jp]
http://srad.jp/security/comments.pl?sid=505937&cid=1816648 [srad.jp]
http://srad.jp/security/comments.pl?sid=505937&cid=1816634 [srad.jp]
読み込もうとするDLLがカレントディレクトリか%PATH%にのみ存在する場合が危ないの。
叩くってこんな感じでいい？
もうちっと強いほうがデマは沈静化するかな。
そもそも (スコア:0)
ダブルクリックで開くこと自体に
リテラシの問題があるんじゃないのかなぁ。
そうさせないためのポリシィ設定してない環境とか。
信頼済みネットワーク内で刺されたらご愁傷様ってことで。
そうでないと、Side By Side以前の通例がネックになるんじゃない？
DLLバージョン依存アプリはEXEとともに
動作確認済みバージョンのDLL置いておくケースは珍しくなかったしさ。
それを無視してMSに対策しましたとかされても
弊害でまくりな気がするんだけど。。。だいじょうぶなん？
Re: (スコア:0)
社内ネットワークは信頼済みに入りますか?
Re: (スコア:0)
権限がなければ、
伝染病放置の職場ってことで、
関係各位含めてご愁傷様。
Re: (スコア:0)
一見正論に見えて、何も解決しない意見ご苦労様。
Re: (スコア:0)
ローカルと同等にその場所を扱って、
ダブルクリックやオートランで開くんだから、
食らうのあたりまえじゃない？ってことなんだけど。。。
ファイルの場所がローカルで、
DLLがインターネットゾーンにあるのに、
それでもロードされて発動するんなら脆弱性といえるだろうけど、
発動可能な場所で開いたら発動するでしょそりゃ。
EXEじゃないから大丈夫だと思ったなんてのと同程度じゃないの？
それって過去も今もこれからも解消しないんじゃない？
ヒューリスティック対応のアンチウイルス使いましょうってレベルでしょ。
だから、「そもそも」脆弱性なのこれ？
Re:そもそも (スコア:1, 興味深い)
>ファイルの場所がローカルで、
>DLLがインターネットゾーンにあるのに、
>それでもロードされて発動するんなら
細工したローカルなファイルを開くことでカレントディレクトリをネットワーク共有上(例えば\\example.jp\)に変えることができれば可能なはず。
というわけでパターンマッチによる外部読み込みでSetCurrentDirectoryしてからFindFirstFileするようなソフトウェアとかは狙い目。
Re:そもそも (スコア:1, 参考になる)
> SetCurrentDirectoryしてからFindFirstFile
それは明らかにそんなことしてるほうが悪いだろ。FindFirstFileはふつうにフルパス受け付けるのに。
それよりファイルオープンダイアログでファイル共有上のファイルを選ばせるだけで危険(GetOpenFileNameはデフォルトで開いたファイルがあるフォルダをカレントにするから)
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:そもそも (スコア:1)
いいえ、少なくともDebian GNU/Linux 5.0.6上のbash/dashでは内部コマンドが優先されます。
怪しげなファイルを自由におけるWebDavからファイルを開くってシチュ (スコア:0)
実際のところたとえばiTunes使ってる人がどういう経緯で開いちゃうんだろうか？
Re: (スコア:0)
iTunesはしらんけどフィッシング的な方法が使えるでしょう。
ま、方法はともかく。
例えばテキストファイル開くのもヤバいと思う？
flashやpdfも普通のHTTP経由なら開くけどWebDav経由ならヤバい？
確かにネット経由で入手したファイルを開くのはローカルのファイルを開くのに比べたらヤバい事かもしれない。
でも、pdf開いたり圧縮ファイル開くと、任意のバイナリが実行出来るってのはセキュリティホール扱いだよね。
普通のHTTP経由なら安全でWebDav経由なら危険っておかしいよね。
Re: (スコア:0)
診断にひっかかるようなソフトは USB メモリーだろうが、なんだろうが同じことをやるわけでしょ。
Re:LINUXでも。 (スコア:2)
ってやったら同じにならない？
Re:LINUXでも。 (スコア:2, 興味深い)
shellアーカイブ形式をブラウザが勝手に展開するようになったら、Linuxも軽く死ねそう。
そういえば、Linux対応のアンチウィルスソフトって、悪意のある
shellスクリプトファイルに対応しているのかな？
# AntiVirやF-secureの製品情報ページ読んでも、よくわからない...
Re:LINUXでも。 (スコア:1)
Re:LINUXでも。 (スコア:1)
＞ Windowsってそんなヤバイ事してんの？
「余計なお世話」が行きすぎると、そんなことになるかな、というだけです。
explorerでzipファイルをシームレスに扱える、という流れからすると、「Linuxで、sharファイルがシームレスに
扱えたら便利じゃね？」ということを考える馬鹿が出ないとも限らない、ってだけ。
# そういや、しばらくsharファイルって見てないかも...
Re:LINUXでも。 (スコア:1)
＞Linuxのアンチウイルスソフトは、(略)Windowsへウイルスを感染させないために入れるものです。
ん？主にそうだ、というだけで、Linuxをターゲットにしたウィルスを検知しないわけじゃないでしょ？
Linux自体、以前にくらべればずいぶん「誰でも使える」という状態に近づいてきたから、オンデマンドで
ヒューリスティック検知（っていうのかな？）できるものならば、してもらいたいな。
# で、それに頼りきってしまって、地雷を踏む、と。