Appleの最新Mach-Oアーカイブパーサーで最近公表された整数アンダーフローの脆弱性により、悪意のある静的ライブラリがXcodeのビルドプロセスをクラッシュさせたり、ビルドログを通じてプロセスメモリを露出させたりする可能性があることが分かりました。
この欠陥は、Appleの新しいリンカであるld-primeが使用するパーサーに加え、libtool、ranlib、さらにはdyld_infoといった関連する開発者ツールにも影響します。
Apple Xcodeの整数アンダーフローの欠陥
SecureLayer7のセキュリティ研究者らの報告によると、問題は`mach_o::Archive::Entry::name()`関数にあり、この関数はUnix静的アーカイブ（.aファイル）内の16バイトのファイル名フィールドを解析します。
Cloudsecurity solutions
静的アーカイブは、パッケージマネージャーやベンダーSDK、CIパイプラインを通じてビルド済み依存関係としてダウンロードされることが多いため、この脆弱性はソフトウェアサプライチェーンにとって重大なリスクとなります。
脆弱なコードは、符号なしのsize_t型インデックスを使ってアーカイブメンバー名の末尾のスペースを除去しようとします。攻撃者がスペース文字で埋めた`ar_name`フィールドを与えると、このループはインデックスゼロを超えて減算を続けてしまいます。
安全に処理を終了する代わりに、符号なし値は`SIZE_MAX`にラップアラウンドし、パーサーは本来のアーカイブ名バッファの外側へと逆方向に読み進んでしまいます。その結果、この関数は一見有効に見えるポインタを持つ`std::string_view`を返しますが、その長さは攻撃者が操作可能な、ほぼ最大値に近いものになります。
この破損した長さの値は、その後ツールチェーンの通常のエラー処理や文字列処理の経路に到達し、以下の3つの結果のいずれかを引き起こします。
- リンカのフォーマット処理コードが`strlen()`を呼び出し、マッピングされたアーカイブファイルを超えて読み込むことで発生する、決定論的な`SIGSEGV`。
- 隣接するメモリマッピングのバイト列を標準エラー出力に出力する可能性のある、範囲外読み取り。
- 途方もなく大きな`std::string`の割り当てを試みた結果、捕捉されない`std::bad_alloc`が発生し、libtoolやranlibで`SIGABRT`が起きるケース。
研究者らは、小さく細工した.aファイルを使ってこの問題を実証しました。彼らが強調しているのは、アーカイブは実行可能コードではなくデータであるという点です。つまり、このペイロードはリンクやアーカイブ処理の入力として受け入れられさえすればよく、プログラムとしてコンパイル・実行される必要はありません。
Appleのmach_oライブラリは、オープンソースのdyldプロジェクトの一部であり、Xcodeおよびコマンドラインツールに付属する最新のツールチェーンで使用されています。
SecureLayer7によると、ld-primeはXcode 15以降、arm64、arm64e、x86_64向けビルドのデフォルトリンカとなっています。一方、libtoolとranlibも、同じパーサーを使用する開発者ツールのバージョンを呼び出しています。
従来のld-classicリンカは、報告によれば別系統の古いアーカイブ解析コードを使用しており、今回の脆弱性の影響を受けません。
この違いにより、レガシーリンカの使用が技術的に可能なチームにとっては一時的な互換性上の選択肢が生まれる可能性がありますが、組織はリンカ設定を変更する前に、ビルドおよびセキュリティへの影響を検証すべきです。
主な懸念は自動化されたビルド環境にあります。サードパーティ製SDKやバイナリ依存関係、ベンダー提供のフレームワーク、あるいは推移的なパッケージに埋め込まれた不正なアーカイブが、開発者のワークステーションやCIランナーで処理される可能性があるためです。
クラッシュはリリースを妨げる恐れがある一方、機密性の高いメモリ情報がCIログに出力されれば、重大な機密性リスクをもたらしかねません。
開示と対策
SecureLayer7はこの問題をApple Product Securityに2026年5月23日に報告しましたが、90日以上経過しても公開パッチが提供されていないと指摘しています。報告書によれば、Appleはこの発見を「限定的なローカルへの影響」があるものと位置づけたとのことです。
Cloudsecurity solutions
これは研究者側の説明であり、確認した資料の範囲では、Appleはこの件に関してXcode向けの正式なセキュリティ勧告を公表していません。
Appleが修正版をリリースするまでの間、開発チームやDevSecOpsチームは、信頼できない静的アーカイブを高リスクのビルド入力として扱い、以下の推奨事項に従うべきです。
- ビルド済みの
.a依存関係についてはバージョンを固定し、チェックサムを検証する。 - 可能な限り、レビュー済みのソースからの再現可能なビルドを優先する。
- 特にプルリクエストや外部フォークからのCIにおける依存関係の取り込みを制限する。
- ビルドは、権限を最小限に抑え、ログへのアクセスを制限した、隔離された短命なワーカー上で実行する。
ld、libtool、ranlib、EXC_BAD_ACCESSに関連するビルド失敗や、異常なメモリ割り当てエラーを監視する。
Appleが公開しているdyldリポジトリには、影響を受けるアーカイブパーサーを維持する最新のC++コードベースが含まれています。
アクティブなマルウェアやフィッシングの発生から24時間以内に、SOCを最新の状態に保ちましょう。 ANYRUNを試して、早期検知でインシデントを防止しましょう。
翻訳元: https://gbhackers.com/apple-xcode-integer-underflow-flaw/
