Google は、ブラウザで JavaScript コードを実行する際に、以前に追加された保護方法をバイパスして、Spectre クラスの脆弱性を悪用する可能性を示すエクスプロイト プロトタイプをいくつか公開しました。 エクスプロイトを使用すると、現在のタブで Web コンテンツを処理するプロセスのメモリにアクセスできます。 このエクスプロイトの動作をテストするために、Web サイト Leaky.page が開設され、作業のロジックを記述したコードが GitHub に投稿されました。
提案されたプロトタイプは、Linux および Chrome 7 を使用する環境で Intel Core i6500-88U プロセッサを搭載したシステムを攻撃するように設計されています。他の環境でエクスプロイトを使用するには、変更が必要です。 この悪用方法は Intel プロセッサに固有のものではありません。適切に適応させた後、この悪用は ARM アーキテクチャに基づく Apple M1 など、他のメーカーの CPU を搭載したシステムでも動作することが確認されました。 若干の調整を行った後、このエクスプロイトは他のオペレーティング システムや Chromium エンジンをベースにした他のブラウザでも実行可能です。
標準の Chrome 88 および Intel Skylake プロセッサをベースにした環境では、現在の Chrome タブで Web コンテンツの処理を担当するプロセス (レンダラー プロセス) から 1 秒あたり 8 キロバイトの速度でデータが漏洩する可能性がありました。 さらに、代替プロトタイプも開発されています。たとえば、安定性を犠牲にして、5 マイクロ秒 (0.005 ミリ秒) の精度で Performance.now() タイマーを使用するときにリーク レートを 60kB/s に増加できるエクスプロイトです。 ）。 XNUMX ミリ秒のタイマー精度で動作するバージョンも用意されており、これを使用して、XNUMX 秒あたり約 XNUMX バイトの速度で別のプロセスのメモリへのアクセスを整理できます。
公開されたデモ コードは XNUMX つの部分で構成されます。 最初の部分では、タイマーを調整して、CPU 命令の投機的実行の結果としてプロセッサー キャッシュに残っているデータを復元するために必要な操作の実行時間を推定します。 XNUMX 番目の部分では、JavaScript 配列を割り当てるときに使用されるメモリ レイアウトを決定します。
XNUMX 番目の部分では、Spectre の脆弱性を直接悪用して、特定の操作の投機的実行条件を作成した結果、現在のプロセスのメモリ内容を特定します。その結果は、予測が失敗したと判断した後にプロセッサによって破棄されますが、その痕跡は残ります。実行は一般的なキャッシュに保存され、キャッシュされたデータとキャッシュされていないデータへのアクセス時間の変化を分析するサードパーティ チャネルによるキャッシュの内容を決定するメソッドを使用して復元できます。
提案された悪用手法により、performance.now() API を通じて利用可能な高精度タイマーや、共有メモリ内に配列を作成できる SharedArrayBuffer 型のサポートがなくても実行できるようになります。 このエクスプロイトには、コードの制御された投機実行を引き起こす Spectre ガジェットと、投機実行中に取得されたキャッシュ データを検出するサイドチャネル リーク アナライザーが含まれています。
ガジェットは JavaScript 配列を使用して実装されており、バッファーの境界外の領域へのアクセスが試行され、コンパイラー (プロセッサー、プロセッサー、先を見て、投機的にアクセスを実行しますが、確認後に状態をロールバックします)。 タイマ精度が不十分な状況でキャッシュの内容を解析するために、プロセッサで使用されているTree-PLRUキャッシュ追い出し戦略を欺瞞し、サイクル数を増やすことで復帰時の時間差を大幅に拡大する手法が提案されています。キャッシュからの値、およびキャッシュに値がない場合。
Googleは、Spectreクラスの脆弱性を利用した攻撃の実行可能性を示し、Web開発者にそのような攻撃によるリスクを最小限に抑える技術の使用を奨励するために、エクスプロイトのプロトタイプを公開したことが注目されています。 同時に、Google は、提案されたプロトタイプを大幅に作り直さなければ、デモンストレーションだけでなく広く使用できる普遍的なエクスプロイトを作成することは不可能であると考えています。
リスクを軽減するために、サイト所有者は、最近実装されたヘッダー Cross-Origin Opener Policy (COOP)、Cross-Origin Embedder Policy (COEP)、Cross-Origin Resource Policy (CORP)、Fetch Metadata Request、X-Frame を使用することをお勧めします。オプション、X -Content-Type-Options、および SameSite Cookie。 これらのメカニズムは攻撃から直接保護するものではありませんが、攻撃者の JavaScript コードが実行されるプロセスへのサイト データの漏洩を隔離できます (漏洩は、攻撃者のコードに加えて、現在のプロセスのメモリからも発生します) 、同じタブで開かれた別のサイトのデータも処理できます)。 主なアイデアは、サイト コードの実行をさまざまなプロセスで、信頼性の低いソースから受信したサードパーティ コード (iframe 経由など) から分離することです。
出所： オープンネット.ru