【ITニュース解説】msiexec repair mode resolves a binary path from a directory an installer wrote to

Windows環境でソフトウェアをインストールする際、その裏側で重要な役割を果たすのが「Windows Installer」という仕組みだ。このインストーラーは、ソフトウェアのファイル配置やシステムへの登録を管理し、もしインストール済みのソフトウェアに問題が生じた際には、「修復」と呼ばれる機能を使って、失われたり変更されたりしたファイルを元の状態に戻すことができる。この修復機能は、通常は非常に便利で安全なものとして機能するが、実は特定の条件下ではセキュリティ上の問題を引き起こす可能性があることが指摘されている。システムエンジニアを目指す皆さんにとって、この仕組みと潜在的なリスクを理解することは、安全なシステム運用やソフトウェア開発において非常に重要になるだろう。

具体的にどのような問題が起こるのか、そのメカニズムを見てみよう。ソフトウェアの修復を実行する際、Windows Installer（コマンドラインツールとしてはmsiexecとして知られる）は、そのソフトウェアがどのようにインストールされたかを示す「製品データベース」を読み込む。そして、不足している、あるいは破損したコンポーネント（ソフトウェアを構成する個々のファイルや設定など）を復元するために、元のインストールファイルを探し出す。もし、元のインストールメディアが利用できない場合、Windows Installerは、キャッシュされたパッケージデータや、インストール時に記録されたディレクトリなど、信頼できると判断した他の場所からファイルを探そうとする。この時、セキュリティ上の問題が生じる可能性があるのは、インストーラーが記録した「ソース」と呼ばれる元のファイル置き場が、非管理者権限の一般ユーザーでも自由に書き込める場所だった場合だ。インストーラーが、ユーザープロファイル内のような、ユーザーが書き込み可能な場所をコンポーネントのソースとして記録してしまうと、修復時には現在のユーザーが制御できるディレクトリからそのコンポーネントが再構築されてしまうかもしれない。これがセキュリティ上の問題となるのは、そのソフトウェアが「SYSTEM」権限や管理者権限といった高い権限で動作するサービスやタスクを含んでおり、かつ、非特権ユーザーが管理者権限なしでその修復操作をトリガーできる、あるいは修復が実行されるのを待つことができるという三つの条件が揃った場合だ。悪意のあるユーザーが、修復時に利用されるユーザー書き込み可能なディレクトリに、不正なファイルや改ざんされたファイルを配置し、それが高い権限で実行されてしまうというシナリオが考えられる。

このような問題が繰り返し発生する背景には、主に二つの要因がある。一つは「Per-userインストール」と「Per-machineインストール」の違いに関する認識不足だ。Per-machineインストールは、その名の通りコンピューター全体にソフトウェアをインストールする方法で、ファイルやレジストリ設定は通常、管理者権限が必要な共有された場所に配置されるため、修復時のファイル解決パスも管理者権限がなければ操作できない場所になることが多い。一方、Per-userインストールは、特定のユーザープロファイルの中にソフトウェアをインストールする方法で、ユーザープロファイルはユーザーが自由に書き込める場所であるため、必然的にファイルパスもユーザー書き込み可能となる。多くのソフトウェアはPer-machineインストールを前提とするが、中にはPer-userインストールもサポートするものがある。この際にインストーラーが注意深く設計されていないと、本来Per-machineでインストールされ、SYSTEM権限で動作すべきサービスが、誤ってPer-userパスに登録されたコンポーネントを持つことになってしまう場合がある。もう一つの要因は「ソースリスト」だ。インストーラーは、ソフトウェアがインストールされた時に、どこからファイルが提供されたかというソースの場所を記録する。これには、ネットワーク共有やローカルディレクトリなどが含まれる。もし、この記録されたソースディレクトリがインストール後も非管理者によって書き込み可能なままだと、そのソフトウェアの寿命が尽きるまで、修復操作の有効なソース候補として残り続けてしまう。これにより、悪意のあるユーザーがその共有ディレクトリに不正なファイルを配置し、修復時にそれが利用される可能性が生じる。

システムエンジニアとして、このような潜在的な脆弱性を見つけるためには、いくつかのポイントを確認する必要がある。まず、対象となる製品がSYSTEM権限で動作するサービスやスケジュールされたタスクをインストールするかどうかを確認する。もしそうであれば、それは潜在的なリスクの兆候となる。次に、インストールされたコンポーネントの登録パスを詳しく調べる。例えば、コンピューター全体にインストールされるべき製品が、ユーザープロファイルの下にあるインストールディレクトリにファイルを置いている場合は、その理由を深く掘り下げる価値がある。これは、Per-machineインストールであるにもかかわらず、Per-userのようなパスにコンポーネントが登録されている可能性を示唆するからだ。さらに、管理者権限なしで製品の修復がトリガーできるかどうかも重要な確認点だ。一般ユーザーは、自分のコンテキストでインストールされた製品の修復を通常は開始できるため、これが高い権限で実行されるサービスと組み合わされると問題となる。最後に、インストール時に記録されたソースディレクトリがまだ存在するか、そして誰がそのディレクトリに書き込む権限を持っているかを確認する。これらの四つの確認は、特別なエクスプロイト手法を使うことなく、通常のシステム設定レビューを通じて行うことができる。

このようなリスクを減らし、よりセキュアなシステムを構築するためには、いくつかの対策を講じるべきだ。まず、サービスをインストールするような製品に関しては、Per-machineインストールを優先し、インストーラーが意図通りに機能したかどうかをデプロイ後に実際にパスを確認して検証することが重要だ。インストーラーのフラグが正しく設定されたと仮定するだけでなく、実際にインストール後の状態を確認する習慣をつけよう。次に、インストールが完了した後、記録されたソースディレクトリを監査することが必須だ。もし、デプロイメントに使われた共有フォルダが、開発チームや一般ユーザーに書き込み可能なまま放置されている場合、それは修復操作に対して永続的な脆弱性の源となってしまう。このような共有は、必要な時だけアクセスを許可し、それ以外は厳しく制限すべきだ。また、修復操作の呼び出しパターンにも注意を払う必要がある。Windowsのイベントログなどには修復操作が記録されるため、メンテナンス期間外にサービスを伴う製品の予期せぬ修復が実行された場合は、それが潜在的なセキュリティインシデントの兆候である可能性がある。最後に、ベンダーから提供されるアップデートが、このソース解決の動作を変更する内容を含んでいる場合は、そのアップデートを速やかに適用し、ただ助言のタイトルを読むだけでなく、上述の四つの条件を再テストすることで実際に修正が適用され、問題が解消されたことを確認することが大切だ。

Windows Installerの修復機能自体は、システムを健全に保つための正当な機能であり、ここで説明したメカニズムもWindowsによって正式に文書化されているものだ。この問題は、Windows Installerの機能自体のバグではなく、特定の製品のコンポーネント登録方法、インストールスコープの設定、そして記録されたソースディレクトリの権限設定が複合的に絡み合うことで生じる。したがって、特定のベンダーのインストーラーが常に危険であると主張するものではなく、システムを設計・導入する側が、これらの条件を理解し、適切に管理することの重要性を示している。