macOSにおけるパスワード漏えいとその他の問題

 (wts.dev)
1 ポイント 投稿者 GN⁺ 2025-03-21 | 1件のコメント | WhatsAppで共有

macOSにおけるパスワード漏えい（そしてさらに多くの問題！）

はじめに

この記事では、Appleのセキュリティアップデートに含まれていた脆弱性 CVE-2024-54471 について説明する。この脆弱性は macOS Sequoia 15.1、macOS Sonoma 14.7.1、macOS Ventura 13.7.1 で修正された。macOSデバイスを使用している場合は、最新版への更新を推奨する。

カーネルとは何か？

オペレーティングシステムにおいて、ハードウェアと通信し、マルチタスクモデルをアプリケーションに提供するコードを カーネル と呼ぶ。macOSのカーネルは XNU であり、BSDカーネルとMachカーネルの派生を含むハイブリッドカーネルである。

Machの歴史

Machカーネルは、1980年代から90年代のUnix戦争と深く関わっている。Machはカーネギーメロン大学でオペレーティングシステム研究プロジェクトとして始まり、NeXTSTEPオペレーティングシステムで使用され、それが最終的にmacOSの基盤となった。

なぜMachなのか？

Machは、Unixシステムの設計と利用の複雑さを減らすために開発された。Machは4つの基本的な抽象化で構成されており、これらは現代のmacOSでも引き続き使われている。

Machのアーキテクチャ

4つの抽象化

  • タスク: スレッドが実行できる環境であり、リソース割り当ての基本単位である。
  • スレッド: CPU利用の基本単位であり、タスク内で独立したプログラムカウンタとして動作する。
  • ポート: メッセージのための通信チャネルであり、カーネルによって保護される。
  • メッセージ: スレッド間通信に使用されるデータオブジェクトの集合である。

タスク、ポート、ポート権限

ポートはカーネル空間にのみ存在し、ユーザー空間にはポート権限として公開される。複数のタスクがポートに対する送信権限を持つことはできるが、受信権限を持てるのは1つのタスクだけである。

メッセージの構造

各Machメッセージは、ヘッダー、任意のディスクリプタ、任意のペイロード、そしてカーネルが追加したトレーラーで構成される。

送信権限を取得する方法

macOSには ブートストラップサーバー があり、これはすべてのタスクが送信権限を持つポートの受信権限を保持している。クライアントは、特定の名前を持つMachサービスに対する送信権限をブートストラップサーバーに要求できる。

Machインターフェースジェネレータ（MIG）

はじめに

MIGは、Machメッセージの送受信のための機能的なインターフェースを生成するツールである。これはメッセージベースのRPCスタイルのインターフェースを提供し、メモリ安全性を高める。

技術的詳細

MIGはMachメッセージのラッパーであり、各関数は ルーチン と呼ばれ、ルーチンの集合は サブシステム と呼ばれる。サブシステムはメッセージIDフィールドでインデックス化される。

MIGサーバーの脆弱性

MIGサーバーのセキュリティ

MIGサーバーは、メッセージ送信元を検証しなければ、送信権限を持つタスクがサーバーのルーチンを呼び出せてしまう。

MIGサーバーを見つける

ipsw CLIツールを使用して、NDR_record シンボルを使用するバイナリを検索できる。これはMIGサーバーとクライアントを見つけるのに有用である。

NetAuthAgentの脆弱性

NetAuthAgentの紹介

NetAuthAgent は、macOSでファイルサーバーの認証情報を処理するデーモンである。この脆弱性が修正される前は、サーバーの認証情報を要求するとそれを提供していた。

NetAuthAgentの動作方式

NetAuthAgentは、macOSの キーチェーン を使って認証情報を保存する。キーチェーンは集中型のシークレットマネージャーであり、各項目は独自のアクセス制御リストを持つ。

NetAuthAgentのMIGサーバー

NetAuthAgentは、com.apple.netauth.user.gui という名前でブートストラップサーバーに登録されたMIGサーバーを公開している。このサーバーは、認証情報を読み取り、作成し、上書きできるルーチンを提供する。

脆弱性の影響

iCloud APIトークンの露出

この脆弱性はiCloud APIトークンを露出させ、攻撃者がユーザー情報を流出させたり、他のデバイスの位置を追跡したりできるようにする。

Appleが取るべきだった対応

この記事には、Appleがこの脆弱性を解決するためにどのような措置を取るべきだったかについての議論が含まれている。

関連記事

1件のコメント

 
GN⁺ 2025-03-21
Hacker News の意見

  • よく書かれた記事。Appleがある程度隠そうとしていたゼロデイ事件を思い出した。空のパスワードを2回試すことで root ログインを回避できた件だ。2017年か2018年ごろの出来事だった

    • 管理者のユーザー名を入力して空のパスワードでログインを試みると、最初はパスワードが間違っているという警告が表示される。警告を無視して2回目にログインボタンを押すと、そのユーザーとしてログインできた
    • この問題はソーシャルメディアで拡散された後、すぐに修正された。それでも大きな失態に見える
    • Mac の認証メカニズムにはまだ問題があるようだ。ポートシステムに言及しているのが興味深い。Mach カーネルのあまり知られていない事実だ

  • ACLs don’t: <a href="https://waterken.sourceforge.net/aclsdont/current.pdf" rel="nofollow">https://waterken.sourceforge.net/aclsdont/current.pdf</a>;

  • あるプロセスが別のプロセスにキーチェーンクエリをプロキシできる仕組みを公開すると、システム全体のセキュリティを弱める可能性がある

  • 記事に小さな修正が入った

    • 権限チェックはカーネルの Mach レイヤーにはない
    • <a href="https://github.com/nmggithub/wts/commit/2bdce1c0c76c7adc360e17a6a42ee547462b99d3" rel="nofollow">https://github.com/nmggithub/wts/…;
    • XNU の動作に関する事実誤認を直すための、1語だけの変更だった

  • 8時間かかったが、この投稿はもうフロントページ上位5件ではない（今は #27 で、まだフロントページにはあるが下のほう）。すべてのコメントに感謝する

  • 著者が実際の PoC コードを提供しているのか気になる。緩和策をテストしてみたい。サンプルコードは見たが、不完全に見える

    • 実際にどんなリスクがあるのか気になる

  • とても興味深い記事だ。Mach と Darwin カーネルの成り立ちにこれほど多くの話があるとは知らなかった

  • 最近の Mach は、macOS におけるバグの信頼できる供給源のように感じる。Apple がそれをすべて封じようと必死に取り組んでいるのは知っているが、Mach から完全に離れる道筋があるのか気になる

  • [dead]