orangeitems’s diary

40代ITエンジニアが毎日何か書くブログ

インテルCPU脆弱性「Foreshadow」の影響をまとめる

f:id:orangeitems:20180815184739j:plain

 

新たな脆弱性「Foreshadow」

お盆休み明けの多数のエンジニアは、脆弱性「Foreshadow」の情報収集に追われるのではないでしょうか。この記事では、報道されている情報をまとめます。

 

問題となっている脆弱性のコード

CVE-2018-3615 : 「Intel SGX」の利用で保護されたメモリの内容が取得される脆弱性。

CVE-2018-3646 : 仮想マシンやハイパーバイザー経由で保護されたメモリの内容が取得される脆弱性。

CVE-2018-3620 : 「OS」や「システム管理モード(SMM)」において情報を取得される脆弱性。

 

各メディア記事一覧

2018/8/15

Intel CPUの投機実行にサイドチャネル攻撃による新たな脆弱性が発見 - PC Watch

インテルのプロセッサに新たな脆弱性「Foreshadow」--仮想化環境に対する大きな脅威 - ZDNet Japan

【セキュリティ ニュース】Intelチップに脆弱性「Foreshadow」 - クラウドVM間で情報漏洩のおそれも(1ページ目 / 全4ページ):Security NEXT

【セキュリティ ニュース】VMware、脆弱性「Foreshadow」向けにパッチを用意 - 緩和策も(1ページ目 / 全1ページ):Security NEXT

Intel CPUの「SGX」機能に新たな脆弱性、仮想マシンなどにも影響 - ITmedia エンタープライズ

IntelのCPUで新たに発見された脆弱性「Foreshadow」の解説ムービーをRedHatが公開中 - GIGAZINE

 

影響

パブリッククラウドには大きな影響がある

上記のメディア記事をすべて読むと概要は理解できると思います。最もわかりやすい影響はパブリッククラウドの仮想サーバーサービスです。コードで言えば、CVE-2018-3646の方ですね。

物理サーバーの上にはハイパーバイザーというソフトウェアが実行されていて、その上で複数の仮想サーバーを実行しています。したがって、1つの物理サーバー上ではたくさんの会社や個人の仮想サーバーが動いています。物理サーバーの中のメモリーには複数の会社や個人のデータが混在していることになります。

今回の脆弱性を利用した攻撃を任意の仮想サーバーで実施すると、その物理マシン上で動いている別の仮想サーバーのメモリーが読み取れてしまうというのが今回の最も重大な影響です。ただ、これを攻撃するためのコードはまだ公開されていないので、悪意のある第三者が攻撃を成功させることはできていません。しかし、速やかに対応をする必要があります。攻撃のメカニズムについては、GIGAZINEの記事が最もわかりやすいでしょう。

なお、物理サーバーを特定の企業が占有するプライベートクラウド型の利用を行っているのであれば、この攻撃を恐れる必要は全くありません。どの仮想サーバーも特定の企業が利用しているのであれば他のサーバーのメモリーを読むことができても攻撃の意味をなさないからです。

 

対応方法

パブリッククラウドを利用しているユーザーの立場から説明します。

以下の2つがポイントです。

(1)ユーザーが、仮想サーバーにOSベンダーがリリースしたパッチを適用すること
(2)パブリッククラウドベンダーが、CPUのマイクロコードアップデートや、ハイパーバイザーのアップデートなど、適切にアップデートすること

 

(1)ユーザーが、仮想サーバーにOSベンダーがリリースしたパッチを適用すること

まず、ユーザーの自衛方法としてOSのパッチを適用することがあります。他の仮想サーバーからのぞけなくなりますので、パブリッククラウドベンダーの対応を待たずこの方法を取ることは重要だと思います。

 

Redhat

L1TF - L1 Terminal Fault Attack - CVE-2018-3620 & CVE-2018-3646 - Red Hat Customer Portal

 

Windows

https://support.microsoft.com/ja-jp/help/4343898/windows-81-update-kb4343898

 

(2)パブリッククラウドベンダーが、CPUのマイクロコードアップデートや、ハイパーバイザーのアップデートなど、適切にアップデートすること

各パブリッククラウドベンダーは優先的にIntelから情報提供を受けているはずで、CPUやハイパーバイザーのアップデートを速やかに実行するはずです。また、根本的な対応ができるまで緩和策(問題が発生しないようにするための回避策)を実行するでしょう。

例えば、Googleのクラウド基盤であるGoogle Cloud Platformでは、各ユーザーがCPUの論理コアを共用しないようにすることで対策を行っているそうです。

 

Protecting against the new “L1TF” speculative vulnerabilities | Google Cloud Blog

Google Compute Engineは、個々のコアが異なる仮想マシン間で同時に共有されることのないようにするホスト分離機能を採用しています。この隔離によって、異なる仮想マシンが順次スケジュールされる場合、L1データキャッシュが完全にフラッシュされ、脆弱な状態が残らないようになります。さらに、これらの攻撃の特定のクラスに対してホストを監視できるようにするインフラストラクチャを開発し、展開しました。

 

また、Microsoftも同じくクラウド基盤であるAzureにおいて同様に緩和策を行っています。

Guidance for mitigating speculative execution in Azure | Microsoft Docs

投機的実行サイドチャネル攻撃と呼ばれる新たな種類のCPU脆弱性の開示により、より明確なものを求めている顧客からの疑問が生じました。

Microsoftはすべてのクラウドサービスに軽減策を導入しています。Azureを実行し、顧客ワークロードを互いに隔離するインフラストラクチャは保護されています。つまり、同じインフラストラクチャを使用する潜在的な攻撃者は、これらの脆弱性を使用してアプリケーションを攻撃することはできません。

Azureは、可能な限り、顧客の影響を最小限に抑え、再起動の必要性を排除するために、メンテナンスを維持するメモリを使用しています。Azureは、システム全体をホストにアップデートして顧客を保護する際に、これらの方法を利用し続けます。

 

AWSもコメントを出しました。

https://aws.amazon.com/jp/security/security-bulletins/AWS-2018-019/

Intelは、「L1 Terminal Fault」(L1TF)と呼ばれるプロセッサに関する新しいサイドチャネル解析方法に関するセキュリティ勧告(INTEL-SA-00161)を発行しました。AWSは、これらのタイプの攻撃に対する保護機能を備えたインフラストラクチャを設計および実装しており、L1TFに対する追加の保護も導入しています。すべてのEC2ホストインフラストラクチャは、これらの新しい保護機能によって更新され、インフラストラクチャレベルでの顧客対応は不要です。

Amazon Linux AMI 2017.09(ALAS-2018-1058)、Amazon Linux AMI 2018.03(ALAS-2018-1058)、Amazon Linux 2(ALAS-2018-1058)の各カーネルは、それぞれのリポジトリで入手できます。一般的なセキュリティのベストプラクティスとして、お客様は、関連するパッチが新しいサイドチャネルの問題に対処できるようになるにつれて、オペレーティングシステムまたはソフトウェアにパッチを当てることを推奨します。

アップデートされたカーネルを自動的に含むAmazon LinuxおよびAmazon Linux 2 AMIの新しいバージョンをリリースしました。更新されたカーネルを持つイメージのAMI IDは、Amazon Linux 2018.03のAMI ID、Amazon Linux 2のAMI ID、およびAWS Systems Managerのパラメータストアにあります。

一方、ワークロードが異なるセキュリティ権限で実行される場合、オペレーティングシステムのプロセス境界やコンテナに頼るのではなく、EC2インスタンスのより強力なセキュリティと分離プロパティを使用することをお勧めします。

 

 

ユーザーは、利用しているクラウド基盤のベンダーがアナウンスする情報を確認し、本件の対応を行っているか確認すべきです。

GoogleやMicrosoft、AWSのドキュメントを見る限り、今回の問題は、以前から話題となっていた「Specter」や「Meltdown」への対応策によって問題が発生しないようになっているけれども、新たな攻撃方法がまた見つかるかもしれないのでOSは最新にしておくようにというコメントに読めます。

 

したがって、(1)および(2)を明確に確認しておくのが最善策であると思います。

 

まとめ

このIntel CPUの脆弱性の件は、去年から話題になっては、出てくる情報が二転三転しているため日本においてはエンジニアの間でも「結局何をするのがベストプラクティスなのかよくわからない」と言った評価だと思います。

本文で書いたように、もし物理サーバーやプライベートクラウドなど、オンプレミスの環境であればあまり気にする必要はないと思います。物理サーバーの上には単独ユーザーしか存在しないためです。

問題はパブリッククラウドです。AWSやAzure、GoogleやIBM、Oralcleなどのメガクラウドベンダーは、Intelから直接優先的に情報提供を受けているのは間違いありません。社会に脆弱性が公開される前に、情報提供を受け準備をしているように見えます。したがってこれらの基盤を使っているのであれば、ベンダーの対応に任せておけば大きな問題は発生しないと思います(もちろん対応したというエビデンスは必要でしょうが)。なお、もちろんOSのアップデートはユーザーの責任です。

国内クラウドはアメリカ勢ほどの情報提供はもらえていないと思いますので、注意が必要です。例えばニフクラ(旧Nifty Cloud)、さくらのクラウドでは、過去はきちんと対応を行っているように見えます。お使いのベンダーの対応状況をよく確認してください。

CPUの脆弱性に関する対応について【追記あり】 - ニフクラ Information

「クラウド」サービスにおけるMeltdownおよびSpectreへの対応について – さくらのサポート情報

ユーザーも、本件においては厳しい目線でクラウド基盤ベンダーを見る必要があると思います。

 

クラウドエンジニア養成読本[クラウドを武器にするための知識&実例満載! ] (Software Design plusシリーズ)