コラム

CTC教育サービス・ホーム　＞　コラム　＞　OpenStack海外動向　＞　第15回　OpenStack利用者が知っておくべき脆弱性：「スペクター」と「メルトダウン」について

OpenStack海外動向

CTC 教育サービス

[IT研修]注目キーワード Python UiPath(RPA) 最新技術動向 Microsoft Azure Docker Kubernetes

第15回　OpenStack利用者が知っておくべき脆弱性：「スペクター」と「メルトダウン」について (野田貴子) 2018年2月

こんにちはー。野田貴子です。今回はOpenStack関連のコラムで面白いものがあったので意訳版をお届けします。昨今、OpenStackの注目度が高まっており、OpenStack開発者メーリングリストやコラムをチェックしている人も多いと思います。英語が苦手な方にとっては、日本語で要約版があると助かるのではないかと考え、日本語意訳したものをお伝えすることにしました。
興味がある方はご覧ください。海外動向を理解する上での参考になれば幸いです。

###

OpenStack FoundationのVP of Engineeringであり、OpenStack Technical Committeeの議長でもあるThierry Carrez氏が、「スペクター（Spectre）」および「メルトダウン（Meltdown）」と呼ばれるセキュリティ上の脆弱性に関する考えを述べました。

「メルトダウン」とは？「スペクター」とは？

「メルトダウン」と「スペクター」は、現代のCPUのパフォーマンスを最適化させる技術に関連する脆弱性につけられた名前で、方々のセキュリティ専門家によって発見されました。このCPU最適化（スーパースカラ機能、アウトオブオーダー実行、投機的分岐予測など）によって作成されるサイドチャネルを悪用すると、通常はアクセスできないコンピュータメモリの内容を推測することができてしまいます。

Thierry Carrez氏：「解決策はいつでも同じです。深い防御を設計し、見つかった脆弱性を追跡し、パッチを迅速に適用することです。」

これが大ニュースになったのはなぜでしょうか？

これらの脆弱性は特定のOSだけに影響を及ぼすのではなく、現代のほとんどのCPUに修復不可能な影響を与えてしまうからです（CPUから欠陥のある部分だけを物理的に取り出すことができないため）。本当の解決策は、現行のCPUの性能を落とさずに、同じ欠陥を持たない新世代のCPU最適化を実装することです。ただしこれはすぐに実現できることではないため、我々は回避策や緩和パッチをこれからしばらく扱わなければならないでしょう。

他の脆弱性と同じようにパッチでうまくいくのでしょうか？

Bruce Schneier氏は次のように述べています。「自分が理解できないものを保護することはできません」と。複雑なシステムほど安全性を保つのが難しく、その方法もより巧妙になります。新しい脆弱性が常に存在し、新種の攻撃が発見されますが、その対応策は常に同じです。深い防御を設計し、見つかった脆弱性を追跡し、パッチを迅速に適用することです。この脆弱性は大きなニュースかもしれませんが、解決策にはよく知られている技術とプロセスが利用されます。

これらの脆弱性は別物ですか？

「スペクター」と「メルトダウン」は実際には同じ脆弱性ファミリーに含まれる3つの悪用技術であり、それぞれ個別に防御する必要があります。

CVE-2017-5753（「bounds check bypass」または「亜種1」）は、2つあるスペクター変形の1つです。これはバイナリベースで処理される必要があるアプリケーションがコンパイルされたあと、その中の特定のシーケンスに影響を与えます。信用できないコードでも実行してしまうアプリケーション（例えば、OSのカーネルやWebブラウザ）には、そのような悪用可能なシーケンスの多くが見つかるため、更新が必要となります。

CVE-2017-5715（「branch target injection」または「亜種2」）は、もう1つのスペクター変形です。これはCPUブランチ予測キャッシュを汚染して特権アプリケーションを誘導し、小さな情報ビットを漏洩させます。この脆弱性は、CPUのマイクロコードを更新したり、脆弱なバイナリに高度なソフトウェア緩和技術（Google Retpolineなど）を適用したりすることで、解決できます。

CVE-2017-5754（「rogue data cache load」または「亜種3」）もメルトダウンと呼ばれます。この技術により、特権のないプロセスからもカーネルメモリを読み取ることができるようになります（つまり、同じシステム上で実行されている他のプロセスの情報や秘密にアクセスすることができてしまいます）。これが一番簡単な悪用方法であり、カーネルレベルでメモリページテーブルの分離を強化するためにはOSにパッチを当てる必要があります。

これらの脆弱性はOpenStackクラウドユーザーにどのような影響を与えますか？

インフラとしてのサービスは仮想化やコンテナ化技術をつなぎ合わせて、仮想コンピューティングリソースとして一連の物理的なベアメタルリソースを提示しています。信頼できないワークロード、特に同じ物理ホスト上で実行されているさまざまな仮想マシンを適切に分離するためには、ホストカーネルのセキュリティ機能がとても重要です。分離に失敗すると（ここの場合）、ハイパーバイザーを中断させることができてしまいます。パッチが適用されていないホストカーネル上で実行されている仮想マシンにいる攻撃者は、これらの手法を悪用して、同じホスト上で実行されている別の仮想マシンのデータにアクセスすることが可能です。

さらに、仮想マシンのゲストOSにパッチが適用されていない（または脆弱なアプリケーションを実行している）場合、その仮想マシン（あるいはそのアプリケーション）で信頼できないコードを実行すると、そのコードがこれらの脆弱性を利用して、同じ仮想マシンの別のプロセスのメモリ内の情報にアクセスすることができます。

OpenStackクラウドプロバイダーがするべきことはなんですか？

クラウドプロバイダーは自分たちのユーザーを保護するために、準備ができ次第、（Linuxディストリビューションの）カーネルパッチ、（ディストリビューションまたはベンダーの）ハイパーバイザーのソフトウェア更新プログラム、（ハードウェアベンダーの）CPUマイクロコード更新プログラムを適用し、これらの脆弱性を回避または緩和するべきです。

OpenStackクラウドユーザーがするべきことはなんですか？

クラウドユーザーは、ゲスト仮想マシンのOSパッチの準備ができ次第これを適用する必要があります。このアドバイスはみなさんが使用することになったコンピュータ（仮想であれ物理であれ）すべてに当てはまります（電話も含みます）。

パッチはもう利用可能でしょうか？

すでにいくつかのパッチが出ていますが、残りのパッチがこれから公開される予定です。メルトダウン攻撃を緩和するカーネルパッチはアップストリームで入手できますが、多くの副作用を伴う重大なパッチであり、まだそれらのパッチをテスト中のOSベンダーもあります。このパッチは公開日まで秘密にされる予定でしたが、漏れてしまいました。このニュースが漏れたときにまだ準備ができていないOSベンダーやディストリビューションがあったのはこのためです。

もうひとつ重要なことは、これらの複雑なパッチが作り出してしまう副作用や新しいバグを減らすために、パッチ自体を精査する必要があり、それによって次々と新しいパッチが公開され続ける可能性があるということです。みなさんはぜひとも、今後数ヶ月間、自身が利用しているOSベンダーのパッチ（およびCPUベンダーのマイクロコードのアップデート）情報に目を向けて、すべてのパッチを迅速に適用するようにしてください。

これらのパッチを適用するとパフォーマンスが低下してしまいますか？

パッチはまだ開発中ですので言及するには少し早すぎるかもしれませんが、こういうことは通常、作業負荷次第となります。ただし、今回の欠陥はCPUのパフォーマンス最適化手法にありますので、ほとんどの回避策や緩和パッチでは、そのパフォーマンス最適化の一部を昔に戻すためのチェックやステップ、同期が追加されることになるため、パフォーマンスは低下することになるでしょう。

OpenStack側で何かパッチを当てるべきでしょうか？

OpenStack自体はこれらの脆弱性の直接的な影響を受けませんが、この問題を緩和するために開発されているパッチの中には、パフォーマンスの影響を広げないためにソフトウェアのコードの最適化が必要なものもあります。OpenStackの安定ブランチやベンダーパッチの動向を追って、適宜対応するようにしてください。

これらの脆弱性は、サイドチャネル攻撃の威力も明らかにしています。昔から共有システムというものは脆弱になりがちです。セキュリティの専門家は近い将来この種の問題に焦点を当てる可能性があり、修正が必要なOpenStackのサイドチャネルセキュリティ攻撃を発見することになるかもしれません。