- tachy0n は iOS 13.0〜13.5 向けの 最後期の 0day 脱獄エクスプロイト の公開事例
- このバグは Lightspeed と呼ばれる
lio_listio システムコールの競合状態 (race condition) で、カーネル LPE（権限昇格）脆弱性の悪用にあたる
- Spice や unc0ver など複数の脱獄プロジェクトでこの脆弱性が実際に活用された事例があり、脆弱性の利用方法とメモリ管理まわりのハッキング手法を説明している
- Apple はこの exploit が公開された後、パッチ適用とリグレッションテストの導入、さらに強力なカーネルオブジェクト分離（Zone、kheap など）とポインタ保護機能の大幅強化を行った
- その後 iOS 14 以降では脱獄・カーネル exploit の環境が根本的に変化し、公開されたカーネル exploit がもはや存在しない状況 となっている
0. 序論
- tachy0n は iOS 13.0 から 13.5 までに適用される旧世代の exploit
- 2020年5月23日に unc0ver v5.0.0 で 0day として公開され、わずか 1 週間で Apple が緊急パッチを適用した
- この脆弱性は以前に 1day として活用された経緯もあり、exploit 手法の観点からも意義ある事例と評価されている
- 脆弱性のソースと発見経緯を詳しく解説する記事
1. Lightspeed
- この脆弱性は Synacktiv が公表した Lightspeed バグ（CVE-2020-9859 など） で、
lio_listio syscall における非同期 I/O コンテキストのメモリ解放時に競合状態の問題が発生する
- メモリのダブルフリー条件を作るために I/O 演算のタイミングを調整し、2回のオブジェクト解放によって同じメモリ領域に複数のオブジェクトを重ねて利用できる
- カーネルの
kalloc.16 ゾーンにおける動的メモリ割り当て構造を exploit に活用している
- 本質的には競合レースを何度も繰り返して成功確率を高める方法
2. Spice
- この exploit は過去に team Jake Blair が制作した Spice 脱獄で使われた
- racoon と app でそれぞれ異なる exploit 変種を実装しており、主な目標は mach ポートの偽造
- iOS 11.x 当時は PAN（Protection Against Null dereference）の回避が容易で、カーネル infoleak や sandbox escape と組み合わせた多様なハッキング手法が試みられた
- racoon の場合は IOKit へのアクセス制限があるため、OSUnserializeXML を使ってカーネルの対象ゾーンへの spray 用オブジェクトを生成した
- sysctl_procargsx、カーネルの uninitialized memory leak、sandbox ポリシーなどの細かな差異と、その後の技術的発展についても記述されている
3. unc0ver
- unc0ver への適用時には A8〜A13 を含む広範な SoC で動作するよう exploit 構造が設計された
- OSData オブジェクト のネストとオーバーラップの追跡を行い、適切なタイミングで目的のオブジェクトを解放・割り当てしてメモリ領域を制御する
- IOMemoryDescriptor のようなカーネルオブジェクトを利用し、ユーザーが制御するデータバッファのアドレスを露出させ、カーネルからの直接読み書きを実装する
- zone_require の回避など、iOS 13 のカーネルメモリアロケータ方針の弱点を適切に利用している
- exploit 全体の構造は公開 GitHub リポジトリ（tachy0n）で詳細実装を確認できる
4. その後の影響
- 0day exploit の公開はセキュリティコミュニティと Apple に大きな反響を与えた
- 実 exploit の公開から 4 時間で Project Zero と Synacktiv が詳細分析と対応を行った
- Apple はパッチ適用後、この脆弱性に対する正式なリグレッションテストを XNU に追加するなど、根本的なセキュリティ戦略強化 へと方針を転換した
- iOS 14 以降では allocation 領域の分離、オブジェクトセキュアガード、PAC（ポインタ認証コード）、kheap 構造など、exploit 作成難度を大きく引き上げる大規模な変更が導入された
- いまでは exploit 戦略そのものがより重視されるようになり、公開情報と非公開研究の格差が拡大し、iOS 17〜18 については公開カーネル exploit がまったく存在しないのが実情である
5. 結論
- iOS セキュリティ／脱獄分野が 5 年で劇的に変化 したことを明確に示す事例
- 脱獄／exploit コミュニティ、研究者、そして Apple の技術的な方向性がどのように変化したかについて洞察を与える
- IL を共有し挑戦していた時代はすでに過去のものとなり、iOS 14 以降では exploit 情報の共有は著しく縮小している
参考および問い合わせ
2件のコメント
Appleのハードウェアは素晴らしいですが、ソフトウェアはユーザーを縛り付けようという意図に満ちています。
自分で作ってビルドしたアプリを自分の端末でだけ動かそうとしても、100ドルのサブスクリプションが必要です。
中小規模のオープンソースアプリを使い、自分でビルドして利用する開発者なら、
Appleの端末で脆弱性を突いて脱獄しながらサイドロードするくらいなら、ただAndroidを使うほうが楽です。
Hacker Newsの意見
SockPuppetは過去にもiOS 12時代の脱獄に使われており、Project ZeroのNed WilliamsonがAppleに報告してiOS 12.3で修正された後も、再びiOS 12.4で再登場したことに言及。
おそらくAppleがXNUを別ブランチにフォークする際にそのパッチを取りこぼしたようで、根本的にはこうした新旧の脆弱性に対する回帰テストがまったく無かったことが大きな問題。
自分でも既知の1-day脆弱性をいくつか回帰テストとして自動化して回してみたところ、すぐに脆弱性をうまく見つけられたという。
このような形でLinux、FreeBSD、OpenWRT、OpenSSHなどさまざまなオープンソースプロジェクトでも、新しいバージョンに対して過去の脆弱性の回帰テストを回しているのか気になる。
各脆弱性を自動化された形で記述し、CIでリソースを投入して実行できる体制さえあれば、十分に見合う効果があるはずだという考え。
20年前の大学時代、MozillaでボランティアのQA活動をしていたときに、何百もの回帰テスト事例があった経験を共有。
主にレンダリング／レイアウト、JSエンジンのバグが多く、最小化したテストケースを作ればCIパイプラインにすぐ追加できる構造だった。
バグそのものは避けられないが、すでに直したバグが再び現れるのは時間とコストの無駄として最悪であり、品質を重視する組織は必ず回帰テストに多く投資するものだと見る。
残念ながらQAを軽視したり、外注だけで済ませてまともに気を配らない組織も多い。
Appleが脱獄関連で回帰テストを持っていなかったという点は理解できない。
以前からMozillaなどではTinderboxやBugzillaのようなツールを活用して優れたQAおよびCI/CD環境を構築しており、DevOpsという概念が広まる前からこうしたやり方は一般的だと思っていたが、実際にはそうではなかったと後になって知った。
何千ものテストケースがあり、Sqliteだった気がする。
パッチをバックポートしなければ、そのテストも一緒にバックポートされない可能性が高いという点を付け加えている。
結局のところコンウェイの法則（Conway's law）が、セキュリティと機能開発の間にもそのまま当てはまる。
そのため、ビルド／リリース手順に回帰テストがしっかり整っている組織であっても、内部の組織構造ゆえにセキュリティ関連の問題が漏れる可能性が高くなる。
情報機関（G10、ロシア、中国、北朝鮮など）や多くの民間グループは、当然この方法で脆弱性の回帰テストをしているはずだという意見。
友人と外国語で会話していて、次の瞬間に脳外科手術や核物理学のような専門的な話題に移ったら頭が真っ白になる状況にたとえている。
以前、製鉄所の修理に関する会話を通訳しようとした記憶を思い出す。
脱獄が消えつつある現実は残念で、脱獄したiPadを特別有効活用していたわけではないが、それ自体が楽しかったという経験。
今ならテザリングアプリやUTM、JITソリューションを入れたい。
SideStoreは有望そうなので試してみたいが、自分のAppleアカウントは過去に有料デベロッパーアカウントだったうえ、10個のApp IDが失効していないため、その種のアプリのインストールに制約がかかる。
新しいアカウントを作るか、再び料金を払わないと無理。
脱獄なしではiPhoneをメイン端末として使う理由がまったくなく、結局Androidに移った。
その頃にはAndroidが基本機能の面でかなり追いついていた時期だった。
仲介ブローカーを通す必要があるのか、公式のメールや窓口があるのか、単に一次サポートで埋もれてしまう心配はないのかと質問。
記事で触れられているように、いまもプライベートコミュニティでは脆弱性が保有されており、Appleは修正を続けている。
減ったのは一般公開される脱獄だけだ。