パスワードを忘れた? アカウント作成
この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。

WindowsにおけるDLLハイジャック脆弱性、多くのメジャーなソフトウェアにも」記事へのコメント

  • by Anonymous Coward on 2010年08月27日 18時15分 (#1816518)

    Windowsには動的ライブラリ(DLL)を相対指定で読み込もうとすると最初にカレントディレクトリから探すという仕様

    2000年の時点でこんな記事が…「WindowsのDLL呼び出し順序に由来するセキュリティ・ホール - DLLを呼び出す「順序」が元凶 [nikkeibp.co.jp]」

    それにしても酷い仕様だ。

    • by kei100 (5854) on 2010年08月28日 1時08分 (#1816662)

      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]とかで文字な場合もある)とか
        みたいな感じのファイルがアプリのフォルダにがあったら要注意だと思います。

        親コメント
      • by Anonymous Coward

        > 普通は自アプリケーションのフォルダを絶対指定するとは思いますが、
        自アプリケーションのフォルダは常に最優先だったはずだけど(KnownDllとかの例外はあるけど)。

        • Windowsが機能追加して「MSめ、同じ名前のDLLを標準で組み込みやがった畜生!」とかいうケースがあるので、絶対パスってます。

          親コメント
          • by Anonymous Coward

            いや、自ディレクトリが最優先でしょ。
            標準で組み込まれようとまず無関係でない?
            それとも特別なDLLと名前が被ったの?

            • 大切な前提として「ユーザーが消した」「セットアップが不完全」ってのが検出できて適切に縮退する事です。
              中途半端に動くのが一番怖いので。

              あと、どうせ他のリソース(iniとかxmlやら)は絶対パスで読まないと駄目なので絶対パスを構築する関数が用意済みってのもあるかしら。

              親コメント
    • by Anonymous Coward on 2010年08月27日 18時38分 (#1816531)

      Dynamic-Link Library Search Order (Windows) [microsoft.com]
      最近のWindowsでは Safe DLL search mode という機能が導入されて改善されたはず
      と思ったら優先順位が変わっただけで相変わらずカレントディレクトリが検索パスに入ってるし。

      ACLだの整合性レベルだのUIPIだの導入してる癖になんでこんなところは雑なんだ。

      親コメント
      • by kcg (26566) on 2010年08月27日 20時54分 (#1816577) ホームページ 日記

        .Netのアセンブリですべて解決しようとしているのでしょう。
        そう簡単に移行できずにいるようですが。

        親コメント
      • by Anonymous Coward on 2010年08月27日 20時07分 (#1816559)
        カレントから検索するって仕様は後方互換性のために
        弄れないんだと思う。
        なんか今に始まったホールのような言い方してる人は、
        多分駄目SIの人間で、こうやって世間を騷がして、皆の問題して
        誤魔化そうとしてるんだと思う。

        日経*とかスッラッシュドットとか人事紺猿系のサイトって最近その為の
        サイトになってたりする。
        親コメント
        • by Anonymous Coward

          カレントから検索するって仕様は後方互換性のために
          弄れないんだと思う。

          VistaでDocuments and SettingsからUsersに変更されましたし、デスクトップセッション0の分離等で常駐系のソフトが影響を受けましたが。

          • by Anonymous Coward

            でっていう

          • by Anonymous Coward

            Vista以降でもUsersへのディレクトリジャンクションとしてDocument and Settingsが残ってますがね。これも互換性のため。

    • by Anonymous Coward

      最初は .exe の場所では。
      カレントディレクトリは2番目。(ただし、最近のWindowsだとsystem32, system, windowsに次ぐ5番目)

      • by Anonymous Coward
        なので、LoadLibraryが悪いとか、そういう話ではないですよね。
        プラグインをロードするときに、フルパス指定せずに、相対パスで読み込んでいるとか、そういう類の話だと思われるんですが。
        # リンク先はちょっと目を通したぐらいじゃ理解できませんでした。
        • by Anonymous Coward

          類としてはそうなんですが、
          相対パスって話でなくて、パスを指定なしで起動するとって話。

          こんなの昔からWindows/DOSの仕様がオカシイといわれてた話。

          UNIXで利用してる場合、
          「カレントディレクトリをPATHに含めないのはなぜか?」とか、
          「カレントディレクトリを追加する場合は、最後にしよう。」とか、
          そうゆう文脈で語られる基礎知識の話。

          いまさら理解できませんとか、許しませんよ?

    • by Anonymous Coward
      これはいわゆる DLL 地獄に対する逃げ道としてのメカニズムですよね

      Windows では OS 自体の仕様になっちゃってますが
      Unix 系でも開発者がユーザに
      LD 系の環境変数を変えさせるという
      「仕様」にしちゃってる例はよく見られます
      #昔はこーゆーのは root の仕事でしたなぁ
      • by Anonymous Coward

        Linux とか *BSD* の一般向け環境だとパッケージメンテナの仕事になった感じですよね。
        OS=ディストリビューションの変態仕様への対応はディストリビューションの一部でもあるメンテナがするはめに。

        Windows でも Microsoft もアプリのメンテナンスをできるようにしたら良いのに。
        ソースを預けてしまってアーキテクチャ毎のビルドや緊急修正はマイクロソフトがやってしまって開発側にフィードバックすれば良い。
        この際、アプリケーションの販売もマイクロソフトアップデートからすれば開発する方にもメリットがあるんじゃないでしょうか。

        • by Anonymous Coward
          無理

          Linuxや*BSDに比べて、Windowsのアプリケーションソフトやフリーソフトの数は、膨大なんですよ。
        • by Anonymous Coward
          そんなことしてみろ、たちまち「Microsoftがソースを盗んでるぞ」と大騒ぎになるに決まってんだろ。
        • by Anonymous Coward

          そんな事すると、Windows7のXpモードみたく、各OS・SP毎に仮想環境でも用意する必要が出る。
          直置きDLLが欲しいのはメーカー非推奨であったとしても「取りあえず動かしたい」ってのに対処する為の構造だからなぁ。
          現状でもMSの互換性維持は優秀なのに「OS替えたらソフトが動かない。ケシカラン!」てのは多々出ている。
          それがいきなり10倍にも成る様な方向性はムズいだろ。
          LinuxやBSDで互換性問題が言われないなんて話は無いんだから。

    • by Anonymous Coward
      なんで今更こんなこと言ってんのかわからんな
      DLLHellのころからこんなん常識だし、
      カレントディレクトリに自分の使いたいバージョンのDLL入れられなくなるのは困るじゃん

長期的な見通しやビジョンはあえて持たないようにしてる -- Linus Torvalds

処理中...