世界を動かす技術を、日本語で。
b1n4r1b01 / n-days Public Notifications は、 脆弱性情報の通知 を提供するプロジェクト。 通知設定の変更 にはサインインが必要。 GitHubリポジトリ として公開。 Fork数62、Star数386 の人気。 セキュリティ関心者向け情報源。
PoCを脆弱なiPhoneにAirDropしたんだけど、Photosアプリで編集しようとしたらクラッシュしちゃった。
誰かにiMessageで送る必要があるのかな？ただの推測だけど。
彼が提供した画像をダウンロードしたよ（https://www.dpreview.com/sample-galleries/4949897610/pentax-...）。DNGファイルには2FD00に01バイトがあった（xxdやhexdump -Cから）。でも、3E40Bのバイト位置には何もなかった。検索してみたけど、その位置には本当にエントリがない。3E40には02の値があったけど、3E40Bにはなかった。これってタイプミス？再現するためにどこで見つけたの？
このCVEはRCE（リモートコード実行）用だけど、特定のPoCはせいぜいDoS（サービス拒否）に過ぎないってことを覚えておいて。実際にRCEとして使えるようにするには、もっと工夫が必要だよ。
ここに0クリックやRCEはどこにあるの？このCVEのITWエクスプロイトがどう機能したのか、すごく興味ある。OOB書き込みは振り返ってみればかなり明らかだけど、OOB書き込みからiOSでの実行に行くのは今はかなり難しいし、OOB書き込みからサンドボックスを抜け出すのは特に難しいはず。iMessageの画像プレビューは全部BlastDoorの後ろにあると思ってたし。まだまだ面白いことがたくさん抜けてるね。
ここに0クリックやRCEはどこにあるの？ 他のコメントを見てみて。 このバグを使ってRCEを得るエクスプロイトが野生にいるけど、この特定の例はただクラッシュを引き起こすだけだよ。
これがかなり重大だったみたいで、全てのアクティブなApple OSの中で唯一のパッチだったね：macOS Ventura 13.7.8 | macOS Sonoma 14.7.8 | macOS Sequoia 15.6.1 iPadOS 17.7.10 | iPadOS 18.6.2 | iOS 18.6.2 通常はセキュリティアップデートに複数のCVEが含まれるんだけど。例：- https://support.apple.com/en-us/122375 (macOS Ventura 13.7.5) - https://support.apple.com/en-us/122718 (macOS Ventura 13.7.6) - https://support.apple.com/en-us/124151 (macOS Ventura 13.7.7)
watchOSにパッチがないのは驚きだね。iMessageで画像を受け取れるのに。パッチを当てるほど重要じゃないのか、それとも脆弱じゃないのか、まだ野生で利用されてないのか？
iOSの防御のためには、ロックダウンモードを有効にして、毎日再起動して非永続的なマルウェアを排除しよう。https://www.youtube.com/watch?v=fAhTPMmvrB0 > 自分にとってはロックダウンモードだけだよ。それがAppleの体験。iOSバックアップは、このCVE-2025-43300 DNG処理の脆弱性の存在を調べるために、iOSフォレンジック用のOSSツールでスキャンできるよ。https://github.com/msuiche/elegant-bouncer | https://www.msuiche.com/posts/elegantbouncer-when-you-cant-g... ELEGANTBOUNCERは、ファイルベースのモバイルエクスプロイトを検出するツールだよ。野生のサンプルを必要とせず、従来の正規表現やIOCに基づく方法を上回る、先進的なファイルベースの脅威識別のための革新的なアプローチを採用してる。現在は、FORCEDENTRY（CVE-2021-30860）、BLASTPASS（CVE-2023-4863、CVE-2023-41064）、TRIANGULATION（CVE-2023-41990）などのモバイル脆弱性の特定を主にターゲットにしてるよ。[最近追加されたCVE-2025-43300も含む] https://x.com/darknavyorg/status/1959271176062251333 > iOSのITW CVE-2025-43300を再現しているときに、別の古いDNG画像解析の脆弱性を偶然引き起こしちゃった。分析はまだ続いてるよ。
mvtや関連するIOCリポジトリが新しいインジケーターをサポートしてると思ったんだけど、残念ながら見当たらないな。 https://docs.mvt.re/en/latest/iocs/
誰かがそれをファイルシステムから削除してなければ、だけどね。
みんなはどうやってこんなバグを見つけるの？何年も経験を積んで、どこを探せばいいか分かるようになるのかな？
経験 /n ファジング（自動でいろんなことを試すやつ） /n コードのリバースエンジニアリング（ghidraやhopperみたいなツールを使って）
どこに目をつけてテストすればいいか、一般的なエクスプロイト戦術に関してはたくさんの経験があるよ。iOSでエクスプロイトを特定するには、OSの動作や既存のエクスプロイトについてのかなりの知識が必要で、それらをどうつなげて大きなエクスプロイトを作るかが重要なんだ。俺は経験はあまりないけど、他の人がどうやってこれらを特定してエクスプロイトしてるかを読むのはすごく感心する。
ファジングは一つのアプローチだね。「Fuzzing ImageIO」（2020年）、https://googleprojectzero.blogspot.com/2020/04/fuzzing-image... > このブログ記事では、画像フォーマットパーサーの脆弱性という古いタイプの問題を、人気のメッセンジャーアプリのインタラクションなしのコードパスという新しい文脈で議論してる。研究はAppleエコシステムとその提供する画像解析API、ImageIOフレームワークに焦点を当ててた。画像解析コードに複数の脆弱性が見つかり、Appleや関連するオープンソースの画像ライブラリのメンテナに報告され、修正された。この研究の中で、クローズドソースバイナリ用の軽量で低オーバーヘッドなガイド付きファジングアプローチが実装され、このブログ記事とともに公開された。「ImageIO、悪名高いiOSゼロクリック攻撃ベクター」（2024年）、https://r00tkitsmm.github.io/fuzzing/2024/03/29/iOSImageIO.h... > テストヘッダー関数を調べるためにLLDBを使ったら、KTX2やWebP、ETCなどの異なるファイルフォーマット用に新しいテストヘッダー関数が3つあることが分かった。だから、結構新しいからProject Zeroにファジングされてないかもと思って、Project ZeroのハーネスをJackalopeファジングツールに移植したんだ。俺のファジングの結果、いくつかの脆弱性を見つけた（Appleによって修正された）。
俺だけ？iOSって画像処理やデコーダースタックにめっちゃCVEsがある気がするんだけど。そろそろメモリセーフなフレームワークや言語でサンドボックス化してもいいんじゃない？
iMessageの「blastdoor」サンドボックスについて調べてみてね。: https://support.apple.com/guide/security/blastdoor-for-messa...
残念ながら、サンドボックスにもバグがあってRCEを許しちゃうんだよね。これを「フルチェーン」って呼ぶことが多いけど、初期のデコーダーのエクスプロイトとサンドボックスのエスケープエクスプロイトをつなげてフルRCEを得る感じ。
なんか、Appleは自社のOSでRustを使うのに消極的みたいだね。
画像フォーマットは結構安定してるから、検証済みのF*パーサーにはいい候補だと思う。PDFはどれくらい簡単か分からないけど、まずは合理的なサブセットから始めてみるのがいいかも。
AppleはiMessageの事実上のDeviceAndAccountTakeover() APIコールを正式化すべきだね。ゼロクリックが何回あるか数えきれないよ。ティム・クックがプライバシーの高い道を歩もうとしても、コードが腐ってたら意味ないし。 https://citizenlab.ca/2025/06/first-forensic-confirmation-of... https://citizenlab.ca/2023/09/blastpass-nso-group-iphone-zer... https://citizenlab.ca/2021/09/forcedentry-nso-group-imessage... https://citizenlab.ca/2020/12/the-great-ipwn-journalists-hac...
これはiOSだけの問題じゃないし、ちゃんとサンドボックス化してるよ。パーサーは難しいんだ。
https://web.archive.org/web/20250827063813/https%3A%2F%2Fs3....