パスワードを忘れた? アカウント作成
13851970 story
Windows

Windows 7のDLL読み込みに関する脆弱性、対策はWindows 10へのアップグレード 71

ストーリー by hylom
既出ではあるが 部門より

昨年5月、複数のMicrosoft製品でDLL読み込みに関する脆弱性が発見されたが、Microsoftはこれに対し「アプリケーション ディレクトリにおけるDLLの植え付けのカテゴリに該当するDLLの植え付けの問題は、多層防御の問題として扱われ、更新プログラムは将来のバージョンについてのみ検討されます」との見解を出していた(Microsoft TechNet過去記事)。これを受けてJVNが、Windows 7 における DLL 読み込みに関する脆弱性として脆弱性レポートを公表した。

問題の脆弱性は「細工されたDLLファイルが実行ファイルと同一のディレクトリに置かれていた場合、任意のコードを実行される可能性がある」というもの(窓の杜Security NEXT)。これに対しMicrosoftはWindows 7においてはこの問題を修正する予定はないとしている。Windows 10ではこの脆弱性を緩和する機能が導入されており、脆弱性レポートでは対策方法として「Windows 10へのアップグレード」が挙げられている。

  • アプリがDLL検索パスを設定するコードに入る前にinjectionが成立してしまうのがOSの脆弱性って言ってるのなら、DLL検索パスを適切に設定していないアプリはほとんどアプリとしての脆弱性があるのでは。
    それとも今のwindows10はまだ対策されてないってことなの?

    ここに返信
    • by Anonymous Coward

      hylomが大事なところをカットしてしまったがシステムDLLが実行してるLoadLibraryが安全じゃないって話だからちと違うんだよな
      アプリ側が実行してるLoadLibraryが全てフルパスならアプリ側は悪くないだろ?
      更にWindows 7にはSetDefaultDllDirectories(LOAD_LIBRARY_SEARCH_SYSTEM32)を実行してもなおアプリケーションディレクトリから読み込みが試行されるなどという邪悪オブ邪悪なDLLまで存在してる

  • by GZ (48699) on 2019年03月04日 21時06分 (#3574669)

    >既出ではあるが 部門より

    うん、その通りなので、なんで今さらこの話題の意味がよくわからないです。もしかして、JVNが取り上げだしたから今あえて取り上げているの?

    >「細工されたDLLファイルが実行ファイルと同一のディレクトリに置かれていた場合、任意のコードを実行される可能性がある」

    ↑当たり前ですよね。例えとしては不適切なんでしょうけど・・・

    UNIXの管理者の設定で、カレントディレクトリにパスがある。

    そこにはlsというシェルスクリプトが配置されており、中身は、 rm -rf / だったら・・・

    だからパスって重要で。LD_LIBRARY_PATHにないライブラリ(dso)は読み込まないとか、そういう文化とか・・・・

    ここに返信
  • by Anonymous Coward on 2019年03月04日 15時08分 (#3574362)

    敢えて脆弱性を直さず、Windows10に移行をさせる流れは正しい。

    ここに返信
    • by Anonymous Coward on 2019年03月04日 18時24分 (#3574533)

      実際延長サポートすらきれる段階で直す義理もないしな。
      でもローカルディスクに偽装DLL置かれてる状況は既に終わってるんじゃないか。

    • by Anonymous Coward

      無料でアップデートできるならともかく、そうではないし。
      未だ延長サポート期間内であるWindows 7で脆弱性への対応を行わないのはダメだろうと思う。

      • by Anonymous Coward

        OSの挙動を変えないと原理的に対応できないケースもあるからなぁ。
        まだWindows7を使ってる中には互換性の解決途中なユーザーも居るだろうし。

      • by Anonymous Coward

        まだ7のライセンスで10に出来るんじゃ?

      • by Anonymous Coward

        直したら直したで、「今まで動いていたアプリが動かなくなった!」と言われるんじゃない。
        どちらにしろMSが悪いって言われるんだから、ご苦労な役回りだわ。。

    • by Anonymous Coward

      大問題が起きて大騒ぎになったらいやが応にもパッチ出さざるを得なくなるんだろうけど、これが大騒ぎになるほどの集団被害を引き起こす可能性は低いからね。

    • by Anonymous Coward

      10では最初から存在しない問題なのかパッチで直した問題なのか

    • by Anonymous Coward

      サポート期間を残してそれをやるのは邪悪な怠慢だわ

  • by Anonymous Coward on 2019年03月04日 15時30分 (#3574375)

    攻撃者がアプリの実行ファイルのあるディレクトリに書き込み権限がある状況で、OSやアプリにできることなんて何もないよ。
    攻撃者が/usr/binや/usr/libに書き込み権限がある状況で、システムをexploitされたらLinuxの脆弱性だとでもいうのか。
    素人なの?

    ここに返信
    • by Anonymous Coward

      だって三井物産が脆弱性って言うから・・・
      https://jvn.jp/jp/JVN69181574/ [jvn.jp]

    • by Anonymous Coward

      > 素人なの?
       
      MSに難癖をつけるプロフェッショナルです。

    • by Anonymous Coward

      ブラウザのダウンロードフォルダにダウンロードされた細工されたDLLファイルで問題を起こす例が報告されています。

      詳しくは調べてみてください。

      • by Anonymous Coward

        それって、「作業ディレクトリ」のDLLファイルを優先的にロードしてしまう脆弱性じゃないの?
        「実行ファイルと同一のディレクトリ」のDLLファイルをロードする仕様とは似て非なるものだと思うのだが

      • by Anonymous Coward

        ブラウザのダウンロードフォルダって、基本空にしておくものでしょ?
        ダウンロードしたファイルを整理していないのか?

        • by Anonymous Coward on 2019年03月04日 16時32分 (#3574431)

          一般人はしないぞ
          ファイルを削除するという概念がない

          ソースは俺の身内全員

        • by Anonymous Coward

          自分はダウンロード兼作業フォルダになってる。デスクトップは空っぽ。
          なので、ダウンロードフォルダは常にたくさんのファイルがある。
          不要になったら、ゴミ箱に捨てるか、別のフォルダに残しておくか、だな。

          Emailも受信ボックス(Inbox)は常に空にする人?

        • by Anonymous Coward

          ブラウザのダウンロードフォルダ自体、誤操作以外じゃ使わないなぁ。
          デスクトップにダウンロードして、用が済んだら消すなりしかるべきフォルダに移動するなりしてる。

        • by Anonymous Coward

          今までダウンロードしたものは全部残してるけど

        • by Anonymous Coward

          そういえば、ストレージセンサーにダウンロードディレクトリを空にされて大騒ぎしたアホがいたなあ。

      • by Anonymous Coward

        こちらはDLLをダウンロードさせるだけで、どっかのEXEが落ちてきて実行されるのを待つ、って感じ?
        かなり限定的なケースな気もするが、みんなダウンロードフォルダをどう運用してるんだろう。

        # 自分はMacなので関係ない話。

      • by Anonymous Coward

        それはブラウザがDLLファイルのダウンロード時には常に保存先指定ダイアログを出してダウンロードフォルダ内が指定されたら警告メッセージを出すようにでもすれば済む話では

        • by Anonymous Coward

          いや、デフォルトのダウンロードフォルダを選択したら警告って、それはそれでだめなような。

    • by Anonymous Coward

      アプリケーションやインストーラーがDLLのハッシュ値を調べて改ざんされてないか診断する機構は付いていたほうがいいよね
      もしくはアプリケーション自体が改ざんされてないかハッシュ値などで自己診断なりOS側で判断する機能が付いているとさらにいいよね

      • ハッシュ値なんて Windows Update でバイナリが差し替えられたら変わっちゃうんだから確認のしようがない。使い物にならない。
        少なくとも Vista の時点で既にコード署名があるんだから、そちらを確認れば済む話。

        ところが、Windows はシステムのコアコンポーネントですらコード署名されてないバイナリが山のように放置されいる。
        例えば、explorer.exe は Win10 は署名されてるけど、Win7 は署名がないし、cmd.exe は Win10 も 7 も署名がない。

        システムコンポーネントの改竄を容易に確認する手段を用意しておきながら、まじめに運用する気がないとか、正直 Microsoft の神経はおかしいとしか言いようがない。
        コード署名のないバイナリの実行をすべて禁止せよとは言わないが、Microsoft 公式のバイナリにコード署名がないのはセキュリティに対する怠慢以外の何物でもないだろう。

        --
        uxi
        • by Anonymous Coward

          署名カタログも知らないくせにcmd.exeに署名がないとか言ってる阿保

          • by uxi (5376) on 2019年03月04日 19時57分 (#3574616)

            ごめんなさい。前言撤回します。私が阿呆でした。
            explorer.exe から cmd.exe のプロパティ見てもデジタル署名付いてないし、
            sigverif.exe も cmd.exe を検証してくれないけど、
            PowerShell から
            Get-AuthenticodeSignature パス名
            ってやると検証出来るんだね。

            でも肝心の署名カタログの場所が分からなかったので、調べる方法知ってたら阿保な私に教えてください。

            --
            uxi
            • by Anonymous Coward

              調べる方法:ググる

              賢くなれるチャンス!

              • by uxi (5376) on 2019年03月05日 10時16分 (#3574918)

                この文章を読んで、調べて分からなかったから聞いているのが分からないとか相当だなと思う。

                #3574472 [srad.jp] は、口は悪いが、要点となる情報をこの上なく簡潔に与えてくれている一方で、
                #3574648 [srad.jp] はからは、何一つとして学ぶものがない。

                人に賢くなれるチャンスとかボケたこと抜かす前にまず自分が文章の読解力を身に付けるべきだろう。
                人に何ら有益な情報を提供出来ないくせに、便乗してマウントを取りたいだけの無能なクズは黙ってろと思うね。

                --
                uxi
              • by uxi (5376) on 2019年03月07日 14時39分 (#3576766)

                署名カタログ自体は *.cat で検索すれば簡単に見つかるよ。
                そこ以外にも WinSxS、System32\DriverStore、servicing\Packages、SoftwareDistribution\Download 以下から大量に見つかる。

                問題はフォルダの場所ではなくて、署名カタログと検証対象のファイルの対応を見つける方法。
                少なくとも私の検索能力では見つけられなかった。

                sigverif.exe で検証されたファイルは、ログを見ればある程度署名カタログを絞り込めるけど、署名ファイルのファイル名が長いと表示桁数をオーバーしてしまうため特定出来ないし、任意のファイルを検証することも出来ないので検証対象になってないファイル(例えば cmd.exe)に対応する署名ファイルは見つけることが出来ない。
                PowerShell の Get-AuthenticodeSignature は任意のファイルを検証出来るけど、これも署名ファイルとの対応を表示する方法がない。

                Windows 本体に含まれない機能を使ってよければ、
                Windows SDK 入れることで
                signtool.exe verify /a /v 検証対象のファイル
                とすれば検証対象のファイルに対応する署名カタログを見つけることは出来る。
                しかし、この逆で署名カタログから検証対象のファイルを見つける方法は見つけられなかった。

                署名カタログにはハッシュ値のみ記録されているので、
                署名カタログ内のハッシュ値を一覧するコマンドさえあればスクリプトを組めそうだけど、
                ハッシュ値を一覧するコマンドも見つけられなかった。

                更に、よくわからないのは署名カタログのハッシュ値。
                例えば、C:\Windows\System32\cmd.exe は
                signtool.exe verify /a /v /hash SHA256 C:\Windows\System32\cmd.exe
                とすると
                File is signed in catalog: C:\WINDOWS\system32\CatRoot\{F750E6C3-38EE-11D1-85E5-00C04FC295EE}\Microsoft-Windows-Client-Features-Package0011~31bf3856ad364e35~amd64~~10.0.17134.1.cat
                Hash of file (sha256): 9F9B267DA808B959A4CD4D5B8FEAC68C4888B932789D26BECB2D65C452273D4B
                という結果が得られる。
                これは、上記の署名カタログを開いてセキュリティカタログのタブを確認してみると確かにこのハッシュ値が見つかる。
                ところが、
                Get-FileHash -Algorithm SHA256 C:\Windows\System32\cmd.exe
                の結果は
                9A7C58BD98D70631AA1473F7B57B426DB367D72429A5455B433A05EE251F3236
                なのでハッシュが一致しない。
                ということは恐らく SALT が付いてるはずなんだけど、これに関するドキュメントも見つけられなかった。

                少なくとも署名カタログについては、私は自分の無知を詫びて阿呆であることを認めたよね?
                口だけならなんとでも言えるけど、無いことの証明はできないだから、是非とも有ることを示して、私の無能を証明してもらいたいのだ。

                --
                uxi
              • by uxi (5376) on 2019年03月07日 14時46分 (#3576770)

                私は基本的に質問しないんだけど、君らがマウント取ってくるから、ボコってくれって言ってるだけなんだが?
                ちゃんとボコってくれたのは、最初の#3574472 [srad.jp]だけで他は情報量ゼロじゃん?

                こっちは調べた上で白旗上げてるんだ。そして調べた結果は還元している。
                知ったかはお呼びじゃないんだ。
                ちゃんと、エビデンスでボコってくれ。

                --
                uxi
      • by Anonymous Coward

        アプリケーションやインストーラーがDLLのハッシュ値を調べて改ざんされてないか診断する機構は付いていたほうがいいよね

        改ざんされてないか診断する機構を実装したDLLが改ざんされていないことを以下無限ループ

  • by Anonymous Coward on 2019年03月04日 15時31分 (#3574376)

    昔はDLLのバージョン違いを気にしなくて済む良い方法とされていたのに。

    ここに返信
    • by Anonymous Coward on 2019年03月04日 16時01分 (#3574398)

      EXEそれぞれが自分用のDLLを持つって
      ナニその本来転倒

    • by Anonymous Coward

      今だってやってますよ
      Microsoft OneDriveっていうソフトなんですけど

    • by Anonymous Coward

      今このスレには二種類の人がいる。
      ・なぜこれが脆弱性になるのかわからない人
      ・脆弱性があるとはこれだからMSはって人

    • by Anonymous Coward

      macOSみたいにアプリをパッケージ構造にしとけばDLL地獄とこの類の脆弱性を同時に解決出来るんだが、なんでWindowsではそっちの方向に動かなかったんだろう。

      • by Anonymous Coward

        windows10のストアアプリがそれかと
        ストアはろくなソフト無く酷いが
        パッケージ形式だけは良いのよね

        • by Anonymous Coward

          ユーザープロファイルごとにインストールするのやめてほしい
          一時的にクリーンなプロファイルが必要でテスト用のアカウント作ってログオンすると
          ガリガリガリガリインストールされて甚だ迷惑

  • by Anonymous Coward on 2019年03月04日 16時06分 (#3574404)
    早くダイアログの表記事項とアプリケーションの動作に関連性が全く無い、穴だらけの仕様から無くすべきだ。
    管理者権限の譲渡が使用者に知らされない状況で譲渡可能な仕様がある事自体が間違いだし。
    ここに返信
    • by Anonymous Coward

      「だじゃく性」って流行ってんの?

  • by Anonymous Coward on 2019年03月04日 16時10分 (#3574407)

    MSが攻撃シナリオと対策のドキュメントを公開しただけで
    修正パッチの類は無かったような

    ここに返信
  • by Anonymous Coward on 2019年03月04日 17時11分 (#3574467)

    基本的にこれの問題点はインストーラやアンインストーラが
    TEMP ディレクトリやダウンロードディレクトリで実行されることが多くて、
    そこに怪しい DLL を置かれるとまずいという話だと思うんですけど、違う?

    Administrators 権限でプログラム実行している限り
    上記以外のディレクトリでもヤバイ気がするし
    regstry いじられるとどこにおいてもヤバイんだけど
    やっぱり怪しいDLLを設置されてしまうという段階でNGな気がする。

    ここに返信
    • by Anonymous Coward

      TEMPの中はひどいよね。各種インストーラーが適当に展開して放置した残骸でいっぱい

  • by Anonymous Coward on 2019年03月05日 0時26分 (#3574763)

    フックして横やり入れるDLLとかあると思うんだけど、アレの挙動もこの問題の一部って理解でいいのかな

    ここに返信
typodupeerror

アレゲはアレゲを呼ぶ -- ある傍観者

読み込み中...