スペクターの脅威は続く:私たちは速度と引き換えにセキュリティを犠牲にしたのか?

Martin Hron 4 6 2018

スペクターとメルトダウンが明らかになった今、パッチ適用が特に重要である理由とは。

サイバーセキュリティ業界の関係者にとって、2018 年が始まったのは 1 月 3 日でした。この日、3 つの CPU バグが発表されたのです。3 つのバグとは?皆さんの記憶にあるのはおそらく、メルトダウンとスペクターの 2 つでしょう。ですが私たちからすれば、スペクターは 1 つで 2 つ分の影響があるバグなのです。メルトダウンとスペクターは、どちらも世界中のメディアやセキュリティ ブログで大いに話題となりました(弊社のブログでも取り上げています)が、両者の間には重要な差があります。そして、この話題はまだ終わっていません。

まず、その違いを確認しておきましょう。メルトダウンは、ほぼ Intel CPU のみに影響を与えるバグです(若干の例外はあります)。一方でスペクターは、市販されているほぼすべての CPU に存在する設計上の欠陥です。残念ながら、この数週間のうちに、同じ欠陥に由来する脆弱性が他にも存在することが明らかになりました。

分かっていることは次のとおりです。今回、スペクターに似た 8 つのバグが発表され、いずれもSpectre-NG(next generation)と呼ばれています。そのうち 4 つが「重大な問題」と評価されています。これらのバグを Intel とドイツの雑誌 Heist に報告したのは、無名の研究者グループでした。

Spectre-NG の開示を待つ間にも、スペクターの脅威は増え続ける一方です。5 月 21 日に、8 つのバグのうち最初の 2 つ、Variant 3a(CVE-2018-3640)と Variant 4(CVE-2018-3639)が開示されました。この 2 つの亜種は Microsoft および Google の Project Zero グループによって発見されたものです。

公開されているスペクターおよびメルトダウンの脆弱性のタイムライン(現時点において):

2018 年 1 月 2 日

  • Variant 1:Bounds Check Bypass - CVE-2017-5753:攻撃者が許可された境界外のメモリに投機的にアクセスし、キャッシュからデータを復元することが可能となる。
  • Variant 2:Branch Target Injection - CVE-2017-5715:投機的メモリが、通常の状況下では実行されないはずのコードを実行する可能性がある。
  • Variant 3:Rogue Data Cache Load - CVE-2017-5754:任意のメモリ領域に対するアクセスとデータの読み取りを可能にする。「メルトダウン」の名称で知られる。

2018 年 5 月 22 日

  • Variant 3a:Rogue System Register Read - CVE-2018-3640:攻撃者が権限のない命令を投機的に実行して(カーネルからのみアクセス可能な)特権レジスタを読み取り、その後サイド チャネル攻撃により値を復元することが可能となる。
  • Variant 4:Speculative Store Bypass - CVE-2018-3639:ロード命令が順不同かつ投機的に実行されるため、攻撃者がメモリ上の古いデータを投機的に読み取ることが可能となる。そのため、攻撃者がサイド チャネル攻撃によりデータにアクセスできる可能性がある。

最近の CPU の設計上の欠陥

では、最近の CPU の設計における根本的な問題はどこにあるのでしょうか?ご説明しましょう。

長い間、「預言者」とも言える CPU が開発されてきました。未来を予測できる、または少なくとも次に何が起きるかを予測できる CPU です。どのように予測するのでしょうか?まず、CPU がメモリと通信する方法について理解する必要があります。現在の CPU は極めて高速であるため、メモリにデータを読みに行っていると速度が落ちてしまいます。CPU の速度を上げるには、キャッシュと呼ばれるものが必要です。キャッシュとは、頻繁に使用するデータをすぐアクセスできるように保持する、小さくて高速かつ高額なメモリのことです。

CPU は、メイン メモリのデータにアクセスする際に、まずキャッシュを見に行きます。キャッシュにデータがある場合はよいのですが、ない場合は、必要なデータのコピーがメイン メモリからキャッシュに移動され、さらに CPU に転送されます。次回 CPU が同じデータを必要とする際には、そのデータはすでにキャッシュ内に存在しています。

最近の CPU は複数の命令を並行処理できるため、時間を節約する傾向にあります。プログラムのある時点で、CPU がメモリ上のある場所(アドレス)のコンテンツ(値)に基づいて、2 つの道のどちらに行くかを決定しなければならないとします。その値はキャッシュにはないため、メモリから取得する必要があります。

CPU は待ちきれずに、「今待っている値が自分をこちらの道に行かせるとしたらどうだろう?」と推測し始めます。「通常行く道はこっちだし…何度か通ったこともあるし」

そこで CPU は、投機的にコードの片方の分岐を実行します。このコードの一部は、メモリ上の別の場所(「秘密の場所」と呼んでおきましょう)からデータを読み込みます。その場所には秘密の値が保存されています。一方で、本当の値がようやくメイン メモリから到着します。その時点で CPU は、もう片方の道に行くべきだと気づき、投機的実行で取得した結果をすべて破棄して正しい道に進みます。

実は、その大切な値は CPU に「秘密の場所」に触れてはいけない、と伝えるセキュリティ チェックだとします。しかし、すでに触れてしまいました。それって問題でしょうか?そんなに深刻な?結局のところ、CPU は投機的に実行したにすぎず、結果はすべて破棄されているのでは?いいえ、そうとも限りません。キャッシュの存在を思い出してください。秘密の値はまだそこに残っているのです。特別な技術を使えば(詳細はここでは述べませんが)、実はその値は簡単に復元できてしまいます。

つまり、問題の本質はこうです。より高速な CPU を追い求める中で、私たちは速度と予測と引き換えにセキュリティを犠牲にしてきました。残念ながら、この問題は簡単には修復できません。少なくとも性能をある程度犠牲にしない限り無理です。では、なぜ古い CPU は影響を受けないのでしょうか?答えは簡単です。予測しないからです。

一般ユーザーにとって、これらの問題はどの程度深刻なのでしょうか?自分は心配するべきですか?

これらの脆弱性はいずれも検証済みで深刻なものですが(すべて概念実証コードが存在)、悪用に成功したマルウェアがあるという証拠はありません。実世界で悪用するには、攻撃者はターゲットとなるプロセスとシステムの「構造」を理解している必要があります。したがって、これらの脆弱性が大規模に悪用される可能性は極めて低いと言えるでしょう。

皆さんは次のような疑問をお持ちかもしれません。自分のシステムにパッチを適用するべきか、それともその必要はないのか?修正によってコンピューターの速度は低下するのか?

答えは「はい」です。軽減策によっては、パフォーマンスが 30% 低下することがあります。パッチについても「はい」です。絶対に適用するべきです。ただし、適切にパッチを適用するには、OS と CPU の両方に対して適用する必要があります。基本的に、OS のパッチは自動的にインストールされるため簡単です。パッチを適用するように促されたら、「はい」と言うだけです。しかし、この問題は CPU 自体のハードウェアおよび構造上の問題であるため、CPU にもパッチを適用する必要があります。通常は BIOS のアップデートが必要で、これにより、コンピューターを起動するたびに「CPU マイクロコード」と呼ばれるパッチが CPU に提供されます。これはセキュリティ上の理由によるものです。CPU の「パッチ」はいずれも恒久的ではないため、CPU が起動するたびに提供される必要があるのです。

パフォーマンスの低下については、場合によって大きく異なります。最大で 30% のパフォーマンス低下があると考えられていますが、ほとんどの場合、それよりも少ないでしょう。パフォーマンスが低下する原因は、メルトダウンの問題を「軽減」し、OS 特権モードのメモリ(カーネル)を保護してコンテンツが非特権モードに流出しないようにするため、OS ベンダーがこの 2 つのメモリ空間をさらに隔離する特別な対策を導入したためです。その結果、特権(カーネル)と非特権(ユーザー)モード間で切り替えるたびにパフォーマンス ペナルティが生じます。ただし、これは切り替えの頻度によって異なります。切り替え頻度は、実行しているアプリケーションの種類によって違います。最新の CPU(Skylake や Kabylake 以降)をお使いの場合、パフォーマンスのオーバーヘッドは 1 桁にとどまります。古い CPU の場合は、より顕著なパフォーマンス低下が見られる可能性があります。

実行すべきこと:

  1. 焦らず、パッチを適用する。
  2. スペクターの最新情報に気を付ける。そして…
  3. 焦らず、パッチを適用する。
--> -->