Spectre（スペクター）は、今日の幅広いマイクロプロセッサに存在するハードウェアレベルの脆弱性であり、正当な権限のないプロセスが保護されたメモリの領域（例：サンドボックスの外側）にアクセスすることが可能になる[1][2][3][4][5]。
Spectre（スペクター）は、今日の幅広いマイクロプロセッサに存在するハードウェアレベルの脆弱性であり、正当な権限のないプロセスが保護されたメモリの領域（例：サンドボックスの外側）にアクセスすることが可能になる[1][2][3][4][5]。
悪意あるプログラムが任意のメモリ領域（機密情報を含む可能性がある）の読み取りを可能とする、マイクロプロセッサの分岐予測・投機的実行の実装に含まれる脆弱性である[1][2] [3][4][5]。
特定のCPUアーキテクチャに依存した脆弱性ではなく、x86（インテル、AMDおよび互換CPU）、ARMでも発生することが示唆されている。GPUでは不詳、あるいは確認されていない[6]。
Spectreに関連するCVE番号は次の2つである。
このうち、CVE-2017-5753は、ブラウザ・ベースのJavaScriptのJITエンジンに発見された脆弱性である。ウェブサイトから、端末の他のブラウザで使用されるデータや、ブラウザ・プロセスそのもののデータを読み取ることができる。Firefox 57.0.4とGoogle Chrome 64で、ウェブサイトごとにプロセスを分割することで対処されるとしている[7][8][9][10]。
2018年5月21日、Spectreの新しい亜種（Variant 3a/4）が発表された[11][12]。
Googleのゼロデイ攻撃研究のプロジェクトProject Zeroと暗号学者のポール・コッフェルが中心となった研究チームが別々に発見し、Meltdownのチームとの共同作業となり、2018年1月3日に発表された。 「Spectre」（幽霊）と命名した理由は、投機的実行 (speculative execution) に由来しており、修復が困難なことから、相当のあいだ幽霊のように我々に取り憑くだろうと説明されている[13]。
Spectreは、以下の2つの脆弱性を内包している [14]
いずれの脆弱性も、権限のないデータの読み取りが可能であることを示唆している。 また、共通する事象として、通常、これらの攻撃の痕跡は残らないため、攻撃を受けて流出したデータの特定が困難であることを意味する。
メモリアクセスにおいて、通常はマイクロプロセッサの境界チェックにより、読み取り可能な領域かどうかをチェックされているが、特定の条件下で投機的実行を行った場合に境界チェックが適切に行われず、盲目的にメモリ命令が発行されるケースがほとんどのプロセッサで存在しており、結果として読み取る必要のない領域がキャッシュに読み込まれることがあり、その変化を追跡することで秘密情報のアドレスを特定し、秘密情報を入手が可能としている[15]。 原理的には他プロセスでの攻撃も成功すると推測するが、Exploitは自プロセスのデータ読み取りが提示されている。
処理の概要としては、Return-oriented programming (ROP) とよく似ており、悪意のあるプロセスで分岐予測を学習させ、ターゲットとなるプロセス内の間接分岐命令がガジェットを投機的実行することを試みる [17]。 攻撃の成否をキャッシュヒットミスの測定することで確認している（サイドチャネル攻撃）。
攻撃成立の前提として投機的実行により副作用が発生することが必要で、検証では同一物理コア内のSMTによる論理コア間でデータを読み出すことが可能であったと示されている[18]。
自プロセス内の機密データを読み取るExploitによる攻撃が成功している（ブラウザベースのJavaScriptによる攻撃等）。
他プロセスのデータを読み取る場合は、確率的な挙動を示し、攻撃の容易度はプロセッサのアーキテクチャに依存するとされている。 AMDは、内部アーキテクチャの違いから、CVE-2017-5715はほぼゼロリスク、Meltdownはゼロリスクである、と述べている[19]。
攻撃対象のプロセスのメモリ構造を知っていれば攻撃の成功率を劇的に向上することができるため、逆説的に、メモリ構造を推測させなければ、攻撃を劇的に緩和させることが可能である。
ユーザランドの対策としては、他のメモリに対する攻撃同様、アドレス空間配置のランダム化 (ASLR) とPosition Independent Code (PIC) を組み合わせるなどして、メモリマップをランダム化する手法が知られており、この脆弱性でも有効とされている。また、LLVMにパッチを充てることで、同様の効果が得られる[20]。
また、成功・失敗の判別にはサイドチャネル攻撃的なアイデアで判別されることがあるが、これらは例えばスクリプトの応答時間を均一化したり、処理時間を高精度で測定させない等の方法により緩和することも可能である(ブラウザのJavaScriptの実行にて同様のアプローチがとられている[21])。
ウイルス対策ソフトウェアでの防御は、有効性が疑問視されている[22]。 影響を完全に排除するには、プロセッサアーキテクチャの大幅な刷新が必要であると述べられている。
原理的には、分岐予測・投機的実行を実装するプロセッサに潜在的影響があるとされている。
GoogleはXeon E5-1650 v3をテストに使用し、攻撃に成功している。その他のCPUではテストされていない[16]。
2018年3月までに、Spectre Variant2に対するCPUマイクロコードのアップデート状況を公表している[23]。現実のシステムへの適用は、BIOS/UEFIのファームウェアアップデート、またはオペレーティングシステム (OS) によるマイクロコードリリースパッチの提供に依存する（これらで未提供の場合、適用されない）。
2018年4月2日付文書で、Intel Core 2世代と、第1世代Core iシリーズの一部について、脆弱性パッチの適用を中止すると公表した。対象CPUのコードネームは以下の通り[24][25][26]。
なお、Core 2よりも以前の世代のCPU（LGA775ではCore Duo/Solo/Pentium M/4/D/EEなど、およびNetBurstマイクロアーキテクチャとそれ以前）については何も発表されていない。
GoogleはeBPF JITを有効にしたカーネルにおいて、AMD PROで攻撃に成功したとしている（eBPF JITを無効にした場合は成功していない）[16]。その他のCPUではテストされていない[16]。
AMD Radeon GPUについては不詳。
ARMは、Cortex-R7/R8/A8/A9/A15/A17/A57/A72/A73/A75はSpectreの影響を受け、これに加えてCortex-A75はMeltdownの影響を受ける事を認めた[16]。
ミドルレンジAndroid携帯電話端末の多数に使用されるオクタコアのARM Cortex-A53/A55 は、アウト・オブ・オーダー実行をしないため、MeltdownやSpectreのいずれの脆弱性の影響も受けないとされている。Qualcomm Snapdragon 630/626/625/4xxもベースコアがCortex-A53/A55 のため同様である[27]。Raspberry Piも影響を受けないとされている[28]。
不詳。
![[icon]](./ファイル:Wiki_letter_w_cropped.svg){kind=small} | この節の加筆が望まれています。 |
本見出し中の日付は特記ない場合2018年。
Spectreは、Meltdownと同様にCPUのハードウェアレベルの脆弱性であるため、OS側やブラウザなどのアプリケーション側で回避策が取られつつある。KPTI(kernel page-table isolation)パッチはMeltdownに有効、Spectreには無効であるが、多くのベンダーはパッチがMeltdownとSpectreのどちら（又は双方）を回避、緩和するのか明確にしていない（そのようなパッチに関しては、Meltdown側で記述する）。
macOSは1月8日にリリースされた"macOS High Sierra 10.13.2 Supplemental Update" で、Meltdown対策に加え、Spectre対策が適用されている（同時にSafariもアップデートされる）[29]。
SpectreはKPTIによっては回避されないので、2018年1月5日時点でOSレベルのパッチは出ていない。
GoogleはAndroid OSのセキュリティパッチを配信している[30]が、現実の端末へのパッチの互換性は、端末のメーカーあるいは携帯電話事業者の対応に依存する。
iOS 11.2以降、tvOS 11.2以降でMeltdown対策パッチが当てられている[31]。なお、1月8日にリリースされた"iOS 11.2.2 にてSpectre対策が適用されている[29]。
1月23日リリース予定のChrome 64においてJavaScriptエンジンにSpectre対策を施す予定である
[10]。
また当面のSpectre対策として、Strict site isolation（厳格なサイト分離）機能を有効にする事をGoogleは提案している[32][33]。ブラウザの互換性については多少の問題がある。
1月4日（現地時間）にリリースされたFirefox 57.0.4 で、perfomance.now()の精度を意図的に低下させ、SharedArrayBufferを無効化する事により対処したとしている。なお、Firefox 52 ESRでは既にSharedArrayBufferが無効化されているが[34]、1月23日（現地時間）リリースのESR 52.6で57.0.4と同レベルの修正が掛かっている[35]。
メーカー等の対応に依存する。
未登録
IPFS未登録
📡 0ピア
N=1
CRITICAL
PQS B69