Linux とか *BSD* の一般向け環境だとパッケージメンテナの仕事になった感じですよね。 OS=ディストリビューションの変態仕様への対応はディストリビューションの一部でもあるメンテナがするはめに。
Windows でも Microsoft もアプリのメンテナンスをできるようにしたら良いのに。 ソースを預けてしまってアーキテクチャ毎のビルドや緊急修正はマイクロソフトがやってしまって開発側にフィードバックすれば良い。 この際、アプリケーションの販売もマイクロソフトアップデートからすれば開発する方にもメリットがあるんじゃないでしょうか。
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やら)は絶対パスで読まないと駄目なので絶対パスを構築する関数が用意済みってのもあるかしら。
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)
VistaでDocuments and SettingsからUsersに変更されましたし、デスクトップセッション0の分離等で常駐系のソフトが影響を受けましたが。
Re: (スコア:0)
でっていう
Re: (スコア:0)
Vista以降でもUsersへのディレクトリジャンクションとしてDocument and Settingsが残ってますがね。これも互換性のため。
Re: (スコア:0)
最初は .exe の場所では。
カレントディレクトリは2番目。(ただし、最近のWindowsだとsystem32, system, windowsに次ぐ5番目)
Re: (スコア:0)
プラグインをロードするときに、フルパス指定せずに、相対パスで読み込んでいるとか、そういう類の話だと思われるんですが。
# リンク先はちょっと目を通したぐらいじゃ理解できませんでした。
Re: (スコア:0)
類としてはそうなんですが、
相対パスって話でなくて、パスを指定なしで起動するとって話。
こんなの昔からWindows/DOSの仕様がオカシイといわれてた話。
UNIXで利用してる場合、
「カレントディレクトリをPATHに含めないのはなぜか？」とか、
「カレントディレクトリを追加する場合は、最後にしよう。」とか、
そうゆう文脈で語られる基礎知識の話。
いまさら理解できませんとか、許しませんよ？
Re: (スコア:0)
Windows では OS 自体の仕様になっちゃってますが
Unix 系でも開発者がユーザに
LD 系の環境変数を変えさせるという
「仕様」にしちゃってる例はよく見られます
#昔はこーゆーのは root の仕事でしたなぁ
Re: (スコア:0)
Linux とか *BSD* の一般向け環境だとパッケージメンテナの仕事になった感じですよね。
OS=ディストリビューションの変態仕様への対応はディストリビューションの一部でもあるメンテナがするはめに。
Windows でも Microsoft もアプリのメンテナンスをできるようにしたら良いのに。
ソースを預けてしまってアーキテクチャ毎のビルドや緊急修正はマイクロソフトがやってしまって開発側にフィードバックすれば良い。
この際、アプリケーションの販売もマイクロソフトアップデートからすれば開発する方にもメリットがあるんじゃないでしょうか。
Re: (スコア:0)
Linuxや*BSDに比べて、Windowsのアプリケーションソフトやフリーソフトの数は、膨大なんですよ。
Re: (スコア:0)
Re: (スコア:0)
そんな事すると、Windows7のXpモードみたく、各OS・SP毎に仮想環境でも用意する必要が出る。
直置きDLLが欲しいのはメーカー非推奨であったとしても「取りあえず動かしたい」ってのに対処する為の構造だからなぁ。
現状でもMSの互換性維持は優秀なのに「OS替えたらソフトが動かない。ケシカラン！」てのは多々出ている。
それがいきなり10倍にも成る様な方向性はムズいだろ。
LinuxやBSDで互換性問題が言われないなんて話は無いんだから。
Re: (スコア:0)
DLLHellのころからこんなん常識だし、
カレントディレクトリに自分の使いたいバージョンのDLL入れられなくなるのは困るじゃん