Apple M5で初公開のmacOSカーネルメモリ破損エクスプロイト

 (blog.calif.io)
1 ポイント 投稿者 GN⁺ 4 시간 전 | 1件のコメント | WhatsAppで共有
  • Califのエンジニアたちが、Apple M5で動作するmacOSカーネルメモリ破損エクスプロイトを作成し、Appleに脆弱性研究レポートを提出
  • エクスプロイトチェーンは、MIEが有効なbare-metalのM5ハードウェアを対象としており、Appleが修正後に技術的詳細の全文が公開予定
  • 対象は**macOS 26.4.1 (25E253)**で、権限のないローカルユーザーから通常のシステムコールのみでroot shellに到達
  • 実装には2つの脆弱性と複数の手法が使われており、CalifはこれをMIEハードウェア上で公開された初のmacOSカーネルエクスプロイトと見ている
  • Mythos Previewはバグ特定とエクスプロイト開発を支援したが、MIEのような新しい緩和策の回避には依然として人間の専門家が必要

M5のMIEを突破したmacOSカーネルエクスプロイト

  • CalifのエンジニアたちがMythos Previewとともに、Apple M5シリコン上で動作するmacOSカーネルメモリ破損エクスプロイトを作成し、Apple ParkでAppleに脆弱性研究レポートを直接手渡した
  • このチェーンは、MIE(Memory Integrity Enforcement)が有効なbare-metalのM5ハードウェアを対象とする
  • 対象は**macOS 26.4.1 (25E253)**で、権限のないローカルユーザーから開始し、通常のシステムコールのみを使用してroot shellで終わる、データ専用のカーネルローカル権限昇格チェーン
  • 実装には2つの脆弱性と複数の手法が含まれており、Appleが脆弱性と攻撃経路を修正した後、55ページのレポートと技術的詳細の全文が公開予定
  • スケジュールは迅速に進行
    • Bruce Dangが4月25日にバグを発見
    • Dion Blazakisが4月27日にCalifへ参加
    • Josh Maineがツールを作成し、5月1日に動作するエクスプロイトが完成

MIEとMythos Previewの意味

  • メモリ破損はiOSやmacOSを含め、依然として最も一般的な脆弱性の種類であり、完全に防げないのであれば攻撃コストを引き上げる緩和策が必要
  • Appleは性能とセキュリティの両立を考慮して多くの防御機能をハードウェアに組み込み、スタック全体を制御することで回避の難易度を高めた
  • MIEはARMのMTE(Memory Tagging Extension)を基盤とするハードウェア支援のメモリ安全システムであり、Apple M5とA19の主要なセキュリティ機能として導入された
  • Appleの研究によれば、MIEは最近流出したCorunaおよびDarkswordのエクスプロイトキットを含め、現代のiOSに対するすべての公開エクスプロイトチェーンを妨害する
  • Califは、MTE環境でも動作するエクスプロイト構築にAIがどう貢献できるかを探ってきており、iOS中心だったAppleのMIEが最新MacBookのM5にも適用されたことで、macOSの攻撃経路が可能になった
  • Mythos Previewはバグ特定からエクスプロイト開発全般を支援し、すでに学習した問題タイプに対しては、ほぼ同種の問題へ一般化できる
  • Mythosがバグを素早く見つけられたのは、それらのバグが既知のタイプに属していたためであり、MIEのような新しい最先端の緩和策を自律的に回避することは依然として人間の専門家の領域
  • Califは、最先端モデルと専門家が組み合わさったときに何が可能かを検証し、この組み合わせは最高レベルの防御を相手に1週間以内でカーネルメモリ破損エクスプロイトを完成させた
  • MIEはハッカーを完全に止めるための仕組みではなく、適切な脆弱性があれば回避されうる
  • MAD Bugsシリーズでは、AIシステムがますます多くの脆弱性を発見しており、その一部はMIEのような高度な緩和策を突破できるほど強力になりうると見ている
  • AppleがMIEを作った時点ではMythos Previewのような環境は存在せず、今回の取り組みはAIベースのバグ発見が高度な緩和技術に与える圧力を示す初期の成果物である

関連記事

1件のコメント

 
GN⁺ 4 시간 전
Hacker Newsのコメント

  • 実演内容だけを見ると、Appleのバグバウンティプラットフォームでは10万ドル級の脆弱性に見えるが、見せ方次第では150万ドル級の脆弱性にもなり得る
    macOSベータ版で再現し、不正アクセスとして位置付け、可能ならロックダウンモードでも見せればよい

    • これはローカル権限昇格(LPE) に見え、上で言っているのは無クリックのリモートコード実行(RCE)に近い

  • セキュリティ問題に対するLLMの影響に、世の中はまったく準備できていないように見える
    もし本当ならCalifチームには祝意を表したいし、詳細は技術的すぎて完全には理解できないだろうが、55ページのレポートを楽しみにしている

    • 私も同意するが、心配なのは人間のほうだ
      あちこちで、開発者が自分で何をデプロイしているのかも十分理解しないまま、LLM生成コードの変更を本番環境に押し込んでいるという話を聞く
      変更が積み重なるほどコードベースへの理解は落ち、行動はさらに危うくなる
      さらに悪いのは、こうした振る舞いがリーダーシップによって直接的または間接的に後押しされていることだ。非現実的な速度目標、曖昧な「AI活用」イニシアチブでの昇進、解雇によって残った開発者に過負荷をかけること、未熟な開発者をシニアの役割に据えること、といった具合だ
      業界のかなり大きな部分が、セキュリティの基本を苦労して学び直そうとしているかのようで、世の中は狂っている
    • ブルーチームやエンジニアたちが何もせず指をくわえているとでも思っているようだ

  • LLMは今後数年間でルーブ・ゴールドバーグ的な脆弱性を大量に生み出すだろう
    すでに始まっており、今回の件がそれだというわけではないが、実際に起きている

    • 理論上安全なシステムを作ること自体、物理的に不可能なのかもしれない
      どんなウイルスにも脆弱でない細胞は存在しない、と考えるのに近い
      もしかするとこれまでは一種のあいまいさによるセキュリティで持ちこたえてきただけで、そのあいまいさとは結局、誰にもコードを実際に分析する時間と集中力がなかったという意味なのかもしれない
    • そういう脆弱性をカーネルにバイブコーディングで埋め込むという意味なのか、それとも見つけ出すという意味なのか気になる

  • 残念ながら詳細がやや不足している
    バグがどうやってMTEをすり抜けたのか非常に気になる

    • Memory Tagging Extension
      Armは2019年に、ハードウェアがメモリ破損バグの検出を支援する仕組みとしてMemory Tagging Extension(MTE)の仕様を公開した
      MTEはメモリタグ付けとタグ検査のシステムで、あらゆるメモリ割り当てに秘密値をタグとして付与する
      その後ハードウェアは、メモリアクセス要求に正しい秘密値が含まれている場合にのみアクセスを許可する
      秘密値が一致しなければアプリはクラッシュし、イベントが記録され、開発者はメモリ破損バグを発生したその場で特定できる
      https://support.apple.com/guide/security/operating-system-in...
    • データ専用攻撃をもう少し読んで納得した
      (https://www.usenix.org/publications/loginonline/data-only-at...)
      プログラム自体が実際に変わるわけではなく、MTEが介入すべき動作を強制しないため、MTEがトリガーされない
      もう一つ気になるのは、Appleがなぜここでfboundsチェックを使っていなかったのかという点だ
      他の箇所ではかなり積極的に適用してきたからだ
      MTEと全面的なfboundsチェックを組み合わせれば、OSは極めて堅牢になり得る
    • GPUメモリやシェーダーなどはMTEやPACでは保護されない
      「data-only」と言っているので、GPUコマンドはここに当てはまるかもしれない
    • 私も同じ疑問を持ったし、これがデータ専用攻撃だとすれば、MIEは多くの攻撃経路を減らすものの、有用な破損プリミティブを完全には排除しないという教訓なのかもしれない
    • バグがMTEをすり抜けたのは今回が初めてではない
      昨年、Google Pixelでも似たことがあった
      https://github.blog/security/vulnerability-research/bypassin...

  • Appleが、いわゆる安全な言語であるSwiftをいまだに社内で十分に使っていないのは驚きだ
    Swift 6全体がほとんどマーケティングだったのではないかと思ってしまう

    • 間違いなく使っている
      Embedded Swiftが登場した理由の一つも、現在Fil-Cに似た発想のC方言で書かれているiBootファームウェアを、より良いものに置き換えようとしているからだ
      ただしLinuxカーネルと変わらない
      Rustが許可されたからといって世界のすべてが書き直されたわけではないし、正気の人ならClaudeでカーネルを書き直そうとはしない
    • AppleでSwiftは確かに使われている
      最近ではSafariのCSSパーサーにも追加され、Secure Enclaveの一部でも組み込みの形で動いている
      Strangeloopの頃からカーネルに入れようという議論はあったと認識しているが、どこまで進んでいるのかはよく分からない
      それとは別に、Appleはclangのfboundsチェックを強く推進しており、これはメモリ安全言語が提供するものの小さいながら重要な一部を実現し得る
      Swiftや代替言語の採用がさらに広がるのも見たいし、安全な言語分野で競争が増えるのはいつでも歓迎すべきことだ
    • Strict Memory Safetyオプションに関心があるかもしれない
      https://docs.swift.org/compiler/documentation/diagnostics/st...

  • MIEがあるからわざわざM5を買ったのに、今では少し間抜けだった気分だ

    • そう思う必要はない
      MTEは脆弱性の大きな塊を防いでくれるし、ROPやJOPのような手法を今では非常に困難、あるいは事実上不可能にしている
    • メモリ破損バグよりnpm/PyPIマルウェアのほうを心配すべきだ

  • 記事は修正されたのか？ 現地訪問についての説明があまりない

  • Mythosのためのまた一つの大げさなマーケティングのように見える
    curlのレポートははるかに落ち着いていた
    https://daniel.haxx.se/blog/2026/05/11/mythos-finds-a-curl-v...

    • この人たちはAppleやAnthropicで働いているわけではない