カーネルのサイドチャネル攻撃 - CVE-2017-5754 CVE-2017-5753 CVE-2017-5715

影響を受ける製品

Red Hat Product セキュリティーチームは、本件によるセキュリティー上の影響度を重要と評価しています。

以下の Red Hat 製品バージョンが影響を受けます。

• Red Hat Enterprise Linux 5

• Red Hat Enterprise Linux 6

• Red Hat Enterprise Linux 7

• Red Hat Atomic Host

• Red Hat Enterprise MRG 2

• Red Hat OpenShift Online v2

• Red Hat OpenShift Online v3

• Red Hat Virtualization (RHEV-H/RHV-H)

• Red Hat Enterprise Linux OpenStack Platform 6.0 (Juno)

• Red Hat Enterprise Linux OpenStack Platform 7.0 (Kilo) for RHEL7

• Red Hat Enterprise Linux OpenStack Platform 7.0 (Kilo) director for RHEL7

• Red Hat OpenStack Platform 8.0 (Liberty)

• Red Hat OpenStack Platform 8.0 (Liberty) director

• Red Hat OpenStack Platform 9.0 (Mitaka)

• Red Hat OpenStack Platform 9.0 (Mitaka) director

• Red Hat OpenStack Platform 10.0 (Newton)

• Red Hat OpenStack Platform 11.0 (Ocata)

• Red Hat OpenStack Platform 12.0 (Pike)

Red Hat Linux コンテナーはカーネル問題の影響を直接受けませんが、そのセキュリティーはホストカーネル環境の整合性に依存しています。Red Hat では最新バージョンのコンテナーイメージを使用することを推奨します。Red Hat Container Catalog の一部である Container Health Index を使用すると、常に Red Hat コンテナーのセキュリティー状態を確認できます。使用中のコンテナーのプライバシーを保護するには、これらの攻撃に対して (Red Hat Enterprise Linux や Atomic Host といった) コンテナーホストを更新する必要があります。Red Hat では、このユースケース用に更新済み Atomic Host をリリースしています。

攻撃の詳細と影響

この記事で説明している攻撃は、高パフォーマンスマイクロプロセッサーの投機的実行機能を悪用します。現代のマイクロプロセッサーは「アウトオブオーダー」(OoO) 実行と呼ばれるデザイン最適化を実装しており、常にプログラマーがアプリケーションバイナリーで提供する順番ではなく、個別の命令のデータ依存関係が利用可能になるとすぐに (「データフロー」モデルと呼ぶ) 実行されます。実行が順次行われているように見えるのは、プロセッサーのこれら中間実行状態をバッファリングして順序立った結果を表示する内部の各種並び替え構造によるものです。「アウトオブオーダー」(OoO) 実行は元々、1967 年に Robert Tomasulo 氏が初期の IBM メインフレームシステム向けに考案したものです。その後、ほとんどすべてのマイクロプロセッサーの標準機能となりました。

アウトオブオーダー実行モデルの拡張により、高度に洗練された分岐予測アルゴリズムがもたらされ、ソフトウェアの特定のパス (分岐) を実行するかどうかを予測するようになりました。分岐は、“if this, then do A, otherwise do B” のフォームにある “if” ステートメントに対して、プロセッサーが実行中の命令のフローを変更するものと考えられます。分岐するまたは分岐しないことを決定する条件は、すぐには利用可能とならないデータに依存することが多くあります (たとえば、遅い RAM から内部マイクロプロセッサーキャッシュの階層への読み取りが必要な場合など)。分岐条件がすぐに利用可能でないため、プロセッサーは分岐予測からの入力に基づいて、最も可能性の高いパスを推測によって実行し始めます。この実行による結果は、予測した分岐方向が後で間違ったことが分かった場合には、パス全体を破棄できる方法で保存されます。このため、投機的実行は通常、プログラマーや同一システムの他のユーザーにはまったく見えないようになっています。

この記事で説明している攻撃は、投機的実行中のマイクロプロセッサーの内部状態というブラックボックスを開くことに依存しています。特に、キャッシュのサイドチャネル分析というテクニックに依存しています。プロセッサーは投機的実行中に、プログラマーや他のプロセッサー、他の実行中のアプリケーションに対して、メモリーやレジスターにおいてその結果を即座に利用可能としません。ただし、予測されるコードパス内のメモリーにアクセスするには、データをプロセッサーキャッシュに持ち込む必要があります。サイドチャネル分析を使用すると、攻撃者はシステムキャッシュへの予測された割り当て (読み込み) を監視することが可能になります。これには、結局は破棄されることになる実行パスからの割り当ても含まれます。この場合、特別なプログラムにより、権限を必要とするメモリーの場所からのキャッシュを予測によって読み込み、その結果を監視できるようになり、その結果を使用して権限を必要とするメモリーのコンテンツを推測することが可能になります。

CPU の投機的実行を開始するトリガーの 1 つは分岐です。攻撃者は、カーネルコード内で特定の分岐がよく分岐する (または分岐しない) ように分岐予測を訓練し始めます。次に分岐が実行されると、プロセッサーは、攻撃者が選択した方向にコードを実行し始めます。メモリーから値を読み込むパスを攻撃者が選択した場合、その読み込みは推測によって実行されます。(影響を受けるマイクロプロセッサー実装のいくつかでは) 分岐予測に対する攻撃はカーネル/ハイパーバイザーの境界を超えることが可能で、権限のないゲストオペレーティングシステムがハイパーバイザーに対して影響力を持つようになり、サイドチャネル分析を一緒に用いることで、ハイパーバイザーの秘密メモリーを抽出できるようになります。

投機的実行の影響は、これだけにとどまりません。マイクロプロセッサーの内部状態はプログラマーや他のユーザー、システム上で実行中のアプリケーションには見えないため、推測によるデータアクセスが許可されるかどうかをチェックする前に、プロセッサーがこのデータアクセスを実行する場合があります。パーミッションのチェックは同時並行で行われ、予測された命令をリタイアする前に、最終的に予測の中止がトリガーされ、実行結果がプロセッサーの外に見えるようになります。パーミッションのチェック前にプロセッサーが推測によってメモリーからキャッシュ済みデータを使用すると、その後に続くメモリーアクセスでそのデータを使用することで、データを監視できるようになります。

パーミッションチェックの一例にメモリー管理ユニット (MMU) からのページアクセスチェックがあります。仮想メモリーとも呼ばれるページングは、高パフォーマンスマイクロプロセッサーの一般的機能です。システム RAM の物理アドレスへの仮想アドレスのマッピングをオペレーティングシステムが制御できるようにし、アクセス制御で仮想アドレスへのアクセスも制限します。たとえば、(書き込みによってページフォールト例外が発生するように) ページを「読み取り専用」とマークしたり、(ユーザーモードアクセスによってページフォールト例外が発生するように) 「カーネルメモリー」とマークすることができます。

プロセッサーのパーミッションチェックにより、ユーザーアプリケーションはカーネルメモリーにアクセスできないため、オペレーティングシステムカーネル (Linux を含む) がカーネル仮想メモリーアドレスをユーザーアプリケーションと同じアドレス空間にマッピングすることは、業界の標準プラクティスとなっています。。アプリケーションはカーネルが提供するシステムコールを頻繁に使用し、各システムコール中のアドレス空間の切り替えにより多大なパフォーマンスのオーバーヘッドが発生するので、この方法ではパフォーマンスが大幅に向上します。切り替えでは、多くの内部 CPU 構造のコンテンツをフラッシュ (無効にする) 必要があります。これには、仮想から物理メモリーへの変換をキャッシュし、仮想メモリーの使用を加速する TLB (トランスレーションルックアサイドバッファ) などがあります。

ただし、カーネルとユーザーアプリケーション間でページテーブルを共有することで、投機的実行に対して別の攻撃が可能となります。この場合、準備段階で攻撃者は、カーネルに「興味のある」仮想アドレスをプロセッサーのレベル 1 (L1) データキャッシュに読み込ませます。L1 データキャッシュは通常、VIPT (Virtually Indexed, Physically Tagged) と呼ばれるテクニックで構造化されており、これは仮想から物理へのアドレス変換とパーミッションチェックをアクセスと並行して行います。共有の仮想アドレス空間があると、カーネルの権限がある仮想アドレスには、投機的実行中に信頼されないユーザーコードが L1 キャッシュを使って推測によってアクセスできるようになります。また、読み込まれた値を、推測によって実行されたパスでさらに使用することが可能となります。このため、2 回目の推測によるメモリーアクセスでは、権限を必要とするメモリーコンテンツに依存した方法でキャッシュを満たし、それらのコンテンツを引き出すことが可能になります。

このようなマイクロプロセッサーのサイドチャネル攻撃では、マシンにアクセスのある信頼できないユーザーが、権限を必要とするカーネルやハイパーバイザーメモリー、同一システムで実行中の他のアプリケーションや仮想マシンから秘密情報を引き出せるようになります。この脆弱性を軽減するには多くの別々のステップが必要となります。マイクロプロセッサーのメーカーやモデルによって、これらの一部またはすべてが必要になる場合があります。各マイクロプロセッサーの脆弱性は、それぞれのバリアントに対して異なる範囲である可能性があります。

• カーネルとユーザー仮想アドレス空間を分離する: これを実行するには、KPTI (Kernel Page Table Isolation) と呼ばれるオペレーティングシステムのカーネルへの設計変更を用います。KPTI は 「KAISER」と呼ばれることもあります。
• カーネルまたはハイパーバイザーへのエントリーの際に、間接的な分岐予測を無効にする: マイクロコードやミリコード、ファームウェア、その他のアップデートによって、業界全体にわたり多くのマイクロプロセッサーに新機能が追加されてきました。これらの新機能は、それらの使用を管理する Red Hat Enterprise Linux への更新によって活用されます。
• 特定メモリーの場所の推測による読み込みのフェンシング: このような読み込みは、Linux カーネルへの小さな変更で注釈を付ける必要があり、これは Red Hat 更新に統合されています。

これらのソフトウェアの解決策は、マイクロコードやミリコード、ファームウェアの更新を合わせることで、本記事に記載の攻撃を軽減することができますが、システムのパフォーマンスにマイナスの影響が出ます。特定のシステム、マイクロプロセッサーのメーカーやモデル、さらにはワークロードの性質によって、パフォーマンスへの影響は多大なものになる場合があります。Red Hat では、ユーザーがそれぞれの環境を評価して、選択的に各種の軽減策を有効または無効にできるようにすることで柔軟に適切な妥協点を見つけられるようにする一方、パフォーマンスよりもセキュリティーを優先するプロアクティブな立場を採用しています。

Red Hat Performance Engineering チームでは Knowledgebase article で、各種のワークロードで観測されたパフォーマンスへの影響をお知らせしています。また、お客様のコンピューターが間違いなく物理的に分離されている場合に、望ましいパフォーマンスレベルに戻すために、セキュリティーフィクスの一部を無効にするオプションについても説明しています。追加のパフォーマンスデータは、本件の進展に従って公表していきます。

Red Hat Performance Engineering および Product Engineering チームでは Knowledgebase article で、これらの新たなセキュリティー機能を有効または無効にできる設定の詳細について説明しています。

AMD ベースのシステムをお使いのお客様には、こちらの ナレッジベースのアーティクルで追加情報を説明しています。

検出 & 診断

システムの脆弱性の判断

Red Hat では、これらの脆弱性への露出を検出する Labs アプリケーションを作成しました。サブスクリプションをお持ちのお客様は、こちらのリンク から Labs ツールにアクセスいただけます。

こちらから入手可能な診断スクリプトを使用して、現在ご使用のシステムにこの不具合による脆弱性が存在するかどうかを判断できます。正規のスクリプトであることを確認するには GPG 分離署名 もダウンロードします。このスクリプトの現在のバージョンは 2.4 です。

Red Hat Virtualization 製品をお使いの場合は、こちらのナレッジベースの記事を参照して OEM 提供のマイクロコード/ファームウェアが適用されているか確認してください。

対処方法

影響を受けるバージョンの Red Hat 製品をご使用のお客様は、エラータが利用可能になり次第、更新を行うことが強く推奨されます。適切な更新を早急に適用することが求められます。影響を受ける製品ではすべて、CVE-2017-5753 (バリアント 1)、CVE-2017-5715 (バリアント 2)、および CVE-2017-5754 (バリアント 3) の 3 つのバリアントを軽減するフィクスを適用してください。

注記

• CVE-2017-5754 (バリアント 3) は「Meltdown」と呼ばれています。
• CVE-2017-5753 (バリアント 1) と CVE-2017-5715 (バリアント 2) は、合わせて「Spectre」と呼ばれています。
• 必要となる変更の性質上、Red Hat Enterprise Linux 7.2 以降を実行しているお客様は、kpatch を利用できません。
• バリアント 2 はローカル (同一 OS 内) または仮想化ゲストの境界を超えた両方の悪用が可能です。フィクスが機能するには CPU マイクロコード/ファームウェアが必要です。ハードウェア OEM に連絡して、プロセッサー用に適切なマイクロコード/ファームウェアを入手してください。詳細については、こちらの Knowledgebase article を参照してください。
• セキュリティーエラータの説明は、注意深く読んでください。すべてのアーキテクチャー向けに初めから軽減策がリリースされているわけでありません。x86_64 の軽減策には Red Hat Enterprise Linux 6 32bit カーネルは含まれません。
• Red Hat OpenStack Platform をお使いのお客様は、別の Knowledgebase article も参照してください。
• Red Hat Satellite 6 をお使いのお客様は、Satellite 6 に関する別の Knowledgebase article も参照してください。注記: お使いのシステムに適用する RHSA の ID については、下記の表を参考にしてください。

影響を受ける製品の更新

*このパッチを取得するには、有効な ELS サブスクリプションが必要です。お持ちのアカウントに有効な ELS サブスクリプションがない場合は、Red Hat の営業部門または営業担当者に お問い合わせ ください。

**このパッチを取得するには、有効な EUS サブスクリプションが必要です。お持ちのアカウントに有効な EUS サブスクリプションがない場合は、Red Hat の営業部門または営業担当者に お問い合わせ ください。

Red Hat Enterprise Linux Extended Update Support サブスクリプションとは何ですか?

*** RHEL AUS のパッチを入手するには、有効な AUS サブスクリプションが必要です。

What is Advanced mission critical Update Support (AUS)?

****RHEL TUS のパッチを入手するには、有効な TUS サブスクリプションが必要です。

***** ハードウェア OEM に連絡して、最新バージョンの CPU マイクロコード/ファームウェアを入手してください。

軽減策

ハードウェア OEM の CPU ミリコード/ファームウェアと合わせてベンダーのソフトウェア更新を適用する以外には、既知の軽減策はありません。Red Hat のお客様は、ベンダーの解決策を CPU に適用し、パッチが利用可能になり次第、カーネルを更新してください。

この問題を軽減するには、リスクベースのアプローチを適用することが推奨されます。高レベルのセキュリティーと信頼を必要とするシステムに最初に対処し、他の信頼できないシステムにエクスプロイトのリスクを低減する対処法が適用されるまで、これらのシステムから高レベルのセキュリティーと信頼を必要とするシステムを分離してください。

Xen ハイパーバイザーを使用しているお客様は、このソフトウェアではバリアント 2 エクスプロイトを完全に除外できず、準仮想化ゲスト上ではバリアント 3 エクスプロイトを除外できないという、技術的制限に注意してください。Red Hat では、Knowledgebase article で Xen の状況と Xen ハイパーバイザーユーザーが利用可能なオプションについて説明しています。