kabkabsunshine’s blog

読書メモ、投資のこと、日々の学び

vSphere ClientでCVE-2018-3646の脆弱性エラーがでる

Sier

f:id:kabkabsunshine:20190214164501p:plain

直近のVxRailのHCI環境の構築案件で上記エラーが出力されていました。

メッセージを見ると潜在的な脆弱があることが書かれていますが調べていくと対処法が厄介(悩ましい判断を迫られる)なことがわかったので調べた内容を整理しておこうと思います。

実環境のrebuildについては割愛します。

 

メッセージ内容

このホストにはCVE-2018-3646で記述されている問題に対する潜在的な脆弱性があります。詳細およびVMwareの推奨については、https://kb.vmware.com/s/article/55636を参照してください。 

 

VMware社のkb

KB55636について

まずは素直にメッセージにあるkbを確認します。

https://kb.vmware.com/s/article/55636

L1 Terminal Fault(L1TF)という名の脆弱性について記述されています。

L1TFでは以下3つの脆弱性を上げています。

           CVE-2018-3646 の軽減策では、Intel ハードウェアで実行されているホストに対してハイパーバイザー固有の軽減策を行う必要があります。

            CVE-2018-3620 の軽減策では、オペレーティング システム固有の軽減策を行う必要があります。

           CVE-2018-3615 は VMware の製品またはサービスに影響を及ぼしません。 詳細については、KB54913 を参照してください。

CVE-2018-3615についてはVMwareの製品は無視して良さそうです。

CVE-2018-3620については重要度中程度の脆弱性でWindowsやRHELは影響を受けずプリインストールのアプライアンス製品に影響が出ます。HiperVisorには影響なしとの記述があるので、ここでは一旦スルーします。

via:https://kb.vmware.com/s/article/55636

 

問題はメッセージにもあるCVE-2018-3646に絞り込めました。

上記KB55636の中にある3646の解決策は下記です。

CVE-2018-3646 (L1 Terminal Fault - VMM)

ハイパーバイザー固有の軽減策

VMware は、CVE-2018-3646 用のハイパーバイザー固有の軽減策を提供しています。 AMD プロセッサは影響を受けません。 製品固有の軽減策に関する手順または脆弱性分析については、次のナレッジベースの記事を参照してください。

今回はvSphereで出ているメッセージとなるのでKB55806を見る必要があります。

KB55806について

https://kb.vmware.com/s/article/55806?lang=ja

ハイパーバイザーまたは別の仮想マシンが権限を持つ情報が同じコアの L1 データ キャッシュ内に同時に存在する場合は、特定の CPU コアで実行されている悪意のある仮想マシンによってこの情報の内容が実際に推論される可能性があります。 現在の Intel プロセッサは、ハイパースレッディング (HT) 対応コアの両方の論理プロセッサで、物理的に解決された L1 データ キャッシュを共有します。両方の論理プロセッサでソフトウェア スレッドの同時スケジュール設定を無差別に行うと、情報がさらに漏洩する可能性が生じます。

 要約すると複数仮想マシンが同一コアを掴んだ時に悪意のある仮想マシンから別の仮想マシンのL1データキャッシュにアクセスできてしまうというものです。

本来vSphere上の仮想マシンはコアを共有しないのですがハイパースレッティングがハード側で有効になっている環境では1コアが複数スレットに論理的に分割されるため上記にある複数仮想マシンが同一コアを掴むことが可能な状態になります。

 

上記攻撃ベクトルには二種類あります。

  • シーケンシャルコンテキスト攻撃ベクトル：悪意のある仮想マシンは、プロセッサ コアのいずれかの論理プロセッサ上にある以前のコンテキストの L1 データ（ハイパーバイザー スレッドまたは他の仮想マシンのスレッド）の中から、最近アクセスされたものを推測できる可能性があります。
  • 同時コンテキスト攻撃ベクトル：悪意のある仮想マシンは、ハイパースレッディング対応プロセッサ コアの他の論理プロセッサ上にある同時実行コンテキストの L1 データ（ハイパーバイザー スレッドまたは他の仮想マシンのスレッド）の中から、最近アクセスされたものを推測できる可能性があります。

 

KB55806の解決策について

解決策については3つのフェーズの対応が記載されています。

1:更新フェーズ
  1. 更新フェーズ： vSphere の更新およびパッチの適用
シーケンシャルコンテキスト攻撃を軽減するには、VMware Security Advisory VMSA-2018-0020 に記載されている製品バージョンに vSphere を更新します。

この軽減策はデフォルトで有効になっていて、パフォーマンスに大きな影響を与えません。

このパッチは最新版のvSphereを適用することで当たっているようなのです。一安心です。

 

2:計画フェーズ
  1. 計画フェーズ： 環境の評価
同時コンテキスト攻撃ベクトルを軽減するには、VMSA-2018-0020 に示されている更新およびパッチに含まれている ESXi サイドチャネル対応スケジューラを有効にします。 デフォルトでは、このスケジューラは有効ではありません。 このスケジュールを有効にすると、vSphere 環境で実行されているアプリケーションのパフォーマンスに大きな影響が及ぶ可能性があります。 計画フェーズの目標は、同時環境に、スケジューラを有効にしても動作に影響が生じないようにするために必要な CPU キャパシティがあるかどうかを把握することです。
次のリストに、ESXi サイドチャネル対応スケジューラを有効にした後に生じる可能性のある問題領域の概要を示します。
  • ESXi ホストで使用できる物理コアの処理能力を上回る vCPU が装備された仮想マシン
  • カスタム アフィニティまたは NUMA が設定された仮想マシン
  • 遅延の影響を受ける構成の仮想マシン
  • 平均 CPU 使用率が 70% を超える ESXi ホスト
  • カスタム CPU リソース管理オプションが有効になっているホスト
  • ローリング アップグレードによって平均 CPU 使用率が 100% を超える HA クラスタ
重要： 上記のリストは、ESXi サイドチャネル対応スケジューラの有効化に関連する問題領域の概要を示すためのものです。 VMware パフォーマンス チームは、KB55767 で詳細なガイドおよびパフォーマンス データを公開しています。 スケジューラを有効にする前に、このドキュメントを詳細に確認することを強くお勧めします。
注： ESXi サイドチャネル対応スケジューラを有効にする前に、追加のハードウェアを取得するか、既存のワークロードを再分散しなければならない可能性があります。 組織は、リスク評価を行って同時コンテキスト攻撃ベクトルで発生するリスクを受け入れた後に、ESXi サイドチャネル対応スケジューラを有効にしないように選択することができます。 この方法はお勧めしません。VMware が組織に代わってこの決定を行うことはできません。

重要なので長々と引用しましたが、"ESXi サイドチャネル対応スケジューラ"を有効にすることで、同時コンテキスト攻撃の対策になるが、これを実施するとパフォーマンスに大きな影響があるとのことです。

 

（私が直接確認している訳では無いのですが）

上記対応を社内で検証したメンバー曰く"ESXi サイドチャネル対応スケジューラ"を有効にしたところESXiの物理CPUのスレット数が半分になって起動してきたとのことです。これについては各KBの中で記載が見つけらていのですがこれがパフォーマンス劣化の原因と考えています。

 

パフォーマンスの影響については下記に詳細が(脆弱性系の調べ物って本当にあっちこっちに飛ばされて辛いです。)あります。

https://kb.vmware.com/s/article/55767?lang=ja

VMware のテストでは、ESXi サイドチャネル対応スケジューラを有効にした結果、ワークステーション、ホスト使用率、およびホスト内で使用されているプロセッサ数に応じて、ホストの最大パフォーマンス キャパシティが 30% 減少しました。 これは、アプリケーションのパフォーマンスが必ず 30% 減少するという意味ではないことにご注意ください。 

必ずしもではないもの30%となるとこれは大問題です。おそらくコア数に対する仮想マシンの数がオーバコミットすればするほどにどんどんCPUのwaitが上がってパフォーマンスが劣化すると予測しています。

 

注： ESXi サイドチャネル対応スケジューラを有効にする前に、追加のハードウェアを取得するか、既存のワークロードを再分散しなければならない可能性があります。 組織は、リスク評価を行って同時コンテキスト攻撃ベクトルで発生するリスクを受け入れた後に、ESXi サイドチャネル対応スケジューラを有効にしないように選択することができます。 この方法はお勧めしません。VMware が組織に代わってこの決定を行うことはできません。

この対応を実施する前に追加のハードウェアを取得しろと書かれています、、、、このトレードオフに素直に従うユーザどれだけいるのか疑問が残ります。

3.スケジューラ有効化フェーズ
  1. スケジューラ有効化フェーズ： ESXi サイドチャネル対応スケジューラの有効化
計画フェーズで上記の問題領域を解決した後に、CVE-2018-3646 の同時コンテキスト攻撃ベクトルを軽減するには、ESXi サイドチャネル対応スケジューラを有効にする必要があります。

 

VxRail(EMC)の見解

現在構築中の案件はVxRailを採用しているためEMC側の見解が知りたいところです。EMCも本脆弱性についてナレッジを出しています。

EMC Community Network - DECN: VxRail: 「このホストにはCVE-2018-3646で記述されている問題に対する脆弱性があります。 詳細およびVMwareの推奨については、https://kb.vmware.com/s/article/55636を参照してください」の警告、及びL1TF/Foreshadow問題への対応

 

内部VCSA利用環境 VxRailが4.0.520、または4.5.218以上
外部vCenter利用環境 vCenterが6.0 U3hまたは6.5 U2c

上記環境で当該メッセージが出るとのこと。現行バージョンだと出てしまうということです。(VxRailではVxRailのバージョンに紐づいてESXiやVC(内部VCSAの場合)のバージョンが決まります)

概ねVM社のナレッジからの抜粋となっていますので違うところについて。

CVE-2018-3620について

CVE-2018-3620はゲストOSレベルの脆弱性です。

VxRailのサービスVM(VxRail Manager、VCSA、PSC)への対処は、VxRailが4.0.520・または4.5.218以上にアップグレードされた時点で完了します。

お客様の仮想マシンについては、ゲストOSごとの対処を行う必要があります。

外部vCenterをご利用のお客様は、外部vCenterを6.0u3hまたは6.5u2c以上にアップグレードする必要があります。

 

CVE-2018-3646について

CVE-2018-3646はハイパーバイザレベルの脆弱性です。

対処には、VxRailを4.0.520・または4.5.218以上アップグレードした後、ESXi SCA Scheduler(ESXiサイドチャネル対応スケジューラ)を有効化する必要があります。

ESXi SCA Scheduler(ESXiサイドチャネル対応スケジューラ)の有効化には、CPUパフォーマンスへの影響を伴う場合があります。

 3620については解消済みとの記載がありました。

また警告の抑止手順を案内した上で下記の文言で閉じています。

--------------------------------------------------------------------------------------------------------------------------------------

Dell/EMC/VMware のうちどのベンダーも、当該問題についてお客様に取っていただくべき対応方針を案内・推奨・手引きすることはできません。

当該問題により発生し得るお客様ビジネス・セキュリティコンプライアンスへのリスク、及び問題への対処に必要なクラスターリソースを確認いただいた上で、お客様自身で対応方針を策定いただく必要があります。

--------------------------------------------------------------------------------------------------------------------------------------

まとめ

  • 本エラーの解決策の対応をするには"ESXi サイドチャネル対応スケジューラ"を有効化する必要がある。
  • 対応しない場合はCVE-2018-3646の脆弱性対策はできない。
  • 有効化した場合はオーバーコミットしている環境では大きなパフォーマンス劣化の可能性を孕んでおりこれに対応するにはノードを増やしてCPUコア数を稼いでオーバーコミット防ぐ必要がある