thegaminggallifreyan/liberationplay-cve-2025-24132-airbourne-pocCVE-2025-24132 (AirBourne) の POC。現在はオーバーフローをトリガーし、クラッシュを引き起こすだけです。
CVE-2025-24132 (AirBourne) のPOCです。現時点ではオーバーフローをトリガーし、クラッシュを引き起こすだけです。
私の車のヘッドユニットへのrootアクセスを試みるため、Oligo Security社が発見したAirplayエクスプロイトCVE-2025-24132（Airbourneと命名）について調査し、学んだすべてをまとめました。
https://www.oligo.security/blog/airborne
これは私の初めてのリバースエンジニアリングプロジェクトです。デバッガを使ったことも、Linuxやコーディングの経験もほとんどなく、プロジェクトの途中までMacOSに触れたこともないまま飛び込みました。CTFから始めるべきだったかもしれませんが…まあいいでしょう。できるかどうか確かめるために、ここ数ヶ月断続的に取り組んできました。
脆弱性のあるバイナリとパッチ済みバイナリのコピーを入手してdiffを取るまでに数ヶ月かかり、さらにエミュレータで実際に動作させるまでにさらに1ヶ月かかりました。
しかし、脆弱なコードはエミュレータでは到達不可能であることが判明しました。それはロジックボード上の物理的なMFiチップとの通信が必要だからです。なぜオーバーフローに到達できないのかと2ヶ月間悩んだ後、問題に気づき、MFiチップの応答チェックをパッチで除去し、本来返されるはずのデータをゴミで埋めることでバイナリを十分にカスタマイズすることができました。これにより、ついにオーバーフローに到達し、実際のシステムでクラッシュを引き起こすのに十分な理解を得ることができました。
オーバーフローはAES CTR暗号化処理内に存在します。SETUPパケットで渡される暗号鍵のサイズはチェックされず、16であると仮定され、16のバッファが作成されます。
これらのクラッシュはほとんど気づかれません。サーバーは通常すぐに再起動して再接続するため、CarPlayシステムでは一瞬の音声途切れや数秒のブラックスクリーンが発生するだけです。まだメモリリークの方法を解明できていないため、現時点ではスタック保護が無効になっているデバイスでのみ有効です。
スタック保護をバイパスするためにメモリをリークする方法を見つける。
これは、いかなる認証も必要としないCarPlayユニットまたはAirPlayユニットに対して機能します。最初にペアリングにPINが必要な場合は、実装されていない追加のペアリング手順があるため機能しません。
Bluetoothベースのデバイスでは、Bluetoothペアリングの面倒な手順をすべて回避するために、代わりにPytoのようなアプリをダウンロードして、私がやったように電話から直接スクリプトを実行することができます。はるかに簡単です。
発見次第、既知のパッチ済みデバイスをここに追加します。
すべてのOnyko AVレシーバーでAirplayをサポートするものは、これに対して脆弱であるはずです。私のテストユニットはTX-NR656で、スタック保護は一切ありません。
ファームウェア3.1より前のCreston DM-NAX-8ZSAユニットは脆弱で、カナリアはありませんが、Airplayプロセスはコンテナ内で実行されます。
Kia CCNCヘッドユニットは適切なスタック保護を備えており、これまでのところそれを破ることはできていませんが、システムログによると、carplayserverはrootとして実行されています。
