Spectre の影響を受けないウェブを作るための概念実証について
2021年3月29日月曜日
3 年前、 によってウェブのセキュリティ境界についての考え方が変わりました。ウェブブラウザはアプリケーション間のデータ漏洩を防げるという保証が によって損なわれたことは、すぐに明らかになりました。その結果、ウェブブラウザ ベンダーが協力し合い、継続的にプラットフォームの堅牢化に取り組んでいます。しかし、この種の攻撃は依然として懸念され続けており、ウェブ デベロッパーが を導入することも求められています。
この投稿では、ウェブユーザーに対する Spectre の悪用に関して、Google セキュリティ チームが行った調査の結果を共有します。また、JavaScript で書かれた高速で柔軟な概念実証（PoC）も提示し、ブラウザのメモリから情報が漏洩することを示します。この概念実証やそのバリアントは、さまざまなオペレーティング システム、プロセッサ アーキテクチャ、ハードウェア世代で動作することを確認しています ...
この記事は情報セキュリティ エンジニア、Stephen Röttger、Artur Janc による Google Online Security Blog の記事 "A Spectre proof-of-concept for a Spectre-proof web" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
3 年前、Spectre によってウェブのセキュリティ境界についての考え方が変わりました。ウェブブラウザはアプリケーション間のデータ漏洩を防げるという保証が最新プロセッサの欠陥によって損なわれたことは、すぐに明らかになりました。その結果、ウェブブラウザ ベンダーが協力し合い、継続的にプラットフォームの堅牢化に取り組んでいます。しかし、この種の攻撃は依然として懸念され続けており、ウェブ デベロッパーがアプリケーション レベルの対策を導入することも求められています。
この投稿では、ウェブユーザーに対する Spectre の悪用に関して、Google セキュリティ チームが行った調査の結果を共有します。また、JavaScript で書かれた高速で柔軟な概念実証（PoC）も提示し、ブラウザのメモリから情報が漏洩することを示します。この概念実証やそのバリアントは、さまざまなオペレーティング システム、プロセッサ アーキテクチャ、ハードウェア世代で動作することを確認しています。
この発見をセキュリティ コミュニティと共有する目的は、ウェブ アプリケーションの所有者に、Spectre による脆弱性がユーザーのデータのセキュリティに与える可能性がある影響について深く理解してもらうためです。さらに、Google 全体の経験に基づき、ウェブ制作者が利用できる対策やウェブ アプリケーションで実現できるベスト プラクティスについても説明します。
2019 年、Chrome の JavaScript エンジンである V8 の担当チームは、ブログ投稿とホワイトペーパーを公開し、ソフトウェア レベルではこのような攻撃に確実に対策することはできないという結論を出しました。この問題に対する確実なソリューションとしては、ウェブブラウザなどのアプリケーションに、プロセスベースの分離のような低レベル プリミティブに合わせたセキュリティ境界が必要になります。
これと並行して、ブラウザのベンダーや標準化団体は、この種の攻撃からウェブユーザーを守るためのセキュリティ メカニズムを開発しました。これには、一部のブラウザ構成で実現できるデフォルトの保護を提供するためのアーキテクチャの変更（Site Isolation（サイト分離）、out-of-process iframes = OOPIF（プロセス外 iframe）、Cross-Origin Read Blocking = CORB（クロスオリジン読み取りブロック）など）と、ウェブ デベロッパーがアプリケーションに広く適用できるオプトイン セキュリティ機能（Cross-Origin Resource Policy、Cross-Origin Opener Policy、Cross-Origin Embedder Policy など）の両方が含まれています。
これらのメカニズムは非常に重要ですが、これで Spectre の悪用を防ぐことはできません。むしろ、攻撃者が読み取ることができるメモリに機密データが含まれないようにするための措置です。そのため、この対策の確実性を評価するには、セキュリティ エンジニアがアプリケーションに対する投機的実行攻撃の実際の影響について理解する際に役立つ、セキュリティ ツールを開発することが重要になります。
Intel Skylake CPU で Chrome 88 を実行している場合、デモのウェブサイトでは 1 kB/ 秒のスピードでデータが漏洩する可能性があります。なお、このコードはわずかに変更するだけで他のバージョンの CPU やブラウザにも適用できると考えられます。ただし、Google のテストでは、大きな変更を加えなくても、この攻撃を Apple M1 ARM CPU などの他のいくつかのプロセッサで成功させることができました。
実験にあたり、異なる特性を持つ他の PoC も作成しました。いくつかの例を示します。
PoC の主な構成要素は、以下のとおりです。
セキュリティ コミュニティの皆さんには、さらに調査をし、他の Spectre ガジェットを利用したコードを作成することをお勧めします。
3 年前、Spectre によってウェブのセキュリティ境界についての考え方が変わりました。ウェブブラウザはアプリケーション間のデータ漏洩を防げるという保証が最新プロセッサの欠陥によって損なわれたことは、すぐに明らかになりました。その結果、ウェブブラウザ ベンダーが協力し合い、継続的にプラットフォームの堅牢化に取り組んでいます。しかし、この種の攻撃は依然として懸念され続けており、ウェブ デベロッパーがアプリケーション レベルの対策を導入することも求められています。
この投稿では、ウェブユーザーに対する Spectre の悪用に関して、Google セキュリティ チームが行った調査の結果を共有します。また、JavaScript で書かれた高速で柔軟な概念実証（PoC）も提示し、ブラウザのメモリから情報が漏洩することを示します。この概念実証やそのバリアントは、さまざまなオペレーティング システム、プロセッサ アーキテクチャ、ハードウェア世代で動作することを確認しています。
この発見をセキュリティ コミュニティと共有する目的は、ウェブ アプリケーションの所有者に、Spectre による脆弱性がユーザーのデータのセキュリティに与える可能性がある影響について深く理解してもらうためです。さらに、Google 全体の経験に基づき、ウェブ制作者が利用できる対策やウェブ アプリケーションで実現できるベスト プラクティスについても説明します。
簡単な背景
Spectre の脆弱性は、2018 年 1 月に一般に公表されました。プロセッサ（CPU）の設計上の脆弱性の一種を攻撃者が利用して、CPU が後続の命令を投機的に実行する際に、プログラムで意図された制御フローを変えることができます。たとえば、CPU が長さチェックに合格すると推測しても、実際には境界外のメモリにアクセスすることになります。CPU の状態は推測ミスが明らかになるとロールバックされますが、この動作による副作用は管理できるため、攻撃者にデータが漏洩する可能性があります。2019 年、Chrome の JavaScript エンジンである V8 の担当チームは、ブログ投稿とホワイトペーパーを公開し、ソフトウェア レベルではこのような攻撃に確実に対策することはできないという結論を出しました。この問題に対する確実なソリューションとしては、ウェブブラウザなどのアプリケーションに、プロセスベースの分離のような低レベル プリミティブに合わせたセキュリティ境界が必要になります。
これと並行して、ブラウザのベンダーや標準化団体は、この種の攻撃からウェブユーザーを守るためのセキュリティ メカニズムを開発しました。これには、一部のブラウザ構成で実現できるデフォルトの保護を提供するためのアーキテクチャの変更（Site Isolation（サイト分離）、out-of-process iframes = OOPIF（プロセス外 iframe）、Cross-Origin Read Blocking = CORB（クロスオリジン読み取りブロック）など）と、ウェブ デベロッパーがアプリケーションに広く適用できるオプトイン セキュリティ機能（Cross-Origin Resource Policy、Cross-Origin Opener Policy、Cross-Origin Embedder Policy など）の両方が含まれています。
これらのメカニズムは非常に重要ですが、これで Spectre の悪用を防ぐことはできません。むしろ、攻撃者が読み取ることができるメモリに機密データが含まれないようにするための措置です。そのため、この対策の確実性を評価するには、セキュリティ エンジニアがアプリケーションに対する投機的実行攻撃の実際の影響について理解する際に役立つ、セキュリティ ツールを開発することが重要になります。
ウェブブラウザを利用した Spectre のデモ
今日は、実際に Spectre が JavaScript エンジンを侵害することを確認できる概念実証（PoC）コードを共有します。攻撃のデモには Google Chrome を使いますが、これは Chrome に固有の問題ではなく、他のモダンブラウザも同様にこの脆弱性の影響を受けるものと考えられます。攻撃のインタラクティブなデモを開発し、https://leaky.page/ で公開しました。コードと詳しい説明は、こちらの Github をご覧ください。
Intel Skylake CPU で Chrome 88 を実行している場合、デモのウェブサイトでは 1 kB/ 秒のスピードでデータが漏洩する可能性があります。なお、このコードはわずかに変更するだけで他のバージョンの CPU やブラウザにも適用できると考えられます。ただし、Google のテストでは、大きな変更を加えなくても、この攻撃を Apple M1 ARM CPU などの他のいくつかのプロセッサで成功させることができました。
実験にあたり、異なる特性を持つ他の PoC も作成しました。いくつかの例を示します。
- performance.now() を 5 マイクロ秒の精度のタイマーとして使うことで、安定性と引き替えに 8 kB/ 秒でデータを漏洩する PoC
- 1 ミリ秒またはそれより粗い精度のタイマーを使うことで、60 B/ 秒でデータを漏洩する PoC
現在の PoC を公開することにしたのは、セットアップ時間が無視できる程度であり、
SharedArrayBuffer のような高精度なタイマーがなくても動作するからです。 PoC の主な構成要素は、以下のとおりです。
- Spectre ガジェット : 攻撃者が制御する一時的実行を呼び出すコード
- サイドチャネル : 一時的実行の副作用を管理する方法
1. ガジェット
公開した PoC では、単純なバリアント 1 のガジェットを実装しました。コンパイラが挿入した長さチェックが成功することを予測する分岐予測のトレーニング後に、JavaScript 配列の境界外への投機的なアクセスが発生します。このガジェットではソフトウェア レベルの対策を取れますが、Chrome の V8 チームは、他のガジェットではそうはいかないと結論づけています。「一部の Spectre のバリアント、とりわけバリアント 4 に対しては、ソフトウェアで効果的に対策するのは不可能であるとわかりました」と述べています。セキュリティ コミュニティの皆さんには、さらに調査をし、他の Spectre ガジェットを利用したコードを作成することをお勧めします。
2. サイドチャネル
投機的実行によって秘密データが漏洩する場合、キャッシュ サイドチャネルが使われるのが一般的です。メモリ内の特定の場所がキャッシュに存在するかどうかを管理すると、投機的実行によるメモリへのアクセスがあったかどうかを推測できます。JavaScript で難しいのは、キャッシュ アクセスとメモリ アクセスを判別できるほどの高精度タイマーを見つけることです。モダンブラウザは、タイミング攻撃を防ぐため、クロスオリジン分離が行われていない状況で performance.now() API のタイマーの精度を粗くし、SharedArrayBuffer を利用できないようにしています。
V8 チームは、2018 年時点ですでに、タイマーの精度を粗くすることは Spectre の対策としては不十分であると報告しています。攻撃者はタイミングの差を自由に増幅できるからです。ただし、そこで述べられている増幅テクニックは、秘密データを複数回読み取る方法に基づいているので、情報の漏洩が確率的なものである場合は、攻撃の効率を低下することができます。
今回の PoC では、新たなテクニックを使ってこの制限を回避しました。最近の CPU でよく使われる Tree-PLRU キャッシュ エビクション戦略の動作を悪用すれば、秘密データを 1 回読み取ることで、キャッシュのタイミングを大きく増幅することができます。これにより、低精度タイマーでも、効率よくデータを漏洩することができました。このテクニックの詳細については、https://leaky.page/plru.html のデモをご覧ください。
この PoC は、大きく改変しない限り、悪用目的で再利用できるとは考えられません。しかし、Spectre のリスクを示す上では、説得力のあるデモとなります。特に、このリスクを考慮してセキュリティ評価をする必要があるウェブ アプリケーション デベロッパーにとっての明らかなシグナルとなり、サイトを保護する積極的なアクションにつながることを期待しています。
ウェブ デベロッパーは、この点を考慮してサイトをさらに確実に分離することを検討する必要があります。そのためには、新しいセキュリティ メカニズムを使い、攻撃者によるクロスオリジン リソースへのアクセスを積極的に防ぎます。このような保護は、Spectre スタイルのハードウェア攻撃や一般的なウェブレベルのクロスサイト漏洩の対策となりますが、デベロッパーはそういった脆弱性によるアプリケーションへの脅威を評価し、その対策のデプロイ方法を理解する必要があります。Chrome のウェブ プラットフォーム セキュリティ チームは、この評価に役立ててもらうため、デベロッパー向けの具体的なアドバイスを含む Spectre 後のウェブ開発とサイドチャネル攻撃への対策を公開しました。このガイドに従って以下の保護をすることを強くお勧めします。
V8 チームは、2018 年時点ですでに、タイマーの精度を粗くすることは Spectre の対策としては不十分であると報告しています。攻撃者はタイミングの差を自由に増幅できるからです。ただし、そこで述べられている増幅テクニックは、秘密データを複数回読み取る方法に基づいているので、情報の漏洩が確率的なものである場合は、攻撃の効率を低下することができます。
今回の PoC では、新たなテクニックを使ってこの制限を回避しました。最近の CPU でよく使われる Tree-PLRU キャッシュ エビクション戦略の動作を悪用すれば、秘密データを 1 回読み取ることで、キャッシュのタイミングを大きく増幅することができます。これにより、低精度タイマーでも、効率よくデータを漏洩することができました。このテクニックの詳細については、https://leaky.page/plru.html のデモをご覧ください。
この PoC は、大きく改変しない限り、悪用目的で再利用できるとは考えられません。しかし、Spectre のリスクを示す上では、説得力のあるデモとなります。特に、このリスクを考慮してセキュリティ評価をする必要があるウェブ アプリケーション デベロッパーにとっての明らかなシグナルとなり、サイトを保護する積極的なアクションにつながることを期待しています。
ウェブにおける Spectre 対策の導入
投機的実行による脆弱性は本質的に低レベルで発生するため、適切なパッチにはユーザーのデバイスのファームウェアやハードウェアの変更が必要になる場合があり、包括的な修正は難しくなります。オペレーティング システムやウェブブラウザのデベロッパーは、可能な限り重要な組み込みの保護機能を実装しています（Google Chrome の out-of-process iframes（プロセス外 iframe） や Cross-Origin Read Blocking（クロスオリジン読み込みブロック）による Site Isolation（サイト分離）、Firefox の Project Fission など）。しかし、既存の API 設計では、データが意図せずに攻撃者のプロセスに流れ込む可能性が残ります。ウェブ デベロッパーは、この点を考慮してサイトをさらに確実に分離することを検討する必要があります。そのためには、新しいセキュリティ メカニズムを使い、攻撃者によるクロスオリジン リソースへのアクセスを積極的に防ぎます。このような保護は、Spectre スタイルのハードウェア攻撃や一般的なウェブレベルのクロスサイト漏洩の対策となりますが、デベロッパーはそういった脆弱性によるアプリケーションへの脅威を評価し、その対策のデプロイ方法を理解する必要があります。Chrome のウェブ プラットフォーム セキュリティ チームは、この評価に役立ててもらうため、デベロッパー向けの具体的なアドバイスを含む Spectre 後のウェブ開発とサイドチャネル攻撃への対策を公開しました。このガイドに従って以下の保護をすることを強くお勧めします。
- Cross-Origin Resource Policy（CORP）と Fetch メタデータ リクエスト ヘッダーを使うと、イメージやスクリプトなどのリソースを埋め込むことができるサイトを制御して、攻撃者が制御するブラウザのレンダリング プロセスにデータが渡るのを防げます。詳しくは、resourcepolicy.fyi と web.dev/fetch-metadata をご覧ください。
- Cross-Origin Opener Policy（COOP）を使うと、アプリケーション ウィンドウで他のウェブサイトからの予期しないインタラクションの受け取りを拒否できます。これにより、ブラウザはプロセス内でウィンドウを分離できるようになります。これは重要なプロセスレベルの保護を追加することになり、完全なサイト分離を有効化できないブラウザで特に重要になります。詳しくは、web.dev/coop-coep をご覧ください。
- Cross-Origin Embedder Policy（COEP）を使うと、アプリケーションがリクエストした認証済みリソースの読み込みを明示的にオプトインできます。 現在、Chrome や Firefox の機密性が高いアプリケーションでプロセスレベルの分離を保証するには、COEP と COOP の両方を有効化する必要があります。詳しくは、web.dev/coop-coep をご覧ください。
覚えておくべき重要な点は、この記事で説明したすべてのメカニズムは重要で強力なセキュリティ プリミティブですが、Spectre に対する完全な保護を保証するものではないことです。また、アプリケーションに固有の動作を考慮したデプロイ方法の検討も必要です。セキュリティ関連のエンジニアや研究者の皆さんには、この Spectre の概念実証の利用と貢献をお願いいたします。サイトのセキュリティ状況の確認や改善に役立てていただきたいと考えています。
ヒント : ウェブサイトを Spectre から守るために役立てていただけるよう、Google セキュリティ チームは Spectroscope を作成しました。これは Chrome 拡張機能のプロトタイプで、アプリケーションをスキャンして、さらなる防御が必要になる可能性があるリソースを見つけます。ウェブ分離機能の導入と合わせてご検討ください。
Reviewed by Eiji Kitamura - Developer Relations Team
ヒント : ウェブサイトを Spectre から守るために役立てていただけるよう、Google セキュリティ チームは Spectroscope を作成しました。これは Chrome 拡張機能のプロトタイプで、アプリケーションをスキャンして、さらなる防御が必要になる可能性があるリソースを見つけます。ウェブ分離機能の導入と合わせてご検討ください。
Reviewed by Eiji Kitamura - Developer Relations Team
![Share on Twitter](data:image/svg+xml,<svg xmlns="http://www.w3.org/2000/svg" width="48" height="48"><rect fill-opacity="0"/></svg>){kind=small}
Adam Ohren（Google Ads API チーム）
