Cisco Talos が報告した Microsoft Azure Sphere の全脆弱性のまとめ
2020 年 5 月、Microsoft 社が Azure Sphere のバグ発見を目的とした 3 か月間の「Azure Sphere バグ発見コンテスト（ASSRC）」を開始しました。この最初の 3 か月間で Cisco Talos は 16 件の脆弱性を報告しました。その後も断続的に分析を行い、最終的に計 31 件の脆弱性を発見して報告、公表しました。そのうち 2 件は Linux カーネル自体の脆弱性でした。
Cisco Talos では Azure Sphere に関するブログ記事をすでにいくつか公開しています（ブログ記事 1、2、3、4、5 を参照）。今回は調査の締めくくりとして、これまでに発見した脆弱性の概要、攻撃者が脆弱性をエクスプロイトする方法、およびユーザーへの影響をまとめます。また来週は別のブログ記事を公開して、2 件の脆弱性を連鎖的にエクスプロイトすることで任意のカーネルコードを実行できることを説明する予定です。
システム概要
Azure Sphere プラットフォームは、Internet of Things（IoT）アプリケーション セキュリティ専用に設計された、クラウド接続型のカスタム SoC です。内部はさまざまな役割（さまざまなタイプのアプリケーションの実行、セキュリティの適用、暗号化の管理など）を担う複数の ARM コアで構成されています。分析を理解するうえで最も関連性が高いコンポーネントは次のとおりです。
- Normal World：Linux カーネルを実行する OS。実際のユーザーランド環境は存在しません（シェルやユーティリティなどは用意されていません）。init バイナリは application-manager というカスタムアプリケーションで、いくつかのサービスを生成します。これは Cortex A7 コアで実行されます。ユーザーランドが Secmon および Pluton と通信するには ioctl をそれぞれ /dev/security-monitor および /dev/pluton に対して発行します。一方カーネル側は、Secmon との通信では SMC（TrustZone の呼び出しに使用する ARM 命令
）を使用し、Pluton との通信ではメールボックスを使用します（プロセッサ間通信に使用される Linux メールボックス フレームワークを参照）。 - Security Monitor、別名 Secmon（Secure World）：Azure Sphere の ARM TrustZone 実装。SMC を使用して Normal World と通信します。これも Cortex A7 コアで実行されます。
- Pluton：セキュリティ関連の操作を実行する M4 コア。メールボックスを使用して他のコアと通信します。
- リアルタイムコア：開発者が自由に使用できる 2 つの M4 コア。通常、メールボックスを使用して他のコアと通信します。
各コアは DMA バッファを設定して他のコアと情報を共有することができます。
最も重要な機能は Secmon と Pluton が担っています。両者は 1 つの同じ「高特権」エントリのように見えるかもしれませんが、実際には Pluton のほうが特権レベルが高くなっています。Pluton はより機密性の高い操作を担当しており、別のコアで実行されています。たとえばアプリケーションをフラッシュする場合には次の手順が実行されます（この手順は大幅に簡略化しています）。
- Normal World の Azured プロセスがフラッシュするイメージ（サイドロードするかクラウドから取得）を処理し、/dev/security-monitor に対して ioctl を実行してイメージのフラッシュを求める。
- Linux カーネルが DMA バッファを設定してイメージを保存し、SMC を使用して Secmon syscall を呼び出してフラッシュを求める。
- Secmon がイメージを読み取り、Pluton にメールボックスメッセージを送信してイメージの検証を求める。
- Pluton がメッセージを受信し、検証結果を Secmon に返す。
- 検証に成功した場合、Secmon がイメージをフラッシュに書き込む。
以下に、システムの論理チャートを示します。
対外的には、Microsoft 社の Azure Cloud によってサポートされています。セキュリティ更新やアプリケーションの展開を処理し、定期的にデバイスの整合性を検証して Azure Cloud へのアクセスを許可するかどうかを決定すること、それが Azure Sphere の役割です。Azure Sphere の更新と展開には Azure Cloud が使われますが、それとは別に利用者独自のサーバーを利用できるのが特徴です。
利用者は、Azure Sphere クラウドテナント（開発モードの場合はサイドロード）としてグループ化されているデバイスに署名済みアプリケーション（最大約 600KB）をプッシュしますが、デフォルトではごく限られた権限しか付与されません。IP アドレスやホスト名への接続、ディスクへのデータ保存、ソフトウェアの更新の延期といった基本機能を使用するには、各アプリケーションのアプリケーション マニフェスト（app_manifest.json）内で事前に定義しておく必要があります（このマニフェストは、フラッシュされるイメージパッケージに最終的に保存されます）。これらを定義することで、特定の機能を使用するために必要となる特定の Linux グループ ID（GID）や Linux 機能が、アプリケーション（インストールごとに異なる）のユーザー ID（UID）に付与されるようになります。
すべてのシステムアプリケーション（networkd、azcore、azured など）には、必要な機能以外にはアクセスできないように、特定の Linux 機能や Azure Sphere 機能の権限のみが付与されます。これらの Azure Sphere 機能は、通常の Linux 機能と異なる形で保持・処理されます。これにより Azure Sphere 固有の重要なインターフェイスへのアクセスが制限されます。多くの場合、Azure Sphere 機能は、特に /dev/pluton および /dev/security-monitor の ioctl へのアクセスを制限する目的で使用されます。
Normal World のユーザーランド
デバイスにはシェルツール（sh、cat、ps など）が用意されていないので、ユーザーランド側を簡単に分析するために busybox をクロスコンパイルし、アプリとしてインストールして、ネットワークソケットを介して I/O をトンネリングしてみました。
ユーザーランド側にはほとんど何もないことを簡単に見ていきましょう。
実行中のプロセスを表示してみると、このアプリケーションのプロセスしかありません。
アプリケーションのディレクトリ構造は、マニフェスト、app バイナリ、そのバイナリが起動するクロスコンパイルした busybox バイナリからなります。
/ 以下のファイルシステムは次のようになっています。
マウントポイント
Azure Sphere のセキュリティモデル
Microsoft 社は Azure Sphere で実装されている「セキュリティで高度に保護されたデバイスの 7 つの特徴」について詳しく説明しています。デバイスのセキュリティモデルが明確に説明されているわけではありませんが、Azure Sphere は実稼働モードで次のようなセキュリティ保証を提供するものと Cisco Talos では理解しています。
- セキュリティ権限に基づいてコンポーネントを分離（低いものから高いものの順。レベルが低ければ権限も低い）：顧客アプリ、Normal World カーネル、Security Monitor、Pluton、1BL（「最初の」ブートローダ）。
- ハードウェア ファイアウォールによってハードウェアレベルでセキュリティをコンパートメント化：コアが完全に侵害されてもファイアウォールルールによって他のコアとの通信を制限。
- デバイスで実行されるあらゆるコードは（顧客のコードでも Microsoft 社のコードでも）Microsoft 社か顧客によって署名されている必要がある。
- ROP（および同様の手法）を使用すれば任意のロジックをデバイスで実行できることを Microsoft 社は認めている。ただし同社のセキュリティ保証により、未署名のコードをメモリまたはフラッシュに書き込んでそこから実行することはできないようになっている。
- デバイスの ID はスプーフィングできない（デバイスごとの秘密キーがハードウェアに保存されており、ハードウェアの暗号化プロセッサによって暗号化操作が実行される）。
- リモート構成証明によって、デバイスで実行されるコードが改ざんされていないことが保証される。
- セキュリティが自動更新される。
- デバイスは古い（脆弱な）バージョンにダウングレードできない。
攻撃ベクトル
顧客は署名済みアプリケーションを Azure Sphere デバイスに展開できます。これが分析の出発点となりました。
Cisco Talos が発見したすべての脆弱性は、（Normal World 側の）顧客アプリケーションが侵害されて（ROP によって）コード実行が可能になっているものと仮定しています。
この段階から権限を昇格するには、次のようなさまざまな道筋が考えられます。
- Linux 下での純粋な Return-Oriented Program（ROP）以外で、未署名のコードを実行する。
- アプリケーション マニフェストに記載されているもの以外で権限を昇格する（例：ユーザー ID の変更、バイナリへのアクセスの追加）。
- システムアプリケーションでコードを実行する。
- Linux カーネルでコードを実行する。
- Secmon でコードを実行する。
- Pluton でコードを実行する。
Cisco Talos はこのすべての項目で脆弱性を発見しています。ここでは権限昇格のステージごとにそれらの脆弱性をまとめて説明します。
達成できた最も重大なチェーンは次の手順のようになります。
- 脆弱な顧客アプリで ROP が可能になる（これが前提条件であると仮定します）。
- アプリで任意のコードを実行する（未署名コード実行の問題をエクスプロイト）。
- Linux カーネルで任意のコードを実行する（情報漏洩やメモリ破損の問題をエクスプロイト）。
- Secmon メモリの任意読み取り（情報漏洩をエクスプロイト）またはファームウェアのダウングレードを行って、いずれかのファームウェア（Secmon、Pluton、1BL）の脆弱なバージョンをデバイスでフラッシュする。
Normal World（Linux）での未署名コード実行
Azure Sphere のセキュリティモデルでは、Azure Sphere デバイスで実行されるすべてのコードは Microsoft 社またはアプリケーション開発者によって署名されている必要があります。具体的に言うと、デバイス上の実行可能データはすべて、Azure Sphere アプリケーション（および rootfs）を構成する ASXipFS パーティション内に存在している必要があります。ASXipFS ファイルシステム カーネル ドライバは書き込みを一切サポートしておらず、（不揮発性データの保存に使用される）Littlefs ファイルシステムも noexec としてマウントされます。Azure Sphere は W^X のコンセプトをプロセスメモリからディスク自体に拡張することにより、W ^ X 保護を事実上、デバイス全体に適用します。こうして「未署名コード実行」が防止されています。
ランタイム側では、カスタムの Azure Sphere Linux セキュリティモジュール（LSM）において mprotect / mmap の syscall に対する保護機構が実装されており、攻撃者がページのアクセス許可を変更したり、プロセスメモリにコードを挿入したりすることが防止されています。過去に書き込み可能だったページに対しては、仮想メモリページの VM_MAY* フラグを使用することで、権限を実行可能に変更することを禁止します（そもそも、書き込み可能かつ実行可能なページをマッピングすること自体を禁止します）。
したがって、特定のプロセス内でメモリに書き込んでそれを実行するのは簡単なことではありません。Cisco Talos は、これを可能にする 7 件の脆弱性を Linux で発見しました（別途記載がない限り、特別な前提条件は存在しません）。
- TALOS-2020-1093：/proc/self/mem に書き込んで .text セクションを変更する。
- TALOS-2020-1138：/proc/thread-self/mem に書き込んで .text セクションを変更する。これは TALOS-2020-1093 が部分的に修正された後に発見されました。
- TALOS-2020-1090：ptrace を使用してプロセスにアタッチし、ptrace の POKETEXT を使用して .text セクションを変更する。
- TALOS-2021-1249：unshare または clone で作成した名前空間で、前述と同様にして ptrace を使用する。これはカーネルの別のチェックをバイパスしているので、別の脆弱性です。
- TALOS-2021-1247：新しい mount namespace を作成し、tmpfs をマウントし、tmpfs ディレクトリに実行ファイルを書き込んで実行する。
- TALOS-2020-1128：READ_IMPLIES_EXEC パーソナリティを設定して、read 権限を要求するすべての mmap コールに exec 権限も付与する。これによって rwx マップが作成され、書き込みと実行が可能になります。
- TALOS-2020-1134：PACKET_MMAP 機能を使用して AF_PACKET を作成し（CAP_NET_RAW が必要）、それを read+exec として mmap する。ネットワーク インターフェイスに書き込む別のプロセスを使用してこのバッファにシェルコードを書き込み、最後にバッファから実行する。
Normal World（Linux）の脆弱性
サービス妨害
以下のサービス妨害の脆弱性がエクスプロイトされるとデバイスを起動できなくなり（ブートループに陥り）、手動リカバリが必要になります。
- TALOS-2020-1129：truncate syscall を使用して littlefs クォータをバイパスすると /mnt/config パーティションが破損してデバイスを起動できなくなる。
情報漏洩
最初の脆弱性を除き、すべてカーネル情報漏洩の脆弱性です。
- TALOS-2020-1089：klogctl を使用してカーネルリングバッファを読み取り、システムアプリケーションの ASLR オフセットをリークさせる。
- TALOS-2020-1130：truncate syscall を使用してカーネルメモリをリークさせる（任意ではない）。これは littlefs でメモリページが再利用時にクリーンアップされないことを悪用した脆弱性です。
- TALOS-2021-1339：GPIO_SET_PIN_CONFIG_IOCTL ioctl を /dev/gpiochip0 に対して使用して、部分的に制御されたカーネルメモリリークを引き起こす。
- TALOS-2021-1340：GPIO_GET_PIN_ACCESS_CONTROL_USER ioctl を /dev/gpiochip0 に対して使用して、任意のカーネルメモリをリークさせる。
以下は Azure Sphere の分析中にアップストリーム Linux カーネルで発見された情報漏洩の脆弱性です。これらはすべての ARM 32 ビットシステムに影響を与えます。
- TALOS-2020-1211：/proc/pid/syscall を読み取ってカーネルメモリをリークさせる（任意ではない）。
- TALOS-2021-1243：任意のプロセスのアドレス空間で SIGPAGE メモリマップを読み取ってカーネルメモリをリークさせる（任意ではない）。
メモリ破損
任意のカーネルコードが実行される危険性があるメモリ破損の脆弱性です。
- TALOS-2020-1118：AF_AZSPIO ソケットを 2 回バインドしてカーネルリンクリストでダブルフリーを発生させる。
- TALOS-2021-1250：カーネルで mqueue inode が初期化されない脆弱性を、名前空間を使用してエクスプロイトする。
- TALOS-2021-1262：PWM_APPLY_STATE ioctl を /dev/pwm0 に対して使用して任意のカーネルアドレスで kfree を実行する。11 月 26 日の Hitcon 2021 で Lilith Wyatt がこの脆弱性をエクスプロイトする方法について詳しく説明しますので、ぜひ講演にご参加ください。
権限昇格チェーン
これはさまざまな脆弱性からなり、次の順で連鎖させると任意の Secmon syscall や Pluton syscall を呼び出すことができます。
- TALOS-2020-1131：細工したイメージパッケージを使用して ASXipFS inode を介して任意のデバイスにアクセスする。このイメージは、McAfee ATR が発見した署名処理の問題をエクスプロイトしてフラッシュできます。
- TALOS-2020-1132：MEMWRITE ioctl を /dev/mtd1 に対して使用して config パーティションを書き込み、uid_map ファイルを変更する。このファイルはプロセスを UID にマッピングしています。
- TALOS-2020-1137：uid_map ファイルで azured プロセスのエントリを複製する。
- 任意のサービス妨害の脆弱性をエクスプロイトしてデバイスを再起動する（TALOS-2020-1129 など。メモリ破損の脆弱性ももちろん使用できます）。これによって新しい uid_map が適用され、昇格した azured UID が得られます。
- TALOS-2020-1133：ptrace を使用して azured プロセスにアタッチし、シェルを挿入する。これで azured 機能が得られたので、Secmon と通信してファームウェアイメージのフラッシュなどを行ったり、Pluton と通信したりすることができます。
Security Monitor（Trusted OS）の脆弱性
サービス妨害
以下のサービス妨害の脆弱性がエクスプロイトされるとデバイスを起動できなくなり（ブートループに陥り）、手動リカバリが必要になります。
- TALOS-2021-1311：SECTION_ABIDepends セクションに不正な list_size フィールドがある細工したイメージパッケージをフラッシュする。フラッシュ操作は機能しますが、起動時にイメージが解析されて Secmon がクラッシュし、デバイスがブートループに陥ります。
- TALOS-2021-1341：正規の古いトラストキーストアをフラッシュする。そこに含まれているキーでは現在のファームウェアイメージを検証できないため、起動時に Pluton が検証チェックを完了できなくなります。注：この脆弱性は理論上のものであり、開発モードで発見されました。実稼働環境での確認は Talos も Microsoft 社も行っていません。詳細についてはアドバイザリを参照してください。
情報漏洩
- TALOS-2021-1309：SMSyscallPeripheralAcquire syscall を使用してペリフェラル構造体の初期化されていないフィールドを読み取ることで Secmon メモリが漏洩する（任意ではない）。
- TALOS-2021-1310：SMSyscallWriteBlockToStageImage syscall を使用して任意の Secmon メモリをフラッシュに書き込む。その後、SMSyscallReadFlash syscall を使用してフラッシュの内容を読み取ることで任意の情報が漏洩する。
- TALOS-2021-1343：SMSyscallStageBaseManifests を使用して Secmon のメモリの任意のオフセットにマニフェストをステージングする。これは読み取り操作で境界チェックが行われないことを悪用しています。
この最後の脆弱性（TALOS-2021-1343）がどのような結果をもたらすかは少し分かりにくくなっています。これは情報漏洩につながる危険性があると Cisco Talos では考えています。完全な実装はかなりの時間を要するためまだ達成できていませんが、理論的には次のようになります。
- SMSyscallStageBaseManifests を使用して Secmon のメモリの任意のオフセットにマニフェストをステージングします。これは読み取り操作で境界チェックが行われないことを悪用しています。マニフェストを任意の場所にステージングしても情報が直接漏洩することはありません。またマニフェストの実際の内容が読み取られる前にマニフェストヘッダーに対してさまざまなチェックが行われます。しかし、それらのチェックの後で一部のデータがマニフェストバッファから再度読み取られるので、TOCTTOU の問題が発生する余地が存在します。
- これらのチェックをバイパスするには、SMSyscallStageBaseManifests syscall を呼び出し、それと並行してマニフェストヘッダーを破損したヘッダーに変更すればよいことになります。これは Normal World からは行えません。Linux からは SMC 命令を発行して Secmon syscall を呼び出しますが、SMC は同期例外になるからです。
- ここで思い出してほしいのは、リアルタイムコア（M4）を自由に使用できるということです。リアルタイムコアは A7 とは別のコアであるため SMC と並行して実行できます。
- したがって、破損したヘッダーを持つマニフェストをステージングするには次のようにします。
- DMA バッファを割り当て、そこに継続的に書き込むようにリアルタイムコアに指示する。
- SMSyscallStageBaseManifests を使用して、割り当てられた DMA メモリにマニフェストをステージングする（DMA は Linux、Secmon、Pluton、リアルタイムコアの間で共有されていることを思い出してください）。
- 破損したマニフェストを書き込むようにリアルタイムコアに指示することで、ある時点で TOCTTOU が発生して、破損したヘッダーを持つマニフェストがステージングされる。
- このようなマニフェストをステージングしたら、SMSyscallGetMissingBaseImagesToDownload syscall を使用して Secmon メモリをリークさせることができます（任意ではなく制約あり）。
ファームウェアのダウングレード
- TALOS-2021-1342：SMSyscallStageBaseManifests syscall を使用してベースマニフェストをステージングする際に、細工したマニフェストイメージで 0x19 を超えるイメージタイプフィールドを使用して署名チェックをバイパスする。これによって任意のベースマニフェストを作成でき、それによって任意の（Microsoft 社の署名がある）イメージの任意のバージョンをフラッシュできます。
- TALOS-2021-1344：任意の（古い）リカバリマニフェストをステージングし、リカバリマニフェストで参照されている 1BL を SMSyscallCommitImageStaging を使用してフラッシュする。これによって 1BL を任意のバージョンにダウングレードできます。注：この脆弱性は理論上のものであり、開発モードで発見されました。実稼働環境での確認は Talos も Microsoft 社も行っていません。詳細についてはアドバイザリを参照してください。
Cisco Talos ではこれらのダウングレードの問題を発見した後、古いバージョンにおける脆弱性を調査していませんが、問題の悪用を狙う攻撃者が脆弱性を探って発見する可能性がありますのでご注意ください。たとえば攻撃者が古いバージョンの 1BL や Pluton でイメージ解析に脆弱性を発見して、デバイスで永続性を維持したり、リモート構成証明をバイパスしたりする可能性があります。
Pluton の脆弱性
サービス妨害
以下のサービス妨害の脆弱性は永続的ではありませんが、Normal World のユーザーランドからトリガーすることができます。通常、デバイスを再起動する権限をアプリが得るには、マニフェストで PowerControls セクションを宣言する必要があります。以下の脆弱性がエクスプロイトされると、権限のないアプリによってデバイスが再起動される危険性があります。
- TALOS-2020-1117：権限のない Linux 側のアプリから非同期 ioctl を繰り返し送信すると Pluton のリングバッファがいっぱいになってウォッチドッグがトリガーされ、デバイスが再起動される。
- TALOS-2021-1347：権限のない Linux 側のアプリから ioctl を繰り返し送信すると Pluton がレート制限に達してデバイスが再起動される。これは意図した動作であると見なされているため Microsoft 社による修正は行われていません。
メモリ破損
メモリ破損の脆弱性を Pluton で 1 件発見しましたが、Microsoft 社によるとこれはエクスプロイトできません。
- TALOS-2020-1139：SIGN_WITH_TENANT_ATTESTATION_KEY Pluton syscall を使用してバッファに任意の内容の境界外書き込みを行う。
まとめ
Cisco Talos は Azure Sphere の調査の一環として 31 件の脆弱性をデバイスで発見して公表し、その修正に協力しました。顧客アプリケーションにおけるコード実行、ファームウェアのダウングレード、Secmon の情報漏洩などの脆弱性です。さまざまな方法でこれらの脆弱性を連鎖させて目的を達成できます。順番に挙げると次のようになります。
- 「未署名コード実行」セクションにある問題のいずれか。
- 「Normal World」セクションにある「情報漏洩」および「メモリ破損」の問題のいずれか。または「Normal World」の「権限昇格チェーン」セクションの問題のいずれか。
- 「Security Monitor」セクションにある「ファームウェアのダウングレード」または「情報漏洩」の問題のいずれか。
「ファームウェアのダウングレード」セクションで説明したように、これは最も重大なエクスプロイトパスの 1 つです。このパスが実行されるとデバイスが完全に侵害されます。最悪のシナリオでは、攻撃者がデバイスで永続性を維持したり、リモート構成証明をバイパスしたりする危険性があります。
- また Pluton や Security Monitor が完全に侵害されなくても、次のようなさまざまな悪意のある行為が攻撃者によって行われる恐れがあります。
- 任意のユーザーランドコード/カーネルコードが実行されて Linux 側がネットワークを通じて攻撃者に制御される。たとえばボットネットに組み入れられる危険性があります。
- ボックス上のすべての企業/顧客アプリケーションもそのデータとともに完全に侵害される。
- リモート構成証明では Linux Normal World が改ざんされていることを確認できない可能性がある。なぜなら、このエクスプロイトチェーンではデバイスのファームウェアを変更する必要がないからです。
- 更新を簡単に無効にできる（ユーザーランドプロセスで処理）。ただし理論上は新しいバージョンがリリースされたときにこれを検出することができます（自動更新が失敗するため）。
- デバイスが利用できなくなる（USB による手動リカバリが必要になる）。これには複数の方法（TALOS-2020-1129、TALOS-2021-1311、TALOS-2021-1341）があります。
- ソフトウェアでデバイスの電源をオフにする機能が無効にされる。このような要求は簡単に破棄できるからです。
また理論上は、永続性を維持したりボットネットの一部として機能したりするためにエクスプロイトで新しいファームウェアをフラッシュする必要は必ずしもないため、Azure クラウドへのアクセスが引き続き可能です。デバイス構成証明はイメージの署名に依存しており、これを変更する必要は必ずしもないからです。
もしかすると、次のように実行できないことを挙げたほうが早いかもれません。
- 高特権のコア（Pluton/Secmon）でコードを実行する。ただし、TALOS-2021-1342 および TALOS-2021-1344 と他の脆弱性を組み合わせるとこれを達成できる可能性があります。
- デバイスのハードウェア秘密キーを抽出する。
本稿は 2021 年 11 月 22 日に Talos Group
Authors