Unity プラットフォーム保護: 開発者向け修正ガイド

概要

Unity 2017.1 以降 でビルドされた Android、Windows、macOS、Linux 向けのゲームとアプリケーションに影響するセキュリティの脆弱性が確認されました。この脆弱性が悪用された証拠はなく、ユーザーまたはお客様に対する影響も発生していません。この脆弱性は、Unity アプリケーションでネイティブとマネージドの拡張をロードして実行することを可能にするコマンドライン引数に起因します。脆弱性がターゲットプラットフォームにどのように影響する可能性があるかを理解するには、プラットフォーム別テクニカルノート を参照してください。

重要: プロジェクトが 2017 から現在までのパッチ適用済みリリースのいずれかの Unity バージョンでビルドされた場合は、影響を受ける可能性があります。影響を受けるプロジェクトをもつすべての開発者が、対処する必要があります。

修正のオプション

Unity 2017.1 以降を使用して Windows、Android または macOS 用にゲームやアプリケーションを開発しリリースしている場合は、対処する必要があります。この脆弱性が Linux に与えるリスクは低いため、開発者は Unity のパッチ適用済みバージョンに更新することで、十分に保護されます。

Unity は 2019.1 以降のエディターのパッチ適用済みバージョンをリリースしました。アプリケーションが Unity 2019 以降でビルドされている場合、パッチ適用済みの Unity エディターを使用してアプリケーションをリビルドすることを推奨します。ただし、"ビルド済みアプリケーションにパッチを適用する" セクションで説明するように、プロジェクトをソースからリビルドできない場合や、2017/2018 バージョンでビルドを行った場合のために、パッチ適用ツールも用意しています。

1.パッチ適用済みの Unity エディターを使用してリビルドする (推奨)

影響を受ける各 Unity エディターバージョンのパッチ適用済みリリースをダウンロードできます。パッチ適用済みの Unity エディターをダウンロードして、アプリケーションのリビルドを行えます。

パッチを適用した Unity エディターバージョンを使用してアプリケーションをリビルドする手順は以下の通りです。

1. アプリケーションのビルドに使用した Unity バージョン (例: Unity 6.1、Unity 2022.2 など) に一致する Unity エディターの最新リリースを ダウンロード します。
2. Unity Hub
3. Unity ダウンロードアーカイブ
4. 更新したエディターで プロジェクトを開きます。
5. アプリケーションを リビルド し、再テスト します。
6. 配信チャンネルに 再度公開 します。

2.ビルド済みアプリケーションにパッチを適用する

ソースからリビルドすることができない (またはアプリケーションのリビルド中に修正プログラムを展開したい) 場合は、Unity アプリケーションパッチャー を使用して既存の Android、Windows、または macOS ビルドを更新します。

Unity アプリケーションパッチャーの使用方法は以下の通りです。

1. Unity アプリケーションパッチャーをダウンロードします。 ツールを入手
2. ライセンス契約、利用ガイド、詳細オプションを確認します。詳しくは、パッチャーのドキュメントを参照してください。
3. 既存のビルドに対して パッチャーツールを実行 します。(Windows または macOS 用ビルドへパッチを適用するにはインターネット接続が必要です。)
4. パッチ適用後に アプリケーションをテスト し、機能することを確認します。
5. 配信チャンネルに 再度公開 します。

Unity アプリケーションパッチャーが異なるプラットフォームに対してどのように機能するかを理解するには、プラットフォーム別テクニカルノートを参照してください。

注意:

• パッチャーは、一部の改ざん防止またはチート対策ソリューションによって保護されているビルドとは互換性がありません。
• パッチ適用後は必ず 、アプリケーションの整合性と機能性を検証してください。
• Unity アプリケーションパッチャーツールは Unity 6.0 で開発されており、このツールを実行するには、対応する Windows または macOS のシステム要件 が適用されます。

プラットフォーム別テクニカルノート

以下のセクションでは、セキュリティの脆弱性が Android、Windows、macOS 用アプリケーションにどのように影響するか、Unity アプリケーションパッチャーが各プラットフォームでどのように動作するかについて説明します。

リリースストリームの一部のベータとパッチリリースが影響を受ける可能性があります。正式リリース以外のリリースで配信した場合は、影響を受けるバージョンの完全なリスト を参照してください。

注意: Google、Meta、Microsoft では、プラットフォームのセキュリティをさらに強化するために、OSレベルの対策も導入しています。それでも、Unity アプリケーションを完全に安全にするためには、パッチを適用するかリビルドする必要があります。

Android

注意: この脆弱性が悪用された証拠はなく、ユーザーまたはお客様に対する影響も発生していません。

Android では、Unity アプリケーションが Unity 2019.1 以降を使ってビルドされた 場合は、特別な権限や設定に関係なく 対処する必要があります。

さらに、アプリケーションが Unity 2017 以降でビルドされ、かつ Mono ランタイム (32 ビットのみ) を使用している場合は、脆弱である可能性があります。正式リリース以外のリリースで配信した場合は、影響を受けるバージョンの完全なリスト を参照してください。

• Android では、一般にアプリケーションは互いに分離されており、脆弱性や誤った設定を悪用しなければ、通常アプリケーション間でコードのインジェクションはできません。
• この脆弱性が原因で、特別に細工されたインテントとコマンドライン引数 xrsdk-pre-init-library、または Mono でビルドされた 32 ビットアプリケーションの overrideMonoSearchPath を使用して、デバイス上の他のアプリケーションが Unity アプリケーションを起動し、悪意のあるネイティブライブラリの挿入を許可する可能性があります。
• Android アプリケーションは、コマンドライン引数 datafolder や monoProfiler に対して 脆弱ではありません。

Android での破壊的変更

Android でこの脆弱性に対処することに関連した破壊的変更はありません。

Android 用 Unity アプリケーションパッチャー

Android では、Unity アプリケーションパッチャーは APK または AAB を解凍し、脆弱なコードパスをブロックするために libunity.so と boot.config をローカルで変更してから、APK または AAB の再パッケージと再署名を行います。

Unity アプリケーションパッチャーは、脆弱なコードパスをブロックするために、libunity.so と boot.config の両方で 文字列 xrsdk-pre-init-library を 8rsdk-pre-init-library に変更します。このようにすると、引数の解析方法により、それをコマンドライン引数 (または Android の Intent Extra) として使用できなくなります。boot.config 設定としては引き続き機能するため、boot.config ファイル内でのすべての使用に対してもパッチが適用されます。

また、Unity アプリケーションパッチャーは、libunity.so 内の文字列 overrideMonoSearchPath の先頭文字を無効な Unicode 文字 0xC0 に置き換えることによって Mono を使用した 32 ビットビルドの引数 overrideMonoSearchPath を使えなくします。

Windows

注意: この脆弱性が悪用された証拠はなく、ユーザーまたはお客様に対する影響も発生していません。

Windows のようなデスクトッププラットフォームでは、実行中のプロセスにコードを挿入するさまざまな方法があります。ただし、それらの方法は通常、システムの特権レベルとセキュリティ境界によって制限されています。ほとんどの場合、自身で開始したプロセスにのみコードを挿入することができ、それを行っても、自身のプロセスがすでに持っている能力以上の追加能力は許可されません。

ただし、この状況では、Unity アプリケーションが カスタム URL スキーマハンドラーとして登録されている場合、特権昇格に対して 脆弱である可能性があります。この登録は、自身のアプリケーションによって実行される場合もあれば (例えば、ディープリンクやブラウザーからの起動をサポートするため)、他のアプリケーション (サードパーティのゲームランチャーやストアフロントなど) によって実行される場合もあります。

サードパーティのアプリケーションによって自身のアプリケーションがスキーマハンドラーとして登録されることを防ぐ方法はなく、それを検出する方法さえないため、Unity では、予防策として Unity のすべての Windows 向けアプリケーションにパッチを適用すること を推奨します。

• 登録された URL スキームを使用すると、より低い整合性レベル (サンドボックス化されたプロセスや権限の低いプロセスなど) でコードを実行している攻撃者が、Unity のこの脆弱性を悪用してアプリケーションを起動し、DLL を挿入して、通常よりも高い権限で攻撃者が用意したコードをアプリケーションに実行させることができるようになります。
• インジェクションは、前述した脆弱なコマンドライン引数のいずれかを介して発生する可能性があります。

Windows での破壊的変更

• アプリケーションで データフォルダー を再配置するためにコマンドライン引数 -datafolder を使用する場合、代わりにカスタムデータフォルダーを 2 番目の引数として UnityMain 関数に渡す必要があります。
• int UnityMain(HINSTANCE hInst, LPCWSTR customDataFolder, LPWSTR szCmdLine, int nCmdShow)
• アプリケーションで、XR プロバイダーの切り替えのために xrsdk-pre-init-library をコマンドライン引数として使用した場合は、OpenXR を使用するか、個別のビルドを提供することを推奨します。
• overrideMonoSearchPath は削除されます。個別のアプリケーションをビルドするか、すべてのスクリプトを同じビルドに入れることを推奨します。

Windows 用 Unity アプリケーションパッチャー

Windows 向けビルドの場合、Unity アプリケーションパッチャーツールは、Unity のバージョンに適したパッチ適用済みの UnityPlayer.dll (または、Unity 2017.1 でビルドされたアプリケーションの場合は .exe) をダウンロードし、ビルドされたアプリケーションの脆弱なファイルの代わりとして置き換えます。

注意: Unity アプリケーションパッチャーは、Unity のサーバーからパッチ適用済みのバイナリを取得し、受け取る前にテストと検証が行われたことを確認します。

UnityPlayer.dll は、脆弱性のあるコマンドラインパラメーターをスキップするように修正されました。

xrsdk-pre-init-library は、boot.config 設定として引き続き機能します。

重要: アプリケーションでコマンドライン引数 -datafolder を使用して データフォルダー (Unity 2022.2 で導入) を再配置する場合、"Windows での破壊的変更" セクションに示されている新しいパターンを採用する必要があります。

macOS

注意: この脆弱性が悪用された証拠はなく、ユーザーまたはお客様に対する影響も発生していません。

macOS では、カメラやユーザーのドキュメントフォルダーへのアクセスなど、多くの権限がアプリケーションごとに管理されています。これらの権限の不正使用を防ぐため、macOS には Hardened Runtime 機能を含む複数のメカニズムが実装されています。デフォルトでは、Hardened Runtime を使用してビルドされたアプリケーションは、署名されていないコードや、異なる署名を持つコードをロードすることができません。

Hardened Runtime を使用することは公証の要件であり、Mac App Store 以外で配布する場合に推奨されます。Mac App Store での配布の場合、厳密にはそれは必須ではなく、アプリケーションは少なくとも App Sandbox を使用する必要があります。App Sandbox により、システム上でアプリケーションがアクセスできる対象が制限されますが、アプリケーション自体のプロセスへのコードインジェクションは防げません。Hardened Runtime を使用しなくても、DYLD_INSERT_LIBRARIES などの手法がすでに可能であるため、この脆弱性によってその環境での悪用の可能性が高まることはありません。それでも Unity では、影響を受けるすべての macOS アプリケーションに対してパッチ適用またはリビルドを行い、脆弱性のあるコードパスを除去し、後で Hardened Runtime が有効化された場合や、Mac App Store 以外での配布に移行する場合でも、安全な状態を維持することをお勧めします。

アプリケーションが Unity 2017.1 以降 (Mono スクリプティングバックエンドを使用) または Unity 2019.1 以降 (任意のスクリプティングバックエンドを使用) でビルドされていて、Hardened Runtime とともに構築され、かつコードインジェクション保護を弱める 特定のランタイム例外 が有効になっている場合は、対処が必要です。アプリケーションを脆弱にする例外は以下の通りです。

• ライブラリ検証を無効にする (com.apple.security.cs.disable-library-validation) — 署名されていない、または異なる署名を持つプラグインやフレームワークをロードすることを可能にします。これにより、引数 xrsdk-pre-init-library または datafolder の使用時に、悪意のあるネイティブの .dylib ファイルがロードされる可能性があります。
• JIT コンパイルされたコードの実行を許可する (com.apple.security.cs.allow-jit) — 引数 datafolder または overrideMonoSearchPath が悪用されると、悪意のあるマネージコードの実行が可能になる場合があります。この例外を許可することは、Mono スクリプトバックエンドのすべての使用の条件であることに注意してください。
• 署名されていない実行可能メモリを許可する (com.apple.security.cs.allow-unsigned-executable-memory) — 同様に、引数 datafolder が悪用されると、悪意のあるマネージコードの実行が可能になることがあります。
• アプリケーションが Unity 2023.2 以降でビルドされている場合。これらの例外がなくても datafolder が悪用される可能性があります。

Hardened Runtime は通常、一般的なコードインジェクション方法をブロックし、そのような攻撃からアプリケーションを保護します。影響される Unity アプリケーションで上記のいずれかの例外が有効になっている場合、攻撃者はコマンドライン引数 xrsdk-pre-init-library、datafolder または overrideMonoSearchPath を介してコードを挿入できる可能性があります。

これにより、攻撃者がプロセス内に悪意のある .dylib またはマネージアセンブリを挿入できる可能性があります。アプリケーション自体にない権限へのアクセスを許可することはできません。

macOS での破壊的変更

• アプリケーションで データフォルダー を再配置するために、コマンドライン引数 -datafolder を使用する場合、代わりにシンボリックリンクを使用することを推奨します。
• overrideMonoSearchPath は削除されます。個別のアプリケーションをビルドするか、すべてのスクリプトを同じビルドに入れることを推奨します。

macOS 用 Unity アプリケーションパッチャー

macOS プロジェクトの場合、Unity アプリケーションパッチャーツールは、Unity のバージョンに適したパッチ適用済みの UnityPlayer.dylib をダウンロードし、ビルド済みのアプリケーションの脆弱なファイルと置き換えます。boot.config 変数 xrsdk-pre-init-library が 8rsdk-pre-init-library に変更されました。これにより、コマンドライン引数として使用できなくなります。引数の解析方法が理由です。引き続き boot.config 設定として機能するため、boot.config 内でのすべての使用に対してもパッチを適用します。

Unity アプリケーションパッチャー 1.3 の新しい動作

• パッチャーは、Hardened Runtime またはエンタイトルメントに関係なく、すべての macOS アプリケーションの UnityPlayer.dylib にパッチを適用します。
• com.apple.security.cs.disable-library-validation エンタイトルメントなしに Hardened Runtime を使用するアプリケーションには、パッチ適用後にパッチャーによる署名は行われません。
• パッチャーがアプリケーションに署名しない場合、手動で署名しないと実行できないという警告が表示されます。
• この変更により、パッチが適用されたアプリケーションは、開発者が明示的に再署名しない限り、セキュリティが弱まった状態で実行されなくなります。

アプリケーションがパッチャーによって署名されると、ローカルテストにアドホック署名が使用されます。アプリケーションが以前に開発者 ID 証明書で署名され、Apple による公証を得ている場合、パッチ処理によってその公証は無効化されます。ソフトウェア配布に関する Apple の推奨事項 に従って、リリース前に再署名と再公証を行ってください。

Linux

注意: この脆弱性が悪用された証拠はなく、ユーザーまたはお客様に対する影響も発生していません。

Linux では、Unity の脆弱なコマンドライン引数は LD_PRELOAD メカニズムと同様に機能します。Linux の標準的なセキュリティモデルのもとでは、これらの引数は権限の境界を超えることはなく、したがって、LD_PRELOAD で起こりうるリスクに比べて追加のリスクをもたらすことはありません。

AppArmor、Bubblewrap、Firejail、SELinux などの環境では、制限された処理がその制限を超えて Unity アプリケーションを起動できる場合、すでに任意のコード実行が可能であり、この脆弱性によってさらにリスクが増加することはありません。特定の SELinux または AppArmor の設定では、一般的なインジェクション方法 (LD_PRELOAD、ptrace) はブロックされる可能性がありますが、任意の引数を使用して Unity を起動することは可能です。この場合、脆弱な引数がポリシーの制限を回避し、有効な攻撃経路となる可能性があります。

軽減策

リスクプロファイルが低いことから、Unity アプリケーションパッチャーの Linux バージョンはリリースされて いません。必要に応じて、特にアクセス制御ポリシーが厳格な環境では、脆弱なコードパスを取り除くために、パッチ適用済みの Unity エディターを使用して Linux アプリケーションをリビルドしてください。

その他のプラットフォーム (iOS、コンソールなど)

iOS を含む他のすべての Unity が対応するプラットフォームでは、この脆弱性が悪用可能であることを示す報告はありません。セキュリティを最大限に高めるために、パッチを適用した最新の Unity エディターを使用してアプリケーションをリビルドすることを推奨します。

リソース

• パッチ適用済み Unity エディターをダウンロード
• Unity アプリケーションパッチャーをダウンロード
• Unity セキュリティアドバイザリー
• CVE の詳細
• Unity Support Services

皆さんのアプリケーションを保護しユーザーを保護するために、対処が必要です。ご質問やサポートについては、Unityサポート までご連絡ください。