Unity を検索

エディターにおける Unity パッケージマネージャーの依存関係かく乱およびアセットバンドルのセキュリティについて

2021年6月9日 カテゴリ: Engine & platform | 8 分 で読めます
取り上げているトピック
シェア

Is this article helpful for you?

Thank you for your feedback!

セキュリティは、あらゆる種類のソフトウェアの開発において重要な要素であり、それは Unity プロジェクトでも例外ではありません。Unity の Responsible Disclosure(責任ある開示)ポリシーの一環として、Unity 環境で問題を起こす可能性のある脆弱性や実際に起きている問題について、外部の研究者と緊密に連携して対処しています。最近、私たちは IncludeSecurity のセキュリティ研究者たちと連絡を取っています。Unity の開発者が陥る可能性がある、安全ではない開発プラクティスについて、IncludeSecurity のチームと協力して情報を共有したいと考えています。このブログ記事では、「依存関係かく乱」と「アセットバンドルのセキュリティ」の 2 つのトピックを取り上げます。

依存関係かく乱

サプライチェーンセキュリティの脆弱性は、すべての Unity 開発者がゲームを作る際に考慮しなければならない深刻な問題です。

これらの脆弱性の 1 つに、依存関係かく乱(dependency confusion)として知られているものがあります。依存関係かく乱は、攻撃者が開発者の環境やツールに影響を与え、悪意のあるパッケージをダウンロードさせることで発生します。この攻撃は、一部のパッケージマネージャーやプライベートリポジトリに見られる、安全でないデフォルトの動作を利用しています。 

Unity エディターには、独自のパッケージマネージャーである Unity パッケージマネージャーが搭載されており、これが NPM レジストリ経由でのパッケージの取得をサポートしています。これは、プライベートな NPM レジストリを使用している Unity 開発者は、先ほど紹介した依存関係かく乱の脆弱性がもたらすものと同じリスクに直面する可能性があることを意味します。

例えば、プライベートレジストリと npm.io のようなパブリックレジストリを利用する Unity プロジェクトを考えてみましょう。開発者は、標準的な開発プラクティスとして、パッケージ A をプライベートレジストリにアップロードすることができます。パッケージマネージャーのスコープが広すぎる場合や、プライベートレジストリがパブリックレジストリをプロキシしている場合、攻撃者は、より大きなバージョン番号を持つ悪意のあるパッケージ A をパブリックリポジトリにアップロードすることができます。この時、悪意のあるパッケージの方がバージョン番号が大きいため、このパッケージが Unity プロジェクトにダウンロードされてしまい、依存関係の読み込み時に開発者のマシン、または Unity プロジェクトを実行しているすべてのマシンでコードが実行されてしまいます。 

Unity エディターでプライベートパッケージを使用し、パブリックリポジトリをプロキシするプライベートレジストリを使用することで、開発者は依存関係かく乱攻撃に対して脆弱になる可能性があります。この攻撃は、IncludeSecurity がこちらの記事(英語)で解説しているものです。

NOTE: Unity does not recommend using public registries, such as the NPM public registry. Many packages in these public repositories are not supported in the Unity editor, and some features are not supported by the Unity Package Manager.

By using private packages in the Unity editor with a private registry that proxies a public repository, a developer may leave themselves vulnerable to a dependency confusion attack. This attack is what IncludeSecurity describes in their article here.

重要: Unity パッケージマネージャーのデフォルトの設定では、依存関係かく乱の脆弱性はありません。この記事の続きで解説するように、開発者が manifest.json ファイルを編集する必要がある時、そこで脆弱性を作り込んでしまう場合があります。脆弱性を作り込むようなローカルパッケージの設定の変更とはどのようなものか、また、そのような脆弱性を緩和するためにどのように設定を更新すればよいかについては、「緩和策」の項を参照してください。大多数の開発者は心配する必要はありませんが、それでも自社のコードベースと顧客を安全な状態に保つためにどうすればよいかを理解するために、この記事で解説するような内容には親しんでおくべきです。

以下に示す脆弱性のある設定例では、唯一のスコープ付きレジストリとしてプロキシされたレジストリを使い、プライベートレジストリとパブリック NPM レジストリからパッケージを取得するようになっています。スコープ内で定義されたパッケージは、同じレジストリを共有しているため、悪意のある攻撃者が、より高いバージョンの「com.private.vulnerable.package」を NPM レジストリにアップロードすることで、開発者がパッケージをアップデートした際に、悪意のあるパッケージがユーザーの環境にダウンロードされてしまう可能性があります。

脆弱性のある設定例:

緩和策

NPM のスコープ付きパッケージなどの典型的な緩和策は、Unity パッケージマネージャーではサポートされていません。代わりに、スコープ付きレジストリを使用すると、このタイプの問題を防ぐことができます。スコープ付きレジストリのスコープにパッケージを明示的に定義することで、パッケージのソースはスコープ付きレジストリの設定ファイルで定義されたものに厳密に固定されます。 

プライベートレジストリが NPM もプロキシしている場合、Unity パッケージマネージャーは、プライベートに公開されたパッケージとパブリックに公開されたパッケージを区別できないことに注意してください。この緩和策はレジストリレベルで適用する必要がありますが、これについては IncludeSecurity が解説記事(英語)を出しています。

以下に示す設定例では、レジストリをそれぞれのスコープ付きレジストリブロックに分割し、各レジストリで使用されるパッケージを明示的に定義することで、脆弱性のある設定を修正しています。つまり、悪意のあるパッケージは、たとえそのパッケージがパブリックなレジストリ上でより高いバージョンで公開されていたとしても、ユーザーの環境にはダウンロードされないということです。

安全な設定例:

アセットバンドルのセキュリティ

アセットバンドルは Unity エンジンでよく使われる機能で、標準化されたフォーマットでアセットを配布するために使用されます。一般的には、ユーザーがプレイしているゲームへの追加のアセットを必要なときにダウンロードできるようにして、最初にゲームをプレイする時にダウンロードするデータ量を削減するために使用されます。Unity プロジェクトの改造やカスタマイズを行うためのカスタムコンテンツを配布するためにアセットバンドルが使われることもあります。 

アセットバンドルを使用する際には、信頼できるソースからダウンロードすることが重要です。アセットバンドルには実行可能なコードを含めることはできませんが、特別に細工されたアセットバンドルファイルにより、攻撃者がゲームコードまたは Unity ランタイムの脆弱性を悪用できる可能性があることを IncludeSecurity は発見しました。

緩和策

上記の理由より、インターネットからダウンロードされたアセットバンドルは、インターネットからダウンロードされた他のソフトウェアと同様に扱うべきです。

  • 信頼できるソースからのアセットバンドルのみを使用するようにしてください。 
  • アセットバンドルが TLS など、安全な通信手段で送信されるようにしてください。

結論

コンテンツ制作者が使うツールやサービスは素晴らしい体験を生み出すために不可欠のものですが、そこにはリスクも潜んでいます。自分の開発者ツールチェーンが安全で適切に設定されているかの確認のために時間をとることは、自分自身とユーザーの両方にセキュリティ上の恩恵をもたらします。

この記事のトピックに関連する記事

Unity Security に関する情報や、Unity からのすべてのセキュリティに関するアドバイザリはこちらのページでご覧になれます。

2021年6月9日 カテゴリ: Engine & platform | 8 分 で読めます

Is this article helpful for you?

Thank you for your feedback!

取り上げているトピック