iLeakage: Appleデバイスに対するブラウザベースのタイマーレス投機的実行攻撃
(ileakage.com)- Spectreの緩和策が約6年にわたり続けられてきたものの、iLeakageはMac・iPad・iPhoneのSafariで、投機的実行サイドチャネルがなお悪用され得ることを示す
- 攻撃者はユーザーを悪意あるWebページに誘導してクリックさせた後、JavaScriptとWebAssemblyでSafariに任意のWebページをレンダリングさせ、機密情報を復元できる
- デモには、Gmailの最近のメッセージ件名、Instagramの自動入力認証情報、YouTubeの視聴履歴、Apple M3搭載MacBook ProでのFacebookパスワードとSMS 2FAトークンの復元が含まれる
- 影響範囲はApple A-series・M-series CPUを使うmacOS・iOSデバイスで、Safari 17.2を含むiOS 17.2とmacOS 14.2で緩和された
- Lockdown ModeやJavaScriptの無効化でも防げるが機能上の制約があり、Safari内で実行されシステムログに痕跡を残さないため検出は非常に難しい
Appleデバイスで再び明らかになったSpectreリスク
- iLeakageはSafari Webブラウザを対象とする投機的実行サイドチャネル攻撃である
- 対象はAppleのA-seriesまたはM-series CPUを使用するmacOS・iOSデバイスである
- 最近のiPhoneとiPadが含まれる
- 2020年以降のAppleノートPCとデスクトップも含まれる
- 本来、あるブラウザタブのコードは別タブの内容を推測できないはずだが、iLeakageは攻撃者のページを訪問してクリックしたユーザーの対象Webページの内容を読み取れる
- 復元可能な情報には個人情報、パスワード、クレジットカード情報が含まれ得る
- 研究者らは2022年9月12日にAppleへ結果を開示しており、これは一般公開の408日前だった
実際に復元された機密データ
- 研究者らは一般的なサービスから高価値情報を復元する事例をデモした
-
Instagram認証情報
- macOS Safariで、ユーザーがLastPassの自動入力認証情報マネージャーを使ってInstagramにログインする状況を用いた
-
Gmail受信トレイ
- iOS SafariでユーザーがGoogleにログイン済みの状態だと仮定し、iPad上でGmailアカウントの最近のメッセージ件名を復元した
-
YouTube視聴履歴
- iOS版ChromeでYouTube視聴履歴を復元した
- iOS版ChromeはApple App Storeのポリシーにより、Safariブラウジングエンジン上のシェルとして動作する
-
Facebookパスワードと2FAトークン
- Apple M3チップを搭載したMacBook Pro、macOS 14.1.1、Safari 17.1環境で、まずFacebookパスワードを復元した
- その後、Androidスマートフォンに送信されたSMS 2FAトークンをGoogle Messages経由で復元した
Spectreとサイドチャネルの動作方式
- ほとんどの現代的なCPUは、分岐結果がすぐに出ないときに実行経路を予測し、その経路の命令を先に処理する投機的実行を使用する
- 予測が外れるとCPUは状態変更を巻き戻すが、キャッシュのようなマイクロアーキテクチャ状態には痕跡が残ることがある
- Spectreは、この痕跡を利用して、本来のプログラムの意味上アクセスできないデータを読み取るハードウェア脆弱性である
- サイドチャネルは、プログラムが安全なアルゴリズムを実行していても、システム実装の特性を悪用できる
- 例として音、電磁放射、熱スロットリング、CPUマイクロアーキテクチャ資源の共有がある
- 攻撃者と対象が同じCPU上で実行されると、コア、キャッシュ、内部バッファなどの資源を共有し、この競合はタイミングや消費電力といった変数を通じて間接的に測定できる
Safariの防御を回避したタイマーレス攻撃構成
- ブラウザベンダーはSpectre以降、投機的実行・一時的実行攻撃への防御を強化してきた
- Safariの防御には35-bit addressing、value poisoning、タブごとのプロセス分離ポリシー、低解像度タイマーが含まれる
- iLeakageはApple Silicon CPUとSafariを対象にした初の投機的実行攻撃デモである
- 攻撃は、Apple CPUの公開されていないキャッシュ構成を実証的に復元するところから始まる
- その後、低解像度タイマーだけでキャッシュヒットとミスを区別するspeculationベースのガジェットを作る
- タイマーを使わずrace conditionを活用する変種もデモした
- このガジェットはeviction set生成テストとcovert channelの両方に使用される
- 手法をSafariへ移植した後は、CPUが投機的実行中のときに、Safariが特定データ型用のコードを攻撃者が作った誤った型のオブジェクトに対して実行するよう仕向ける
- 最終的にSafariレンダリングプロセスのアドレス空間のどこからでもout-of-bounds readが可能になる
- 異なるドメインのWebサイトを同じアドレス空間へ統合する新たな方法と組み合わせ、機密情報を漏えいさせるspeculative type confusion攻撃を実行する
緩和策、検出の難しさ、ブラウザ別の影響
- iLeakageはSafari 17.2で緩和されており、Safari 17.2はiOS 17.2とmacOS 14.2に含まれる
- 対応策はAppleデバイスを最新OSバージョンへ更新することである
- Lockdown ModeはSafariのJITコンパイルを無効化し、iLeakageを緩和する
- JITコンパイルはiLeakageが攻撃プリミティブを作るために使う性能機能である
- Lockdown Modeは一部のメッセージ添付ファイルや不明なFaceTime通話をブロックするなど、デバイスの動作を変える可能性がある
- 全リストはAppleのLockdown Mode文書にある
- JavaScriptの無効化もiLeakageを防ぐが、Safariが一部Webサイトを誤って、または不完全にレンダリングする可能性があり、オンライン決済のような高度なWeb機能が動作しない場合がある
- iLeakageはSafari内で実行され、システムログファイルに痕跡を残さないため検出は非常に難しい
- ただし、攻撃者のWebページを訪問した痕跡は、最近訪問したページに関するブラウザキャッシュに残る可能性がある
- 実際に悪用された証拠はない
- エンドツーエンドの攻撃構成は非常に難しく、ブラウザベースのサイドチャネル攻撃とSafari実装に関する高度な知識が必要である
- 認証情報マネージャーは引き続き使用することが推奨される
- iLeakageはWebページに自動入力された認証情報を復元できる
- 多くのプラットフォームでは、自動入力が行われるためにユーザー操作を要求する
- macOSのChrome、Firefox、Microsoft Edgeは別のJavaScriptエンジンを使用するため、Safari JavaScriptエンジンの特殊性を悪用するiLeakageは動作しない
- iOSではApple App Storeとサンドボックス化ポリシーのため、他のブラウザアプリもSafari JavaScriptエンジンを使用する
- iOS版Chrome、Firefox、Edgeは、ブックマークや設定同期のような補助機能を提供するSafari上のラッパーである
- App StoreのほぼすべてのブラウザアプリケーションがiLeakageに対して脆弱である
- 学術論文はiLeakage paperとして提供されており、2023 ACM Conference on Computer and Communications Securityに掲載された
1件のコメント
Hacker Newsの意見
このFAQには抜けている点があるように見える。これがWebKitの脆弱性なのかSafariの脆弱性なのか、モバイルSafariには該当する開発者設定がないがLockdown Modeを有効にすると緩和されるのか、Appleにはいつ開示したのかが気になる
その後ページが更新され、最後の質問には回答が追加された。研究チームは2022年9月12日にAppleへ結果を開示しており、公開リリースの408日前だったという
WebKitから可能な限りすべてのSpectreガジェットを取り除くのは非現実的なので、ブラウザは異なるWebサイトを異なるプロセスに隔離する形でOSのSpectre緩和策を活用すべきだ
FAQには「最終的にSafariレンダリングプロセスのアドレス空間内のどこからでも範囲外読み取りを達成する」とあるので、個人的にはSafariのサイト分離の実装不備による脆弱性だと見る
どの環境で悪用可能かは、このサイドチャネルを引き起こして測定するJavaScriptベースのガジェットの詳細実装に依存しており、まだ読んでいない論文に書かれているのかもしれない
Lockdown ModeはSafariでJITコンパイルを無効化するため緩和策となり、iLeakageが攻撃プリミティブを作るのに使う性能機能を防ぐという
「認証情報マネージャーを使うと危険なのか？」については大半がそうではないと答えているが、メモリから何かが漏れるのであればSafariのプロセス空間内のすべてのメモリに影響するはずではないかと思う
この分野に詳しくないので、なぜ認証情報マネージャーの利用有無が例外条件になるのか、いまひとつ理解できない
人々が「newpassword2」のようなやり方に戻ってしまうのを避けたいのだろうし、自動入力を無効にしてショートカットやその他のユーザー操作で入力させれば、より安全になる
パスワードマネージャーを使わず、ブラウザにも保存せず、毎回手入力すれば無効化できるという読み方もできるが、それはさまざまな理由から良い反論ではない
パスワードマネージャーは他にも多くの理由で有益であり、たとえパスワードが盗まれても少なくとも被害は1つのWebサイトにとどまる
この手法はおそらくセッショントークンも盗めるので、パスワードの窃取ほどではないにせよ、依然として悪い
パスワードマネージャーをクリックしないと入力しない設定にすれば、この攻撃も防げる
ページに自動入力されたパスワードは手入力したパスワードと同じように復元できるが、パスワードマネージャー内に保存されたすべてのパスワードを直接読み出せるわけではない、という意味だ
window.open呼び出しで開かれたサイトにのみアクセスを許すものだと理解している別個のパスワードマネージャーアプリに保存されたパスワードは、そのアプリが侵害されたSafariウィンドウやプロセスに自動入力しない限りアクセスできない
今回の攻撃は、異なる2つのオリジンが同じアドレス空間を共有するようにする方法を見つけたもので、拡張機能には適用されないと見ている
論文には「Safariのサイト分離ポリシーを悪用し、攻撃者ページがJavaScriptの
window.openAPIで任意の被害者ページを開くだけでアドレス空間を共有させる新しい手法を示す」とあるWebKit専用という位置づけが本当に正しいのか混乱する。キャッシュ悪用それ自体は一般的なものに見えるし、引用文にもSafari、Firefox、Tor全体でほぼ完全な精度を示したと書かれている
また、
window.open()による攻撃が本当にWebKit専用なのか、それとも今回の研究ではWebKitだけを深く調べたのかも気になるwindow.open()は呼び出し元ウィンドウが新しいウィンドウへの参照を受け取り、新しいウィンドウはwindow.openerで逆参照を持つという共有コンテキストを示唆するが、他のブラウザエンジンが完全な分離を達成しているのかも疑問だモバイルブラウザではChromiumのサイト分離は限定的で、Firefoxはまだ実装を完了できていない
https://www.chromium.org/Home/chromium-security/site-isolati...
困惑する。これは重大度の高い問題に見えるのに、修正がデバッグメニューの奥にある。なぜ適切に全面展開される前に公開されたのか分からない
また、サイドチャネル緩和策が実質的に役に立たず、この種の攻撃が修正済みだと装うべきではないことも示している
現代のCPUで複数のアプリケーションを動かすホストなら、どれだけサンドボックス化していても、信頼できないコードを実行するのは安全ではない
Appleユーザーが危険を知らないままさらに1年以上放置されるより、危険を知らせるほうがはるかに良いと思う
企業にバグを修正する時間を与えることには賛成だが、ある時点を過ぎると、影響を受ける人々に知らせないほうがより無責任になる
論文では、投機的なJavaScriptサンドボックス脱出は依然として可能だが、攻撃者は自分のアドレス空間と自分のデータの読み取りに制限されると説明している
執筆時点でAppleのパッチは公開済みで、Safari Technology Preview 173以降に実装されているとあり、[57]は https://github.com/WebKit/WebKit/pull/10169 のことだ
その下でエンジニアが
window.open()とプロセス分離に関する追加の強化パッチを引き続きリンクしているSwap Processes on Cross-Site Window Openはすでに有効で、Stableと表示されていると思っていた自分で有効にした覚えはないので、Appleがすでに有効化していて説明が古いのかもしれないと思ったが、後で似た名前の
Swap Processes on Cross-Site Navigationを見ていたことに気づき、現時点ではデフォルト有効ではないようだ修正配布前に公開した研究者たちより、これほど長く手をこまねいていたAppleを責めるべきだ
すべてのサイドチャネル攻撃が修正されたわけではないが、サイドチャネル緩和策が無意味だというのは不適切だ
シートベルトをしていても自動車事故で人は死ぬが、だからといってシートベルトが無意味なわけではないように、緩和策は悪用の難易度を大きく引き上げる
「研究者たちは2022年9月12日にAppleへ結果を開示した」とあるのに、Appleがなぜ1年以上ほぼ放置していたのか本当に気になる
AppleはCVE権力者の一つなので、自社製品に対するCVE発行を拒否でき、その力があれば好きなだけ遅く動ける
iLeakageのWebサイトで修正に関する文言を見た気がしたが、消えていた。見間違いかと思ったが、実際にはこの1時間の間にWebサイトが変更されていた
「AppleがiOS 17.1、iPadOS 17.1、macOS Sonoma 14.1をちょうどリリースしたので、デバイスを更新してください」という文言があり、今は戻されている
https://github.com/ileakage-authors/ileakage-authors.github....
私がサイトに公開スケジュールがないと指摘したところ、FAQに短いセクションが追加され、ここから修正配布の有無が紛らわしい状況で、研究者側も一緒に混乱しているようだ
Swap Processes on Cross-Site Navigationがあり、デフォルトで有効になっているmacOSの
Swap Processes on Cross-Site Window Openとは別物なのか気になる「iLeakageは最後まで実行するのがかなり難しい攻撃であり、ブラウザベースのサイドチャネル攻撃とSafari実装に関する高度な知識が必要だ」という文言が、Appleがあまり気にしていない理由かもしれない
さらに大げさな別名やドメイン名まで付けているのは、専門的にも信頼できるものにも見えない
Apple AシリーズまたはMシリーズCPUを搭載したmacOSまたはiOSデバイス、つまり最近のiPhone/iPadや2020年以降のAppleノートPC・デスクトップが対象なら、珍しいIntel Macユーザーとして私は影響を受けないようだ
キャッシュ階層構造が少し違うだけで、概念実証には多少の変更が必要になるだろう
iOSなら Lockdown Mode を使うべきで、それがiPhoneを安全に使う唯一の方法だ
Lockdown Modeなしのベンチマークは、
mitigations=offでCPUベンチマークを回したのと同じくらい無意味だと見なすべきだiOSデバイスで別のブラウザエンジンを許可すべき、また一つの良い理由だ
以下のコマンドを実行するときにエラーが出るなら、ターミナルにFull Disk Accessを付与してから再試行すればよい
defaults write com.apple.SafariTechnologyPreview IncludeInternalDebugMenu 1