ハクソク

世界を動かす技術を、日本語で。

メモリ整合性の強制

258日前原文(security.apple.com)

概要

  • Memory Integrity Enforcement (MIE) はApple独自のハードウェアとOSセキュリティを統合した、業界初の常時オン型メモリ安全保護機構。
  • iPhone 17 やiPhone Airなど、最新Appleデバイスに標準搭載。
  • Enhanced Memory Tagging Extension (EMTE) を中核とし、バッファオーバーフローやuse-after-freeなどの脆弱性をハードウェアレベルで防御。
  • Xcode を通じて全Apple開発者にもEMTEを提供、開発段階から安全性を強化。
  • パフォーマンスを損なわず、高度な攻撃にも耐える新しいセキュリティ基盤。

Memory Integrity Enforcement (MIE)の全貌

  • MIE は、Apple siliconのハードウェアと高度なOSセキュリティを融合した、これまでにないメモリ安全対策。
  • 消費者向けOS史上最大のメモリ安全性向上 とAppleは位置付け。
  • iPhoneでは大規模なマルウェア攻撃の成功例がなく、観測されるシステムレベルの攻撃は国家レベルのスパイウェアに限定。
    • これらスパイウェアは数百万ドル規模のコストと高度な技術を要し、ターゲットはごく一部の個人。
  • こうした攻撃手法の多くは メモリ安全性の脆弱性 を突いており、Appleは業界全体の課題と認識。

Appleのメモリ安全性強化の取り組み

  • Swift ：Appleが開発したメモリ安全なプログラミング言語。新規コードや重点コンポーネントの書き換えに活用。
  • kalloc_type （iOS 15）と xzone malloc （iOS 17）：用途ごとにメモリを割り当て、脆弱性悪用を困難化するセキュアアロケータ。
  • Pointer Authentication Codes (PAC) ：A12 Bionicから導入。コードフローの整合性を守るハードウェア機構。
  • 2019年に Arm が発表した Memory Tagging Extension (MTE) を独自に評価・改良。
    • オリジナルMTEの弱点を解消すべく、Armと協力し Enhanced MTE (EMTE) を策定（2022年）。

MIEの設計と防御メカニズム

  • MIE は、セキュアアロケータ、EMTE（同期モード）、タグ秘匿性強化ポリシーを統合した総合防御策。
  • 常時オン・同期型 で動作し、パフォーマンスを維持しつつ、カーネルなど主要攻撃面を防御。
  • Xcode のEnhanced Security機能として、開発者にもEMTEを提供。

セキュアアロケータの役割

  • kalloc_type, xzone malloc, WebKitのlibpas など、型情報を活用してメモリ配置を最適化。
    • 攻撃者が意図的にメモリ配置をコントロールするのを困難化。
  • ページ単位（iOSでは16KB）で保護を適用し、小規模な割り当てにはページレベルの防御を活用。

EMTEによる具体的な攻撃防御

  • バッファオーバーフロー ：隣接する割り当てに異なるタグを付与。異なるタグ領域への越境アクセスはハードウェアがブロック。
  • use-after-free ：解放後再割り当てでタグを変更。古いタグでのアクセスはブロックされ、OSがプロセス終了等の措置。
  • 非タグ付きメモリ （グローバル変数等）へのアクセスも、タグ領域からはタグ確認を必須とし、攻撃困難化。

タグ秘匿性とサイドチャネル対策

  • Tag Confidentiality Enforcement ：EMTEタグの秘匿性を強化し、カーネルデータ構造やタグ情報の漏洩を防止。
    • Secure Page Table Monitor でカーネルアロケータやタグストレージを保護。
    • カーネルによるアプリ代理アクセスもタグチェックを徹底。
  • 投機的実行攻撃 （Spectre等）への対策も実装。
    • タグ値が投機的実行経路に影響しないようApple siliconを設計。
    • タグ生成用疑似乱数生成器の頻繁な再シードで予測困難化。
    • Spectre Variant 1（V1）にも対応し、タグ漏洩リスクを最小化。

まとめ

  • Memory Integrity Enforcement は、Appleがハードウェア・ソフトウェア両面で全社的に取り組んだ新時代のメモリ安全機構。
  • iPhone 17やiPhone Air などの新モデルで標準搭載され、開発者もXcodeで利用可能。
  • 高度な攻撃にも耐える、常時オンのメモリ安全性 を実現し、今後の消費者向けOSの新しいセキュリティ基準を提示。

Hackerたちの意見

両方のアプローチから同じ結論が出たよ：メモリ整合性強制（MIE）は、攻撃者が利用できるエクスプロイト戦略を大幅に減らすんだ。メモリのバグは通常、互換性があるけど、MIEは基本的なレベルで多くのエクスプロイトステップを遮断しちゃったから、新しいバグを入れ替えてもチェーンを復元するのは無理だった。かなりの努力をしても、MIEを回避するためにこれらのチェーンを再構築することはできなかったよ。残ったメモリのバグの影響は不安定で、攻撃者にとって十分な勢いを与えないから、これは素晴らしいことだし、ちょっと埋もれたニュースだね。傭兵スパイウェアの経済の一部は、互換性のあるパーツを持つチェーンに依存しているから、その特性を直接狙った対策は面白いよ。

└

Appleのクレムリン学的に、これはCHERIのような完全な能力ベースのメモリ安全性への一歩と見なすべきなのか、それともAppleがCHERIなしでもやっていけると思っているサインなのか？

Apple/ARMモデルはかなり洗練されてると思うけど、ざっと見た感じでバーローズの大規模システムメモリタグ付けアーキテクチャを思い出したよ。

これは本当にすごいね。攻撃者が何度も試すチャンスがある場合、これが守ってくれるわけではないと理解してるんだけど。アプローチとしては、隣接するオブジェクトをスキップするために十分に範囲外に出たり、たくさんのグルーミングをしてから使ったりして、一致するタグを得るチャンスを狙う感じかな。一致するタグを得る確率は1/16だけど、この投稿には自信を持てるほどの詳細がないから、時間が経てばわかるよね！もしこれが成功すれば、残りのエクスプロイトチェーンは論理バグに依存することになるから、悪者たちにはかなり痛いことになるね。

└

Android MTEでも、回避策の一つは小さなタグサイズに対する確率的攻撃で、これは複数回の試行を意味してるよ。ここでの大きな違いは、均一な同期強制で、書き込みがすぐにトラップされて、次のコンテキストスイッチではないってことだね。

└

他の15/16回の試みはクラッシュしちゃうけど、そんな不安定なバグは実際の運用では使えないよね。ユーザーにバレるし、診断情報も上に送られちゃうし。それに、その15/16をいくつか重ねると、運が良くなるまで結構時間がかかるんだよね。

Googleは昨年、リスクのあるユーザー向けのプログラムに参加する人にMTEを提供するという素晴らしい第一歩を踏み出した。でも、MTEをオンにしているユーザーにとっても、AndroidでのMTEの効果は、メモリ整合性強制とAppleシリコンでのEMTEの使用を区別するオペレーティングシステムとの深い統合が欠けているために限られている。 > iPhone 17シリーズとiPhone Airの導入に伴い、私たちは業界初の包括的で常時オンのメモリ安全保護を提供できることを楽しみにしている：カーネルや70以上のユーザープロセスを含む重要な攻撃面をカバーし、強化されたメモリタグ付け拡張（EMTE）に基づき、安全な型付きアロケータとタグの機密保護によってサポートされている。もちろん、GrapheneOSの取り組みが他の人に認められないのは少し残念だけど、Appleが真剣に取り組んでいるのを見るのはとても励みになるね。これがGoogleにもPixel OSで同じことをするよう促すといいな。GrapheneOSが未知の脅威からデバイスの所有者を守るシステムを作るリーダーの一員であることに自信を持たせてくれるはずだよ。

└

Appleはこれに何年も取り組んできたんだ。DanielがGrapheneOSでそれをオンにすることを決めたときに、メモリタグ付けについて考え始めたわけじゃないよ。

メモリ安全性の保護は厳密に同期的で、デフォルトでオンにし、継続的に機能する必要があると考えています。ちなみに、これは「経験から」だと思ってるけど、第一原則からではないよね。これが彼らの初期のカーネルメモリ保護の仕組みではなかったから；P 2015年、iOS 9でAppleはカーネルパッチ保護（KPP）をリリースした。これはカーネルが非同期的に変更されていないことを確認するもので、頻繁には行われなかったと思うけど、コストがかかるチェックだったんじゃないかな。そして、もし破損が検出されるとパニックになる。 > まず、iOS 9以来の最悪の敵、KPP（カーネルパッチ保護）を考えてみよう。KPPは、デバイスが忙しくないときに数分ごとにカーネルの変更をチェックし続ける。 > 「たまにチェックする」っていうのはセキュリティ対策としてはあまり良くないように聞こえるし、実際、ルカ・トデスコによって完全なバイパスが公開されたけど、それは設計上の欠陥を含んでいる。KPPはカーネルパッチを防ぐわけではなく、ただそれをチェックし続けて、もし見つかったらカーネルをパニックさせるだけ。でも、まだパッチを当てることができるから、レースコンディションの機会が生まれるんだ。もし十分に速く行動してから元に戻せば、KPPは何も知らないよ ;)

EUのチャットコントロールがあったら、状態は俺のデバイスにあって、彼らが望むものにアクセスできて、俺が何をできるか決められちゃう。GoogleがWEIを強制したら、ウェブ全体がロックダウンされるよ。セキュアブートやMIEがあれば、自由を取り戻すことは絶対に無理だね。

└

つまり、システムやサービスをバルカン化しない限りね。

Armは2019年にメモリタグ付け拡張（MTE）の仕様を発表した。これはハードウェアがメモリ破損バグを見つける手助けをするためのツールなんだ。MTEは、基本的にはメモリにタグを付けてチェックするシステムで、すべてのメモリ割り当てには秘密がタグ付けされる。ハードウェアは、後のメモリアクセスリクエストが正しい秘密を含んでいる場合にのみアクセスを許可する。秘密が一致しないとアプリはクラッシュして、そのイベントがログに記録される。これにより、開発者はメモリ破損バグを発生した瞬間に特定できるんだ。

iPhoneに対する成功した広範なマルウェア攻撃はこれまで一度もない。実際に観測されるiOSのシステムレベルの攻撃は、特定の個人やデバイスを狙った傭兵スパイウェアから来ているだけ。ほとんどのユーザーはこんな風に狙われることはないと思うけど…もし間違ってたら教えてほしい。開発されたスパイウェアは、ボタン一つで大規模に適用できるはずだよ。今はそうしないことを選んでいるだけだと思う。この段落は、実際よりも大きな違いを強調してる気がする。

└

まあ、そうかもしれないし、そうじゃないかもしれない。でも、指摘するのは公平だと思う。もしそれがWindowsみたいに露出してたら、もっとたくさんあったはずだよ。

└

AppleやGoogleは、自社製品に対する攻撃がどれほど広がっているかを本当に理解していないのに、まるで完璧に把握しているかのように振る舞っているよね。彼らは、自分たちが知らないことを知っていると主張しているんだ。GrapheneOSは、エクスプロイト開発者からのリークデータを公開していて、実際にはデバイスを攻撃したり、アップデートを追跡したりするのが、ほとんどの人が思っているよりもずっと成功していることを示している。私たちは、公開している以上の情報を持っているけど、リークが特定されないように、複数の独立したソースがない限り公開しないからね。これらのツールは広く利用可能で、データ抽出なのかリモートエクスプロイトなのか、使われている時には一般的には分からない。野生でエクスプロイトを捕まえるのは例外で、そうでなければエクスプロイト開発会社は、使われた後に新しいエクスプロイトを作り続けるのがずっと大変になるはずだよ。もし50,000回使われた後に機能しなくなったら、彼らは単一のエクスプロイトチェーンをそんなに大切にしないだろうね。世界中の法執行機関は、Cellebrite Premiumのようなツールにアクセスできて、国境を越える多くの人々や抗議活動などに対して使われている。それがスケールでの使用だよ。リモートエクスプロイトについては、広く使われるために広く配布される必要がないから、あまり情報がないんだ。

2018年、私たちは業界で初めてA12 Bionicチップにポインタ認証コード（PAC）を導入した。これはメモリ破損がある状況でコードフローの整合性を守るためのものだ。この防御メカニズムの強力な成功は、ソフトウェアとハードウェアのセキュリティの深い統合が、私たちの最大のセキュリティ課題に対処する鍵になることに疑いを持たせなかった。PAC導入以降、複数のフルチェーン攻撃があったけど、攻撃者はPACのバイパスを見つけ続けているから、実際には意味のある攻撃抑止にはなっていない。これを考えると、EMTEがどれだけ安全か疑問に思うよね。

EMTEの存在は、攻撃者が攻撃を誘導するための最後の手段としてSpectre V1を残しているから、私たちはSpectre V1の漏洩の効果的な範囲を制限する全く新しい緩和策を設計した。これにはほぼゼロのCPUコストで、攻撃者は型の分離に対処しなければならない。この緩和策により、攻撃者がSpectre V1を使うのは実質的に不可能になる。通常、95％以上の悪用率に達するには25以上のV1シーケンスが必要だからね。これらのシーケンスのうちの1つが悪用されるバグに関連していない限り、私たちのkalloc_type分析と同じような理由で。彼らはこの緩和策が何をするのか説明したことがあるのかな？