多数の新しい macOS サンドボックス脱出脆弱性

 (jhftss.github.io)
1 ポイント 投稿者 GN⁺ 2024-11-09 | 1件のコメント | WhatsAppで共有
  • macOSのサンドボックス脱出研究において、これまで比較的注目されてこなかった PID domain XPCサービス が攻撃面として浮上し、10件以上の新規脆弱性の発見につながった
  • 中核的な標的はSystem/User domainのMachサービスではなく、アプリやフレームワークのロード時にPID domainへ登録される ApplicationタイプXPCサービス である
  • 脆弱な事例にはCVE-2023-27944、CVE-2023-32414、CVE-2023-32404、CVE-2023-41077、CVE-2023-42961、CVE-2024-27864、CVE-2023-42977などが含まれ、一部は TCCバイパス、SIP関連権限、iOSへの影響にもつながる
  • 繰り返し見られた失敗点は、非隔離サービスがファイル・ディレクトリ・アーカイブ・DMGを処理する際に、quarantine拡張属性、パス文字列、クライアント権限の検証を安全に扱えていなかった点である
  • Appleの対応は、脆弱なXPCサービスの削除、入力の正規化、サーバー側検証への移行、private entitlement の要求へと進んだが、なおパッチ待ちの報告が5件残っている

macOSサンドボックスモデルと脱出の目標

  • macOSでは、Apple自身のサービスやサードパーティ製アプリを含む多くのプロセスが、制限された サンドボックス環境 で実行される
  • 攻撃者がサンドボックス化されたプロセスでリモートコード実行（RCE）を得ても、実行能力やファイルアクセス権は制限されるため、次の段階はより広い権限を得るための サンドボックス脱出 となる

  • App Sandbox

    • Mac App Storeの要件により、多くのアプリが App Sandbox 制限下で実行される
    • サンドボックスアプリは com.apple.security.app-sandbox entitlement を持つ必要がある
    • 制限はアプリの main 関数より前、dyld初期化 の段階で適用される
    • App Sandboxに入るとアプリはコンテナ化され、ファイル操作はデータコンテナのパスに制限される
    • サンドボックスアプリが作成したファイルには、デフォルトで com.apple.quarantine 拡張属性が付与される
    • サンドボックスプロファイルには、この拡張属性の削除を防ぐルールがある
    • App Sandboxの詳細な権限は /System/Library/Sandbox/Profiles/application.sb に定義されている
    • ネットワーク、ハードウェア、ファイルシステム、アクセス可能なMachサービスが制限される
    • fork された子プロセスは、親のApp Sandbox制限を継承する
    • LaunchService.framework によって起動されたプロセスは制限を継承せず、たとえばシステムの open コマンドで非サンドボックスアプリを直接実行できる

  • Service Sandbox

    • Appleの多くの daemonサービス は、Service Sandboxコンテキストで実行される
    • サービスサンドボックスプロファイルは主に /System/Library/Sandbox/Profiles/*.sb と /usr/share/sandbox/*.sb にある
    • Service Sandboxの制限は、サービスの main 関数で sandbox_init_XXX APIを呼び出して手動で適用される
    • Service Sandboxに入ったサービスは、一般にコンテナ化されない
    • 重要な違いは、Service Sandboxで生成されたファイルがデフォルトでは quarantine処理されない 点である
    • quarantine関連APIを手動で呼び出さない限り、生成ファイルにquarantineは付かない

既存のmacOSサンドボックス脱出経路

  • LaunchService.framework攻撃

    • 従来の一般的な手法の1つは、LaunchService.framework を通じて非サンドボックスアプリを攻撃する方法である
    • CVE-2021-30864 は、システムの非サンドボックスアプリであるTerminal.appに対して $HOME 環境変数を操作した事例である
    • Terminal起動時、制御可能な $HOME/.profile 配下の悪意あるペイロードがサンドボックス制限なしで実行される
    • 別のシナリオでは、新しい非サンドボックスアプリをドロップしてから実行する
    • ただし、サンドボックスアプリが新たにドロップしたアプリはquarantine処理されるため、実行はブロックされる
    • quarantineなしでファイルやフォルダをドロップできれば、App Sandboxを完全に回避できる
    • CVE-2023-32364 は、devfs が拡張属性をサポートしない点を利用して、quarantineのないフォルダをドロップした事例である

  • アクセス可能なMachサービスへの攻撃

    • 2つ目の一般的な手法は、App Sandboxプロファイルに列挙された Machサービス を攻撃するものである
    • システムのMachサービス情報は /System/Library/xpc/launchd.plist に保存されている
    • bootstrap_look_up APIにより、サンドボックスアプリから特定のMachサービスへアクセス可能かどうかを確認できる
    • こうしたMachサービスは System domain または User domain に存在する
    • 今回の研究の出発点は、App Sandboxからアクセス可能なXPCサービスがこの2つのdomain以外にも存在するという点である

新たな攻撃面: PID domain XPCサービス

  • 見過ごされていたXPCサービスは PID domain に存在する
  • 従来よく見られたSystem/User domainのXPCサービスと異なり、これらのサービス種別は Application である
  • ApplicationタイプのXPCサービスは、アプリから要求された際に起動され、そのアプリが終了するとともに終了する
  • System/User domainのXPCサービスは、application.sb に定義されている場合にのみサンドボックスアプリからアクセス可能である
  • アプリやフレームワークが必要とするすべてのXPCサービスは、そのアプリの PID domain に現れる
  • PID domainの多くのXPCサービスは、サンドボックスアプリから呼び出されることを想定しておらず、着信するXPCクライアントに対するentitlement検査やサンドボックス検査を持たない可能性がある

  • SystemShoveService.xpcの事例

    • SystemShoveService.xpc は、システムprivate ShoveService.framework 内のXPCバンドルである
    • Info.plistにおけるサービス種別は Application で、バンドル識別子は com.apple.installandsetup.shoveservice.system である
    • サンドボックスアプリから /System/Library/PrivateFrameworks/ShoveService.framework をロードすると、対応するXPCサービスがPID domainに自動登録される
    • SystemShoveService.xpc は要求元のXPCクライアントを検査しないため、App Sandbox脱出に悪用可能だった
    • このサービスは com.apple.rootless.install という強力な SIP関連entitlement を持ち、SIP保護の回避にもつながり得た
    • この脆弱性には CVE-2022-26712 が割り当てられており、詳細は 以前の記事 にまとめられている

  • 探索方法

    • Service Typeが Application のすべてのXPCサービスは、App Sandbox脱出の潜在的な標的となる
    • システムフレームワークおよびprivateフレームワークから列挙して見つけられる
      • /System/Library/Frameworks
      • /System/Library/PrivateFrameworks
    • 着信するXPCクライアントを検査しないPID domain XPCサービスがあれば、次の方法で攻撃を試みられる
      • quarantineなしでアプリ フォルダ をドロップし、完全なサンドボックス脱出を得る
      • 非サンドボックスアプリが入った ZIP または DMG ファイルをquarantineなしでドロップする

beta限定の脆弱性2件

  • Beta-No-CVE-1: StorageKitにおける任意コマンド実行

    • Appleはこの脆弱性をadditional recognitionsに記載したが、CVEは付与しなかった
    • Appleによると、CVEは本番向けにリリースされたソフトウェアの脆弱性にのみ付与され、beta-onlyソフトウェアの脆弱性には付与されない
    • 影響対象はmacOS Sonoma Betaバージョンのみ
    • 脆弱なXPCサービスのパスは/System/Library/PrivateFrameworks/StorageKit.framework/XPCServices/storagekitfsrunner.xpc
    • このサービスはサンドボックス制限なしで実行可能で、delegateメソッドで全てのXPCクライアントを許可していた
    • SKRemoteTaskRunnerProtocolの唯一のメソッドrunTask:arguments:withReply:は、指定された実行ファイルパスと引数で任意コマンドを実行するよう設計されていた
    • 実行ファイルパスと引数をサンドボックスXPCクライアントが制御できたため、サンドボックス制限なしで任意のシステムコマンド実行が可能だった
    • AppleはmacOS Sonoma 14.0の正式リリース前に、脆弱なXPCサービスをOSから完全に削除した

  • Beta-No-CVE-2: AudioAnalyticsHelperServiceのZIP生成悪用

    • この脆弱性も同じbeta-onlyの理由でCVEは付与されなかった
    • 脆弱なXPCサービスのパスは/System/Library/PrivateFrameworks/AudioAnalyticsInternal.framework/XPCServices/AudioAnalyticsHelperService.xpc
    • このサービスはサンドボックス制限なしで実行可能で、全てのXPCクライアントを許可していた
    • createZipAtPath:hourThreshold:withReply:メソッドは、XPCクライアントが指定した任意のパスを圧縮する
    • 指定パスにcompressedフォルダがなければ作成し、.jsonファイルを探してそのフォルダへ移動した後、ZIPファイルを作成する
    • 攻撃者はcompressedフォルダをsymlinkに置き換えることで、任意のファイルを任意の場所へ移動できる
    • ソースファイルの内容は検査されず、対象ファイルパスは.json接尾辞を持つ必要がある
    • 新たに作成されたZIPファイルは、サービスがサンドボックス化されていないためquarantine処理されない
    • AppleはmacOS Sonoma 14.0のリリース前に、受信するXPCクライアントのcom.apple.audioanalytics.helper.service entitlementを検査するよう修正した
    • 最新のmacOSでは、private AudioAnalyticsInternal.frameworkと当該XPCサービスは完全に削除されている

CVE-2023-27944: TrialArchivingService

  • 脆弱なサービスは/System/Library/PrivateFrameworks/TrialServer.framework/XPCServices/TrialArchivingService.xpc
  • このサービスは/System/Library/Sandbox/Profiles/com.apple.trial.TrialArchivingService.sbプロファイルでService Sandboxに入る
  • Service Sandboxであるため、ドロップされたファイルはquarantine処理されない
  • このサービスは受信する全てのXPCクライアントを許可していた
  • extractArchiveFromHandle:withArchiveName:toDirectory:destDirExtension:postExtractionCompression:completion:メソッドは、サンドボックスアプリが渡したアーカイブファイルを指定位置に展開する
  • 展開されたコンテンツにquarantine拡張属性が引き継がれず、quarantineなしのファイルドロップにつながる可能性があった

  • 悪用条件と回避策

    • このメソッドを悪用すると、アーカイブ内のMach-Oファイルは展開後に実行権限を失うため、そのままでは実行できない
    • CVE-2021-30990の手法のようにsymlinkを使う方法が回避策になり得る
    • ただしこのXPCメソッドはディレクトリと通常ファイルのみを展開し、アーカイブからのsymlink展開は許可しない
    • 1つの回避方法は、ペイロードアプリをサンドボックスアプリコンテナパスに展開すること
    • サンドボックスアプリはそのパスへの読み書き権限を持つため、自身でsymlinkを作成したりchmodで実行権限を付与したりできる
    • 別の方法は、ペイロードアプリを二重にアーカイブすること
      • 脆弱なXPCメソッドで外側のZIPを展開する
      • システムのopenコマンドで内側のZIPを展開する

  • パッチ

    • AppleはmacOS Ventura 13.3で、受信するXPCクライアントのcom.apple.TrialArchivingService.internal entitlementを検査するよう修正した
    • 当該entitlementがなければXPC接続を拒否する

CVE-2023-32414: ArchiveService

  • 脆弱なサービスは/System/Library/PrivateFrameworks/DesktopServicesPriv.framework/XPCServices/ArchiveService.xpc
  • このサービスはService Sandboxに入るが、ドロップファイルはquarantine処理されない
  • このサービスは全てのXPCクライアントを許可していた
  • unarchiveItemWithURLWrapper:…メソッドは、サンドボックスアプリが渡した項目を指定位置に解凍する
  • 展開されたコンテンツにquarantine拡張属性を引き継がないため、サンドボックスアプリがquarantineなしの任意ファイルをドロップできた
  • XPCクライアントはDesktopServicesPriv.frameworkのObjective-CクラスDSArchiveServiceに既に実装されていた

  • パッチ

    • AppleはmacOS Ventura 13.4で、受信するXPCクライアントのcom.apple.private.ArchiveService.XPC entitlementを検査するよう修正した
    • 当該entitlementがなければXPC接続を拒否する

CVE-2023-32404: ShortcutsFileAccessHelper

  • 脆弱なサービスは/System/Library/PrivateFrameworks/WorkflowKit.framework/XPCServices/ShortcutsFileAccessHelper.xpc
  • このサービスはサンドボックス制限なしで実行可能だったため、App Sandbox脱出に悪用可能だった
  • コード署名にはFull Disk Access用の特別なTCC entitlementも含まれていた
  • そのため、この脆弱性はTCC保護を完全に回避するためにも悪用可能だった
  • このサービスは全てのXPCクライアントを許可していた
  • WFFileAccessHelperProtocolの唯一のメソッドextendAccessToURL:completion:は、XPCクライアントに任意のURLへの読み書き権限を付与するよう設計されていた
    • 内部的にsandbox_extension_issue_file APIを呼び出し、ファイルアクセス用トークンを発行する
    • 任意のURLはサンドボックスXPCクライアントが指定する

  • パッチ

    • AppleはmacOS Ventura 13.4で、受信するXPCクライアントのcom.apple.shortcuts.file-access-helper entitlementを検査するよう修正した
    • 当該entitlementがなければXPC接続を拒否する

CVE-2023-41077: mscamerad-xpc と繰り返されたパッチ回避

  • 脆弱なサービスは /System/Library/Frameworks/ImageCaptureCore.framework/XPCServices/mscamerad-xpc.xpc
  • このサービスはサンドボックス制限なしで実行でき、App Sandbox 脱出に悪用可能だった
  • コード署名には、ユーザープロンプトなしで Photos と Removable Volumes にアクセスできる特別な TCC entitlement があった
  • そのため、この TCC 保護も同時に回避可能だった

  • 脆弱性のフロー

    • デフォルトのサービス名は com.apple.mscamerad-xpc
    • サービスはすべての XPC クライアントを許可する
    • ICXPCDeviceManagerProtocol の openDevice:withReply: は新しい MSCameraDevice を開いて設定する
    • 新しいデバイスの初期化中、カメラデバイス向けのサービスルーチンを提供するために、別の匿名 XPC サービスが開かれる
    • この匿名 XPC サービスもすべての XPC クライアントを許可する
    • ICCameraDeviceProtocol の requestReadDataFromObjectHandle:options:withReply: メソッドは、要求されたファイル項目の内容を読み取り、XPC クライアントに返す
    • 要求ファイルパスは XPC クライアントが制御できるため、サンドボックスアプリはコンテナ外の任意のファイルを読めた
    • サービスの強力な TCC entitlement により、ユーザープロンプトなしでユーザーの Photos も読めた

  • 偽のカメラデバイス構成

    • MSCameraDevice は DMG ファイルを作成してマウントし、エミュレートできた
    • DMG ボリューム内のファイルパスが特定の正規表現と一致すると、ファイル項目は ICCameraFile としてインデックス化される
    • フォルダ名の例: 123abcde, DCIM, dcIm
    • ファイル名の例: abcd1234.mp3, 1234E5678.HEIC
    • サンドボックスアプリは、DMG ファイルをドロップして開き、マウントすることで問題をトリガーできた
    • XPC クライアントは ImageCaptureCore フレームワークにすでに実装されていた

  • パッチと回避

    • Apple は macOS Sonoma 14 で acceptConnection: に新しいチェックを追加した
    • クライアントが com.apple.private.imagecapturecore.authorization_bypass private entitlement を持っていれば許可する
    • または、クライアントが platform binary であれば許可する
    • platform binary 条件は、Apple 署名済みバイナリに動的ライブラリを注入できるため回避可能だった
      • entitlement のない Apple 署名済みバイナリ /bin/ls を選んだ
      • DYLD_INSERT_LIBRARIES 環境変数で、以前の exploit コードを含む dylib を注入した
      • その後、従来どおり XPC サービスと通信した
    • Apple はこの回避報告に CVE-2024-23253 を割り当てた
    • macOS 14.4 では 2 つ目の条件が強化され、XPC クライアントは platform binary であるだけでなく、CS_REQUIRE_LV または CS_FORCED_LV フラグで署名されていなければならなかった
    • このパッチも回避可能だった
      • /bin/ls に dylib を注入した
      • 実行時に csops API で必要なフラグを手動設定した
      • その後 XPC サービスのチェックを通過した
    • Apple はこの 2 回目の回避に CVE-2024-40831 を割り当てた
    • macOS Sequoia 15 では、com.apple.private.imagecapturecore.authorization_bypass private entitlement を持つ XPC クライアントのみを許可するよう再度パッチされた

CVE-2023-42961: intents_helper

  • この脆弱性は iOS でも悪用可能
  • 脆弱なサービスは /System/Library/Frameworks/Intents.framework/XPCServices/intents_helper.xpc
  • サービスはサンドボックス制限なしで実行でき、すべての XPC クライアントを許可する
  • filePathForImageWithFileName 関数の パストラバーサル(path traversal) により、任意パスへのアクセスが可能だった
  • fileName パラメータは XPC クライアントが制御できる任意の文字列

  • 影響を受けるメソッド

    • 脆弱な関数には 2 つの XPC メソッドから到達できた
    • retrieveImageWithIdentifier:completion: は .png 拡張子を持つ任意ファイルを読むために悪用可能
    • 読み取ったデータは INImage インスタンスのメンバー変数に保存され、XPC クライアントに返される
    • purgeImageWithIdentifier:completion: は任意ファイルパスの削除に悪用可能

  • パッチ

    • Apple は macOS Sonoma 14.0 で XPC クライアント入力文字列を正規化するようパッチした
    • パストラバーサルに使われる特殊文字を切り落とした

CVE-2024-27864: diskimagescontroller

  • CVE 項目は執筆時点で公開待ちだった
  • 脆弱なサービスは /System/Library/PrivateFrameworks/DiskImages2.framework/XPCServices/diskimagescontroller.xpc
  • このサービスはコード署名に com.apple.diskimages.creator-uc entitlement を持ち、強力な動作が可能だった
  • この entitlement の主な機能は 2 つある
    • FDA entitlement を持ち、実際の attach 処理を行う /usr/libexec/diskimagesiod と通信する
    • IOKit サービス AppleDiskImagesController に接続し、DMG ファイル用のデバイスを作成して quarantine 処理を行う

  • 脆弱性の原因

    • サービスはすべての XPC クライアントを許可する
    • DIControllerProtocol の attachWithParams:reply: メソッドが攻撃ポイントだった
    • 内部で checkAttachEntitlementWithError を呼び出すが、この関数は名前と違って常に TRUE を返す
    • DiskImages2.framework には、Objective-C クラス DIAttachParams として XPC クライアントがすでに実装されている
    • フレームワークのクライアントコードは、入力 URL が quarantine 状態かどうかを検査する
    • 入力 URL が quarantine 状態なら、attach 前に quarantine パラメータを設定し、このパラメータは XPC サービスに対象デバイスを quarantine 処理するよう伝える
    • 独自の XPC クライアントを作成すれば、quarantine パラメータ設定をスキップして attachWithParams:reply: を直接呼び出せる
    • その結果、quarantine 済みの DMG ファイルを attach しても、対応するデバイスを quarantine 処理しないようにできた

  • パッチ

    • Apple は macOS Sonoma 14.4 で検証ロジックを クライアント側からサーバー側へ移動 した
    • 入力ファイルパスが quarantine 状態なら、サーバーが対応するデバイスを直接 quarantine 処理する

CVE-2023-42977: PerfPowerServicesSignpostReader

  • 脆弱なサービスは /System/Library/PrivateFrameworks/PowerlogCore.framework/XPCServices/PerfPowerServicesSignpostReader.xpc
  • このサービスはサンドボックス制限なしで実行でき、すべての XPC クライアントを許可する
  • XPCSignpostReaderProtocol には 6 つのメソッドがあるが、Apple は submitSignpostDataWithConfig:withReply: だけを実装しており、残り 5 つは空実装である
  • このメソッドの中核ロジックは、ログデータを収集して gzip ファイルとしてアーカイブすること
  • XPC クライアントが制御する tagUUID 文字列により、powerlog パスを任意のパスへハイジャックできた

  • 任意パス削除

    • 関数内部で archiveDirectoryAt:deleteOriginal: を呼び出し、powerlog パスを削除する
    • TagUUID にパストラバーサル文字列を入れると、任意パス削除 primitive を得られる

  • 任意ディレクトリ作成と完全なサンドボックス脱出

    • createSignpostFile: 関数は powerlog パスにディレクトリを作成する
    • これにより quarantine 拡張属性のない任意ディレクトリ を作成できる
    • quarantine のない任意ディレクトリ作成 primitive は、完全なサンドボックス脱出につながり得る
    • 記事では CVE-2023-32364 の手法を使用している
      • quarantine のない .app フォルダを作成
      • Contents/MacOS 配下に /bin/bash symlink を作成
      • LSEnvironment に BASH_ENV を設定
      • open ./poc.app で実行

  • パッチ

    • Apple は macOS Sonoma 14.0 で、XPC クライアントの UUID 文字列を正規化するようにパッチを適用した
    • 入力文字列が 有効な UUID でなければ、関数から抜けるように処理した

反復パターン

  • 中核の攻撃面は System または User domain の XPC サービスではなく、システムおよび private フレームワーク内の PID domain XPC サービス である
  • Service Type が Application の XPC サービスは、フレームワークをロードするだけでサンドボックスアプリの PID domain に登録され得る
  • 脆弱なサービスの多くはサンドボックスクライアントからの呼び出しを想定しておらず、次の検査を欠いていた
    • XPC クライアントの entitlement 検査
    • サンドボックスクライアントかどうかの検査
    • 入力パスの正規化
    • サーバー側での quarantine 状態検証
  • 繰り返し悪用された条件は次のとおり
    • quarantine のないファイル・フォルダのドロップ は、完全なサンドボックス脱出につながり得る
    • 展開中に quarantine 拡張属性が消えると、Gatekeeper 回避とサンドボックス脱出につながり得る
    • Service Sandbox で作成されたファイルは、デフォルトで quarantine 処理されない
  • まだパッチ待ちの報告が 5 件 残っている

App Sandbox と Service Sandbox についての追加意見

  • Apple はある報告について、新たに実行されたアプリケーションは現在のプロセス文脈にはおらず、現在のプロセスの entitlement や権限を共有できないため、expected behavior だと判断した
  • App Sandbox では、ドロップされたファイルはデフォルトで quarantine 処理される
  • Service Sandbox では、ドロップされたファイルはデフォルトで quarantine 処理されない
  • 新たに実行されたプロセスが現在のサービス実行文脈になく、そのサービスの entitlement や privilege を共有しないという点自体は flaw ではないと整理している
  • 逆に、攻撃者がサンドボックス制限されたサービス文脈で RCE を得たあと、新たな非サンドボックスアプリをドロップして実行し、対象サービスのサンドボックス制限を抜けられる点は flaw と見なせる
    • 例として、NSO Group の 0-click exploit の標的だった IMTranscoderAgent が言及されている
  • com.apple.WebDriver.HTTPService.xpc は WBSEnableSandboxStyleFileQuarantine API を手動で呼び出す例として登場する
  • App Sandbox から Service Sandbox へ脱出することは、macOS では事実上 Non Sandbox へ行くことだと整理されている

関連記事

1件のコメント

 
GN⁺ 2024-11-09
Hacker News の意見

  • ここで XPC サービスを一つひとつ個別にパッチする対応は少し奇妙です
    サンドボックス自体の設計問題のように見えますし、アプリ内部向けに見える XPC サービスが、なぜこれほど多くサンドボックス化されたアプリからアクセス可能なのか疑問です

    • その通り。macOS にこれを後から組み込む際、UNIX と NeXTSTEP から引き継いだものを壊さないための妥協である可能性が高いです
      Windows 側にも WinRT サンドボックス、Win32 アプリのサンドボックス、セキュアカーネル、ドライバー保護など似た仕組みは多いですが、複数の構成をまたいで単一の実行ファイルを動かそうとすると、後方互換性の隙間が生まれます
      モバイル OS は後方互換性がなく、実行モデルを強く制限できるので、ずっと簡単な部類です

  • MacOS には、巨大なブロックリストの塊のように見える方式ではなく、capability ベースの Darwin コンテナのようなものが必要です

    • https://github.com/darwin-containers
      https://news.ycombinator.com/item?id=37655477
      デスクトップでうまく機能するセキュリティモデルはありません
      別のコメントにもあるように、iOS は古い残骸がなかったので、筋の通ったセキュリティモデルを提供できました
      一方で Telegram が連絡先と写真全体の共有を要求すると、人々は実際に許可します

  • 良い仕事です
    ただ、こうしたアーキテクチャが正しい方向なのかは疑問です。ある攻撃を防ぐためにセキュリティフレームワークを作るたび、まったく新しい種類の問題が飛び出してくるようで、最終的により安全になったという感覚はありません
    オランダの税法のように、悪用を防ぐためのパッチが延々と積み重なった構造で、すでに意識を獲得しているかもしれません

    • こうしたシステムの多くは、最初から最後まできちんと安全に設計されていないからです
      正しいやり方はたいてい、後方互換性や開発者が機能採用を拒むことのせいで市場では失敗します。WinRT サンドボックスがその例です
      携帯電話のセキュリティは後方互換性を気にする必要がなく、これまでは App Store のゲートキーピングのおかげで、参加したい開発者は従わざるを得なかったので、より簡単でした
    • 結局、セキュリティは後方互換性と両立しにくいです
      現在運用されているすべての OS は、次の世紀まで安全であるためには最初から作り直す必要があり、その過程で大量のコードを捨てる必要があります。それが支払うべきコストです
    • オランダの税法に触れたのは面白いです。その「悪用の穴」の一部は意図的に入れられたと言っても、大きな議論にはならなさそうです
      コンシューマーコンピューティングにも、より多くの脆弱性を押し込もうとする強い勢力があるのではないかと推測できます
      それぞれの有名な例は次の通りです
      https://en.wikipedia.org/wiki/Dutch_Sandwich
      https://en.wikipedia.org/wiki/Intel_Management_Engine#Assert...

  • MacOS、つまり NeXTstep は、最初からオープンで極めて拡張性の高い OSとして作られました
    サードパーティ拡張やフックを追加する方法は数え切れないほどあり、複数のランタイムからソフトウェアへアクセスできたため、当時はこれらすべてが滑らかに連携して動くこと自体が印象的な技術的成果でした
    Java、クラシック Mac、X11、NeXTstep のコードベースが、カーネルの複数の拡張エントリポイントのおかげで問題なく共存して動いていました
    さらにプラットフォームには、アプリ同士が問題なく通信できるようにする API もありました
    しかし Apple は少しずつその哲学から後退し、システムを閉じ続けています。かなり興味深い歩みです

  • SBPL（sandbox profile language）は興味深いです。詳細はこちらにあります: https://github.com/0xbf00/simbple
    macOS の中にこれを処理する Scheme インタプリタがどこかにあるのか気になります
    追記: これを行うのは sandbox-exec のようです。参考: https://reverse.put.as/wp-content/uploads/2011/09/Apple-Sand...

  • 印象的な発見です。記事でも示唆されている通り、似た欠陥がまだ野に残っている可能性は非常に高そうです
    Apple がこうしたサービスを強化するアプローチを再設計しない限り、XPC 関連の CVEは継続的に出てきそうです

  • サンドボックスは好きでもあり嫌いでもあります
    優れた第2防衛線ではありますが、大きな組織はサンドボックスを脱出して意味のあることができない限り、リモートコード実行脆弱性の修正を拒む傾向があります。だからサンドボックスを主防衛線のように使うことになり、それが悲しいです

    • 「サンドボックスを脱出できなければリモートコード実行脆弱性の修正を拒む」というのが誰の話なのか分かりません
      私の知る限り、Apple、Microsoft、Google はいずれもバグバウンティを設けており、サンドボックス脱出にはより大きな報奨金を出しますが、サンドボックスに阻まれる脆弱性にも報奨金は支払います
      攻撃者が、今は使えないリモートコード実行脆弱性をため込んでおき、サンドボックス脱出が見つかったら組み合わせて使うことは、皆よく理解しています

  • 話題から少し外れるが、サンドボックスの専門家で maximum "pattern serialization length" 制限を回避する戦略を知っている人がいれば、この Issue のせいでかなり長いこと頭を悩ませている: https://github.com/NixOS/nix/issues/4119
    残念ながら sandbox-exec はほとんど文書化されておらず、廃止予定だという話もあるので、解決するのがかなり厄介

  • macOS では回避策が際限なく出てくる。この OS はそもそも、こうした 細かな権限 のために設計されたものではないから
    レガシーな Mac OS と NeXTSTEP の技術の上に、後からそのまま載せられるものではない
    セキュリティ研究者ではなく古参のアプリ開発者にすぎない自分でも、直接いくつもの回避策を見つけた。いわば、死体がどこに埋まっているか知っているようなもの
    だが結局、探すのはやめた。Apple のセキュリティ脆弱性報告システムは完全にめちゃくちゃで、できるだけ長く口を封じておくことにしか関心がないように見えた。時間の無駄
    全体として macOS は セキュリティ劇場 の犠牲になったように感じる。弱体化したソフトウェアと終わりのない権限要求で、ユーザーと正当な開発者の双方に被害を与える一方、実際の攻撃者は望めば簡単に回避できる。かつて Apple が Windows Vista をパロディにしたのと似ている

    • この文章を書いた研究者は、かなり多くの穴をクレジット付きでパッチさせることに成功したようだ。ただし、これらの CVE の一部は数年前のものに見える
      企業がバグを修正する時間をできるだけ確保したいというのも、このゲームの一部ではある。他の企業は、発見された脆弱性を本当にできるだけ早く公開してほしいのだろうか。ユーザーがどれだけ早くアップグレードするかは制御できないのだから、公開を遅らせる方がエンドユーザーにとって常によりよく、それは研究者の宣伝欲求より優先されるべきだ
      Apple のサンドボックスアーキテクチャは、通常かなりよく設計されているように見える。今回の場合は、アーキテクチャかコミュニケーションのどこかで問題が起きたようだ
      回避策が存在するのは、デスクトップ OS にあまりにも多くの機能を求めるからでもある。デスクトップ OS はサーバープラットフォームよりはるかに精巧で複雑な OS だと見なせる。Web ブラウザに CVE が多いのも同じ理由だ。セキュリティも欲しいし機能も欲しいので、その両者が衝突する中間地点は必然的に生じる
    • 「レガシーな Mac OS と NeXTSTEP の技術の上に、後からそのまま載せられるものではない」という言葉とは違い、Apple はスタック全体を所有しているので、それは可能だし実際にやってきた
      過去 20 年にわたって macOS のソフトウェアとハードウェアを段階的に強化してきたことが、その証拠だ
      エンドユーザーの多くは気づかないほど段階的だったが、macOS 開発者はメジャーアップデートとマイナーアップデートの双方で対処しなければならないセキュリティ関連の問題を痛感している。例えば次のようなものだ
      https://eclecticlight.co/2024/08/…
      https://eclecticlight.co/2024/08/…
      https://eclecticlight.co/2024/08/…
      https://eclecticlight.co/2024/09/…
    • こうした レガシーの重荷 は、すべての主流 OS にあるように思う
      capability ベースのシステムは存在するが、実際に広く使われているものはない
      解決策が何なのかはよく分からない。それでも、アプリケーションの脆弱性 1 つが即座にユーザーアカウント全体の乗っ取りにつながる状態を放置するよりは、セキュリティを後付けしようとする試みの方がましに見える
    • 「レガシーな Mac OS の上に後から追加できない」なら、SELinux はそれを実現したのに、MacOS を根本的に妨げているものは何なのか？
    • こうした制限の理由は、サードパーティ開発者が Apple 製品と競争しにくくするためだ

  • pid ドメインで見落とされた XPC サービス は、macOS のサンドボックス制限を回避する賢いやり方だ
    権限チェックを避ける dyld インジェクションのトリックも洗練されている
    Apple のパッチはここでは場当たり的に感じられ、サンドボックス継承の動作の仕組みをきちんと見直す必要があるのかもしれない