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

Skypeのアップデート機能にDLLハイジャッキング脆弱性が見つかる」記事へのコメント

  • elevatedなプロセスが、一般ユーザが書き込めるフォルダに実行ファイルを書き出して実行しちゃうもんだから、
    そのタイミングで実行ファイルを置き換えればelevateされた権限で実行できるってやつだよね。

    Microsoftがすぐに修正しないのは、「UACはsecurity boundaryではない」(よって脆弱性ではない)っていういつもの立場からだろう。

    原因としては、高権限プロセス用の一時フォルダが、標準で存在しないのが問題なのかなあという気がする。

    #「UAC security boundary」でググったら「UAC is a security boudanry」っていうTwitterアカウントが見つかって笑った。

    • by Anonymous Coward

      DLLの読み込み方法をこれからはちょっと考えるべきだな
      仕組みを変えようってことではなく「プラグイン」としての
      DLLの在り方

      • 根っこにあるのが、MS-DOSのPATH環境変数や、その周辺の仕様だから難しそう。

        .NET FrameworkのReflectionみたいに、ピンポイントでファイル名を指定してロードさせるような仕様ならいいけど、既存の(たとえばWin32API等の)DLLは「規定の順序で探して、最初に見つかったファイル」という形式だし・・・。

        • by Anonymous Coward on 2018年02月17日 23時43分 (#3363292)

          その認識はちょっと古い。
          OSとしては、SetDllDirectoryなどによって、DLLをロードするディレクトリというのは制御可能になっているし現状では、特に問題はない。
          これは単純にSkypeというアプリの問題に過ぎない・・・というといい過ぎかな。
          しかし、SkypeはもともとMS製じゃないアプリだから、根幹の部分で修正しきれない難しい問題があるのだろう。

          親コメント
          • by Suzuno (48093) on 2018年02月18日 11時34分 (#3363353) 日記

            SetDllDirectoryにせよ、System.Reflection.Assembly.LoadFromにせよ、今後作るアプリへの対策としては十分で、OSの制御としては特に問題ないと思いますよ。

            ただ、既にあるレガシーなアプリが、上記の仕組みを組み込めるかは別問題だよねって。
            理論的にはSetDLLDirectoryは比較的低コストで従来のWin32アプリに組み込めるとは思うけど、それでも動作検証のコストは莫大になりそうだし。
            そしてMS-DOSからの使用を引きずるかぎり、そういったレガシーなアプリのDLL読み込みに「OS側が干渉して不正なDLLから保護する」方式はとれないから、後方互換を維持する限りは延々と続く問題じゃないの?これ。

            # 本気でやるならSetDllDirectoryを使う前にDLLをロードしようとしたアプリを停止させるぐらいは必要だけど
            # それで古いアプリはこぞって動かなくなるので、それでいいの?って話だと思うの。

            親コメント
            • by Anonymous Coward

              SetDllDirectory()で対策出来るのは実行時リンクするDLLだけでエントリポイントに達する前にロード時リンクされるDLLに対しては全く対策にならない

コンピュータは旧約聖書の神に似ている、規則は多く、慈悲は無い -- Joseph Campbell

処理中...