アカウント名:
パスワード:
Windowsには動的ライブラリ(DLL)を相対指定で読み込もうとすると最初にカレントディレクトリから探すという仕様
2000年の時点でこんな記事が…「WindowsのDLL呼び出し順序に由来するセキュリティ・ホール - DLLを呼び出す「順序」が元凶 [nikkeibp.co.jp]」
それにしても酷い仕様だ。
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]のが一番お手軽ですね。動かなくなったアプリは既に実は死んでたのが表面化したということで。
セルフ追記。
日本語にはまだ対応してない、多言語対応アプリも要注意かもしれません。リソースをDLLで持っていて読み取り方法が不味く、システム言語ファイルをとりあえず最初にロードするタイプだと合わせ技で食らうかもしれません。アプリ名_langid.dll例えば"lang0409.dll"とか、"AppName.1033"(拡張子は必ずしもDLLとは限らない)とか、AppLang.enu(GetLocaleInfo [microsoft.com]+LOCALE_SABBREVLANGNAME [microsoft.com]とかで文字な場合もある)とかみたいな感じのファイルがアプリのフォルダにがあったら要注意だと思います。
> 普通は自アプリケーションのフォルダを絶対指定するとは思いますが、自アプリケーションのフォルダは常に最優先だったはずだけど(KnownDllとかの例外はあるけど)。
Windowsが機能追加して「MSめ、同じ名前のDLLを標準で組み込みやがった畜生!」とかいうケースがあるので、絶対パスってます。
いや、自ディレクトリが最優先でしょ。標準で組み込まれようとまず無関係でない?それとも特別なDLLと名前が被ったの?
大切な前提として「ユーザーが消した」「セットアップが不完全」ってのが検出できて適切に縮退する事です。中途半端に動くのが一番怖いので。
あと、どうせ他のリソース(iniとかxmlやら)は絶対パスで読まないと駄目なので絶対パスを構築する関数が用意済みってのもあるかしら。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
日本発のオープンソースソフトウェアは42件 -- ある官僚
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: (スコア:0)
> 普通は自アプリケーションのフォルダを絶対指定するとは思いますが、
自アプリケーションのフォルダは常に最優先だったはずだけど(KnownDllとかの例外はあるけど)。
Re:2000年からわかっていた問題 (スコア:1)
Windowsが機能追加して「MSめ、同じ名前のDLLを標準で組み込みやがった畜生!」とかいうケースがあるので、絶対パスってます。
Re: (スコア:0)
いや、自ディレクトリが最優先でしょ。
標準で組み込まれようとまず無関係でない?
それとも特別なDLLと名前が被ったの?
Re:2000年からわかっていた問題 (スコア:1)
大切な前提として「ユーザーが消した」「セットアップが不完全」ってのが検出できて適切に縮退する事です。
中途半端に動くのが一番怖いので。
あと、どうせ他のリソース(iniとかxmlやら)は絶対パスで読まないと駄目なので絶対パスを構築する関数が用意済みってのもあるかしら。