- macOS Calendar の招待添付ファイル処理の欠陥により、攻撃者は Calendar サンドボックス内で任意ファイルの書き込み・削除 を行うことができ、この問題はリモートコード実行と Photos データへのアクセスのチェーンにつながった
- 第1段階の CVE-2022-46723 では、ATTACH セクションの
FILENAME=../../../PoC.txt のようなパストラバーサル入力を適切に正規化しなかったため、添付ファイルが意図した場所の外に保存される可能性があった
- リモートコード実行チェーンは、Monterey から Ventura へのアップグレード過程における Calendar の Open File 動作を利用し、複数のファイルを注入して DMG・SMB マウント・カスタム URL スキームを組み合わせた
- Photos 段階では、
defaults import で悪意ある設定を適用し、System Photo Library を /var/tmp/mypictures/Syndication.photoslibrary に変更して、iCloud のオリジナル写真が TCC で保護されないディレクトリに同期されるようにした
- Apple は 2022年10月から 2023年9月にかけて関連する脆弱性をすべて修正しており、Photos の脆弱性は CVE-2023-40434、Gatekeeper バイパスは CVE-2023-40433 として扱われた
Calendar 添付ファイルのパストラバーサル
- 悪意ある Calendar 招待にはファイル添付を含めることができ、添付ファイル名の検証不足により ディレクトリトラバーサル が可能だった
- 攻撃者は ATTACH セクションで
FILENAME=../../../PoC.txt のように任意のパスを指定できた
- 通常の保存先は
~/Library/Calendar/[CalendarID]/Attachments/[eventid]/
- 脆弱な動作ではファイルが
~/Library/Calendar/PoC.txt に保存された
- すでに同名ファイルがある場合、新しいファイルは
PoC.txt-2 として保存されるが、その後攻撃者が送ったイベントや添付が削除されると、元の名前の PoC.txt が削除される可能性があった
- この動作は、ファイルシステム上の Calendar サンドボックス 内で既存ファイルを削除するためにも利用できた
- この脆弱性は少なくとも macOS Monterey 12.5 最新版に存在し、macOS 13.0 beta4 ではもはや脆弱ではないことが確認された
リモートコード実行へ拡張したチェーン
- macOS Ventura のリリース直前に発見された脆弱性は、バージョンアップグレードの過程と Calendar の Open File 機能を利用してリモートコード実行へと拡張された
- 攻撃者は Calendar の任意ファイル書き込み脆弱性で複数のファイルを注入し、Monterey から Ventura にアップグレードされる際に RCE チェーンが動作するよう構成した
-
注入ファイルの構成
000Hacked-$RANDOM.calendar
- 「Siri Suggested」Calendar のように見える Calendar データが含まれている
- 繰り返しイベントと通知機能を含み、ほかの注入ファイルを開くように動作する
CalendarTruthFileMigrationInProgress
- 既存の Calendar が古い形式から新しいデータベースへアップグレード・マージされるようにするファイル
CalPoCInit.dmg
- 最初の Calendar 通知が
~/Library/Calendars/CalPoCInit.dmg を開くようにする
- DMG 内の
.DS_Store の Bookmark が、外部 Samba サーバーの背景画像参照を含んでいる
CalPoCInit.dmg 自体が隔離状態でも、マウントは quarantine flag なしで行われる
stage1.url
- 2番目の Calendar 通知が
~/Library/Calendars/stage1.url を開くようにする
- このファイルには、前段階でマウントされた Samba ボリューム内のアプリを指す
file:///Volumes/CalPoCPayload/MyMidiTest.app URL が含まれている
- Finder が
/Volumes/CalPoCPayload/ を開くとインデックス作成が自動で行われ、MyMidiTest.app がインデックスされる
- アプリバンドルの
Info.plist は mymiditest カスタム URL スキームハンドラを登録する
stage2.url
- 3番目の Calendar 通知が
~/Library/Calendar/stage2.url を開くようにする
- このファイルは
mymiditest:// を参照し、ユーザー操作なしに悪意あるアプリを実行する
Gatekeeper バイパスとアプリ実行
mymiditest:// を実行できた理由は、アプリが exploit によって作成された Samba マウント内にあり、その場所に quarantine flag がなかったためであるmymiditest アプリは第3段階に必要なファイルを /var/tmp/ に書き込み、open /var/tmp/PhotosPoC.sh で Terminal からスクリプトを実行する- 全体のチェーンは、Calendar サンドボックスを抜けるために複数のファイルを注入し、SMB トリックで Gatekeeper 緩和策 を回避したうえで任意コードを実行するよう構成されていた
Photos 設定変更による iCloud 写真へのアクセス
- リモートコード実行後の段階は、Photos の設定を変更して、ユーザーの機微な写真データ、特に iCloud Photos にアクセスすることに焦点を当てていた
- 通常、Photos のような機微ファイルへのアクセスは TCC により制限されるべきだが、Photos の設定を変更すると、System Photo Library が TCC で保護されていないパスを指せてしまった
- 攻撃者は別の System Photo Library を使う Photos 設定ファイルを作成し、それを
defaults import で取り込むことができた
- PoC チェーンでは、第2段階が
/var/tmp/mypictures/Syndication.photoslibrary を System Photo Library として使う設定を自動で準備する
- 関連する悪意ある設定ファイルは
/var/tmp/mypictures/*.plist に生成される
- 実行中の Photos 関連アプリケーションを終了する
- 元の設定は
/var/tmp/mypictures/*-orig.plist にバックアップされる
- 悪意ある設定は
/var/tmp/mypictures/ から取り込まれる
- 新しい写真ライブラリは
open /var/tmp/mypictures/Syndication.photoslibrary で Photos から開かれる
Syndication.photoslibrary は空のテンプレートライブラリであり、新しい System Photo Library として Photos が起動すると iCloud 同期が有効になり、オリジナルファイルが保護されていないディレクトリにダウンロードされる- ディスクに同期されたファイルは
/var/tmp/PoCLoot$RANDOM/ 配下の新しいディレクトリにコピーされる
- PoC は簡単な修正だけで、データを外部リソースへコピーしたり
curl コマンドで外部 Web サーバーへ送信したりできた
修正スケジュールと未解決のバウンティ問題
- 全体のチェーンは macOS のセキュリティ障壁を順に突破する必要があった
- Calendar に複数のファイルを注入してサンドボックスを回避し、次の段階を有効化する
- SMB トリックで Gatekeeper 緩和策を回避し、任意コードを実行する
- TCC 保護を回避して iCloud Photos のような機微データにアクセスする
- 修正前は、悪意ある Calendar 招待を Apple iCloud ユーザー に送ることで、ユーザー操作なしに iCloud Photos を盗み出せた
- Apple は 2022年10月から 2023年9月の間に関連する脆弱性をすべて修正した
-
タイムライン
- 2022-08-08: Calendar サンドボックス内の任意ファイル書き込み・削除を報告
- 2022-10-24: macOS Monterey 12.6.1 および Ventura 13 で修正
- この項目には CVE はなく、Ventura beta3 は脆弱だった
- 2022-11-14: Calendar 脆弱性を任意コード実行と Gatekeeper バイパスへ拡張する PoC を提出
- 2022-12-04: iCloud Photos アクセス PoC を提出
- 2023-02-20: Calendar 脆弱性に CVE-2022-46723 のクレジットと CVE が追加
- 2023-03-27: Gatekeeper バイパスが macOS Ventura 13.3 で修正
- 2023-09-26: Photos 脆弱性 CVE-2023-40434 が修正され、クレジットが付与
- 2023-10-09: Gatekeeper バイパスと Photos 脆弱性に関するバグバウンティを発表
- 2023-12-21: Gatekeeper バイパスに CVE-2023-40433 のクレジットが付与
- 2024-09-12: 元の Calendar 任意ファイル書き込み・削除脆弱性 CVE-2022-46723 に関するバウンティは依然としてなし
- 2024-10-20 更新: Apple は、CVE-2022-46723 の Calendar 任意ファイル書き込み・削除脆弱性は macOS Monterey のみに影響し、Ventura ではすでにベータ段階でこの問題がなかったため、バウンティ対象ではないと判断した
1件のコメント
Hacker News のコメント
iCloud Photo Library を使っていなくてよかったが、写真ライブラリの場所を変えると新しい場所がまったく保護されないというのはおかしい
/var/tmp/mypictures/Syndication.photoslibraryをシステム写真ライブラリに指定して Photos を開けば、Photos アプリがこのディレクトリを保護するはずなので、エクスプロイトは失敗すると予想していたSonoma 14.6.1 でざっと試したところ、Option キーを押しながら Photos を開いて
~/Picturesに新しい写真ライブラリを作ると、フルディスクアクセス権限も写真権限もないアプリはそのフォルダへのアクセスを拒否されたところが新しい写真ライブラリを
/tmpに作ると、同じアプリがアクセスできた。この挙動は混乱を招き、一貫性がないApple が写真ライブラリをファイルシステム上のどこにでも移動できる機能を本当にサポートするなら、保護も適切に適用すべきだ
/tmpは歴史的に、ディレクトリ階層の中で誰でも読み書きできる場所であり、非公開データを保存するには適切な選択ではないAppArmor や Firejail がなくても、ほとんどのサービスはデフォルトで専用の一時ディレクトリを与えられる
このスレッドではバグ報奨金の支払いについての話が多いが、常設の報奨金プログラムを運営している巨大テック企業が報奨金を払わないなら、たいていはそれなりの理由がある可能性が高い
こうしたプログラムのインセンティブは、正当な提出に報奨金を支払う方向にほぼすべてそろっている
まれにインセンティブがかなりうまく整合している例であり、企業は特定の種類の研究を奨励しようとして報奨金プログラムを作るので、正当な報奨を支払わないことはその目的に反する
ベンダー側の担当者が自腹を切るわけでもなく、金額も会社にとっては意味のある規模ではない
通常、プログラム運営チームのメンバーは報奨金を減らすよりも、より多く支払うように動機づけられている
最近SWEプログラムオフィスからSEAR（security engineering & arch）に移され、マネージャーも最近追い出されてAirBNBへ行った
チームメンバーの大半は新卒レベルのICT2・ICT3で、社内の他部署のコーディング面接にも通らないような人たちであり、主にバグの分類担当のように働いている
コンピュータの前で働く時間より、カンファレンスに行ってハッカーたちと交流する時間のほうが多い
「調査中」ポータルのグラフは上がり続けるばかりで、メールがたまる一方なのに追いつこうとする試みすらしていない状態だ
報奨金を受け取るべきなのに受け取れていない人たちは、進展を見たいならTwitterでSEAR責任者のIvanを公然と圧迫する必要がある
しかしセキュリティ研究者や一般の人々にとって、それは重要だろうか？ いいや。壊れている理由に関係なく、Appleは報奨金プログラムを直すべきだ
結局、このブログ記事も、すでに大きな山に積み上がっているもう1つの例にすぎない[1][2][3][4][5]
1: https://arstechnica.com/information-technology/2021/09/three...
2: https://mjtsai.com/blog/2021/07/13/more-trouble-with-the-app...
3: https://medium.com/macoclock/apple-security-bounty-a-persona...
4: https://theevilbit.github.io/posts/experiences_with_asb/
5: https://shail-official.medium.com/accessing-apples-internal-...
好意的に見ても典型的な遅い官僚主義のようで、それはあまり良い理由ではない
会社が本当にこうしたものを奨励しているなら、承認に1年以上かかる理由はない
論理としては正しいかもしれないが、こうした状況を見ると、「会社がけち、あるいはほとんどすべての他の状況でいつもそうであるように過度に官僚的だ」という説明のほうが、「見たところ条件を満たしている報奨金を支払わない正当な理由がある」という説明よりあり得ない、とは考えにくい
投稿者が出来事を正確に描写しているなら、他のあらゆる場所で働いているインセンティブがこの領域にも染み出してきた、というほうがはるかにあり得そうに見える
そのうち1つは副作用なしにコード1行で直せるのに、2年たっても未解決のままだ
Appleのセキュリティチームは関心がないか無能かのどちらかで、どちらにしても良くない
コンピューティングで経験した中でも、最も腹立たしくもどかしい出来事の1つだった
問題を公に共有しないでほしいと明確に望んでいる一方で、無期限に引き延ばすばかりだ
正直、限界に近づいている
報奨金などどうでもよく、ただバグが直ってほしいだけだ
事案を真剣に扱っていると信じられるなら最大限の猶予を与えるが、そう信じるのは難しい
事後に参加ルールを変えたり、セキュリティ研究者を進行中の報奨金プログラムからひそかに締め出したり、善意の公開を捜査機関に回したり、管理者たちが極めて狭量に振る舞ったりする、といった具合だ
「会社にとって金額は意味がない」という点のせいで、むしろこうしたずさんな処理はいっそう理解しにくい
検疫フラグをいじるまた別の方法だね。もう1つはこのリンク: https://imlzq.com/apple/macos/2024/08/24/Unveiling-Mac-Secur...
あまりにも多くの異なるシステムがこの検疫フラグを変更できるように見える
「攻撃者はファイル添付を含む悪意のあるカレンダー招待を被害者に送信できる…修正前は、任意の Apple iCloud ユーザーに悪意のあるカレンダー招待を送り、ユーザー操作なしで iCloud Photos を盗むことができた。」
この範囲ってどの程度なの？ macOS のどこからでも、誰でも iCloud を使っている相手に任意の招待を送れるということ？ そんなことを望まない人がいる？
カレンダー招待は昔からスパムの温床だったので、脆弱性もあると言われても驚きはない
「攻撃者が指定したファイルがすでに存在する場合、指定されたファイルは
PoC.txt-2という名前で保存される。しかし、攻撃者が送ったイベント／添付ファイルが後で削除されると、元の名前のファイル（PoC.txt）が削除される。この脆弱性は、ファイルシステムの『サンドボックス』内部にある既存ファイルを削除するために使われ得る。」これはひどいエンジニアリングだ
ここの報奨金の状況はあまり気に入らない。セキュリティ研究者の立場では、Apple やほかの FAANG 級企業でこれほど長く待たされるのはよくあることなの？
第1段階だけでもとんでもない脆弱性だ。Apple はどうしてこれを考慮しなかったのだろう？
「攻撃者は
ATTACHセクションでFILENAME=../../../PoC.txtのようにファイルへの任意パスを設定し、ディレクトリトラバーサル攻撃を成功させることができる。」特にコードレビュアーもそのライブラリを知らない場合、最初から安全でない形で再実装するのを防ぐのは難しい
こうした問題に対する現代的な解決策はあるのだろうか？
大規模な非メモリ安全性のセキュリティホールが出るたびに、妙にわくわくする
ちょっと意地が悪いのは分かっているけど、Rust に注ぎ込まれたすべての時間とエネルギーが、結局パストラバーサルバグ一つで台無しになるという構図が好きだ
Lockdown Mode はこれを防ぐの？
以前のゼロクリック画像添付関連のエクスプロイトを考えると、Lockdown Mode はそういうものを防ぐために作られたように見えるし、すべてのファイルがその方式で扱われそうだ
うわ。かなり古典的なエクスプロイトだね
ファイル名内のパスみたいなものは、10年くらい前に読んだ記憶がある