特別企画

企業のITにおけるMeltdownとSpectreの影響は?

 2018年に入り、重大なプロセッサの脆弱性が公表され、IT業界全体がバタバタしている。今回の脆弱性が深刻なのは、プロセッサのアーキテクチャ部分に根ざす問題だから、確実な対処を行うためには、サーバーのファームウェア、ハイパーバイザー、OS、アプリケーションなど、すべてのレイヤーで対処していく必要があることだ。

MeltdownとSpectreは、どのような脆弱性なのか?

 ここではまず、これまでの経緯を整理してみよう。

 始まりは、1月2日に英国のITメディアThe Registerの記事がきっかけだ。内容としては、「Intelプロセッサのバグが発見された。このバグは深刻で、ソフトウェアで対処しようとすると大幅なパフォーマンスの低下をもたらすため、根本的な対処はハードウェアの変更が必要だ」というものだった。

 この記事では、詳細などは明らかにされなかったが、The Registerの記事がIT業界に波紋を広げた後、Googleの脆弱性調査チームProject Zeroがこの脆弱性の詳細を明らかにした。

 Spectre(スペクター)とMeltdown(メルトダウン)と名付けられた脆弱性は、IntelやAMD、ARMなどのすべてのプロセッサに存在するという。

 SpectreとMeltdownという脆弱性の基本的な部分は、OS自体が使用しているカーネルメモリ領域をプロセッサが保護(バリア)しているが、このバリアを超えてアプリケーションなどがアクセスできるようになる脆弱性だ。Spectreは、Variant1とVariant2が存在する。Meltdownは、Variant3だ。

 カーネルメモリにアクセスできると、OSが内部で処理しているパスワードやデータ、ユーザーアカウントなどが盗み見ることが可能になる。

 SpectreのVariant1は、プロセッサのアーキテクチャとして採用されている投機的実行(speculative execution)のメカニズムを悪用している。投機的実行は、ブログラムで分岐が行われる際、分岐条件がはっきりする前に分岐先のコードをあらかじめ実行しておき、パフォーマンスを上げる仕組みのこと。もし予測が外れれば、投機的に実行しているコードを廃棄する。

 ただ、投機的実行であってもコードを実行するため、カーネルメモリを読み出すことができる(本来なら、投機的実行の結果自体も破棄する必要があるが、厳密に破棄がされていない)。

 Spectreのもう1つのVariant2は、プロセッサの分岐予測や分岐ターゲットバッファを悪用するものだ。

 Spectreは、OSのカーネルなどの特権モードでしかアクセスできない。ただ、OSは外部のプラグインを特権モードで動かすことができるため、Spectreを利用する不正なプラグインが出てくれば、ブラウザ経由でJavaScriptなどのコードを使って、不正アクセスを許すことになる。

 Spectreは、Intelのプロセッサだけでなく、AMDやARMのプロセッサでも起こる。このため、サーバーだけでなく、PCやスマートフォン、IoTデバイスなど、広範囲に影響があるという。

 一方のMeltdownは、Spectreと同じく、プロセッサの投機的実行機能を利用して、ユーザープログラムからカーネルメモリをアクセスするようなコードが実行できる脆弱性。

 基本的に、ユーザープログラムからカーネルメモリにアクセスするのは特権違反でエラーになるが、投機的実行では特権違反でエラーが起こるまでに先のコードを実行してしまう。その後、投機的実行によって実行された結果を保存しているメモリ領域にアクセスすれば不正アクセスが実現する。

 なお、こちらはSpectreよりもやっかいとされている。Spectreは、特権モードで動作しているコードに不正アクセス部分を入れ込む必要があるが、Meltdownは、ユーザープログラムからカーネルメモリにアクセスできるようになるためだ。

 影響を受けるのは、IntelのプロセッサとARMのCortex A75だ。

 なお、特にサーバー向けプロセッサとして多くのシェアを持っているIntelのプロセッサに関しては、第4世代(開発コード名:Haswell)以降のCoreプロセッサが確実に影響を受け、第1世代(同:Nehalem)から第3世代(同:Ivy Bridge)までのCoreプロセッサなどについても影響があるのではと言われている。

 サーバープロセッサXeonの観点から見ると、Xeon E7/E5/E3というブランド名は、E7の最初のモデルを除き、基本的に第2世代Coreプロセッサから採用されているので、E7/E5/E3という名称が付けられたXeonに関しては、すべて影響があると思っていいだろう。

 ちなみに、第8世代(開発コード名:Coffee Lake)や第7世代(同:KabyLake)CoreプロセッサのXeon Scalableはまだリリースされておらず、最新のXeon Scalableは第6世代(同:Skylake)にあたる。

MeltdownとSpectreに関する情報サイト(https://meltdownattack.com/)。こういったロゴが付けられたので、よりニュース化されたのかもしれない

各社の対応が進むが…

 SpectreやMeltdownに関しては、1月2日に記事が公開されて初めて分かったのではなく、2017年末には脆弱性の問題が認識され、対処するためのパッチなどの開発が進んでいたようだ。

 実際Microsoftは、Windows 10/8/7、Windows Server 2008/R2、2012/R2、2016(バージョン1709=Windows 10 Fall Creators Updateと同時期に公開されたServer Coreのアップデート版)などに適用するためのアップデートを、いつもの月例スケジュールの3日前にWindows Updateで公開している。

 ただし、一部のアンチウイルス製品との相性問題があったほか、AMDのプロセッサにおいてトラブルが起こったり、アップデート後のパフォーマンスが大幅に低下するシステムが存在したりといった、さまざまなトラブルが起こっている。

MicrosoftのBlogでは、SpectreやMeltdownにどのように対応していくのかなどが説明されている

 またVMwareでも、ハイパーバイザーのESXi、VMware Workstation、Fusionなどに対してのセキュリティパッチを提供している。Oracleでも、Oracle Database、MySQL、Financial Services Application、Fusion Middleware、Javaなど、フレームワークやデータベース、アプリケーションといった広範囲にわたりパッチを提供した。

 SpectreやMeltdownは、CPUのアーキテクチャ部分に問題が存在するため、最終的には、IntelやAMD、ARMがこれらの問題に対応したプロセッサを新規にリリースする必要がある。ただ現在のプロセッサでも、BIOSやUEFIをアップデートすることでマイクロコードを更新できる。このため、既存のプロセッサであってもある程度の対処が可能になる。

 IntelではアップデートしたコードをOEM各社に提供したと公表しているが、OEM各社が、Intelのコードをベースに自社のPCやサーバーに対してアップデートを行うため、社内の検証などを考えれば、BIOSやUEFIのアップデートは時間がかかるだろう。

 また、多くの企業が利用しているパブリッククラウドに関しても、Microsoft Azure、Amazon Web Services(AWS)、Google Cloudなどがすでに対応を行っている。

 なお、SpectreやMeltdownに関しては、年末や新年といったタイミングで記事になったため、多くの企業が慌てて対応策を示した。セキュリティソフト評価機関AV-TESTでは、Spectre/Meltdownの脆弱性を利用したマルウェアサンプルが発見されたと発表している(2/1現在)。これらのマルウェアサンプルは、Spectre/Meltdownの脆弱性を発表した論文に掲載されている概念実証(PoC:Proof of Concept)コードを利用している。

 SpectreやMeltdownなどの脆弱性を利用するには、プロセッサの内部をよく知り、非常に高度なプログラミングが必要になる。このため、今すぐにSpectreやMeltdownを利用したウイルスが爆発的に広がっていくとは考えられていない。

 PoCコードは、脆弱性があるということを実証しているだけで、実際にSpectre/Meltdown脆弱性を利用してシステムに入り込むコードを書くには、足りない部分がある。

 ただ、PoCコードを利用するマルウェアが出てきた状況を考えれば、近いうちにSpectreやMeltdownなどの脆弱性を利用したウイルスや攻撃が出てくるだろうし、一度こういったウイルスが出てきたら、亜種のウイルスや攻撃も数多く出てくることが予想される。だからこそ、しっかりと対応していく必要があるわけだ。

パフォーマンスに影響も

 SpectreやMeltdownの問題は、プロセッサのアーキテクチャに由来するため、各パッチを適応するとパフォーマンスに問題が出てきているという。特に、第4世代Coreプロセッサ(Haswell)以前の古いプロセッサを搭載しているサーバー、I/Oアクセスの激しいアプリケーションを運用しているサーバーでは顕著なパフォーマンス低下が見られるようだ。

 ただ、どのようなプロセッサで顕著なパフォーマンス低下を示すのか、データベースなどが動作しているサーバーがパフォーマンス低下するのかなど、システムの状況によっても異なるため、一律にパフォーマンス低下するとは言い切れない。

Intelでは、1月10日にクライアントPCのBIOSをアップデート後にパフォーマンステストを公開した。このデータでは、最大14%ほどのパフォーマンス低下だとしている
1月17日には、サーバー向けのファームウェアを使ったパフォーマンステストを公開した。このデータでは、ディスアクセスのベンチマークソフトにおいて大幅な低下が出ている。しかし、OLTPやSaver Side JavaやLinpacなどのベンチマークでは3~5%ほどの低下となっている。このベンチマークテストで使われているのは最新のXeon Scalableプロセッサとなっているため、以前のXeonプロセッサなどではどうなるかは不明だ
MicrosoftのBlogでは、広範囲なプロセッサでのテストも行われている。特にサーバーに関しては、I/Oアクセスが集中したシステムでは顕著なパフォーマンス低下が見られると解説している

 OSやハイパーバイザーなどは、ひとまずSpectreやMeltdown問題に対応したパッチがリリースされているが、アンチウイルスなどとの相性問題があったり、一部のシステムでリスタートを繰り返すなど、問題も多々存在する。

 いつもなら、すぐにWindows Updateやパッチなどを早急に適応すべきと薦めるのだが、今回はもう少し状況が落ち着いてから対応した方がいいだろう(Windows Updateなどは、強制的にすべてのアップデートが行われるため、SpectreやMeltdownに関するパッチだけを不適応にすることはできない)。

 また、Spectre/Meltdownの脆弱性に完全に対応するためには、サーバーベンダーからアップデートされたBIOSやUEFIを更新する必要がある。ただ、Intel社から提供されたコードなどは、クライアントPCで再起動を繰り返すなど問題を起こしている。だからこそ、今回は冷静に各社からアップデートが提供されるのを待ち、トラブルが起こらないのか、少し状況を見てからにした方がいいだろう(最初に提供されたIntelのファームウェアでは一部のシステムでリブートを繰り返すバグがあった)。

 もし、SpectreやMeltdownの脆弱性を利用した攻撃が出てきたら、早急に対処をする必要があるため、IT管理者は自社が持つクライアントやサーバーに対するアップデートの情報を整理しておく必要があるだろう。

 SpectreやMeltdownの脆弱性に対処するためには、BIOSやUEFIのアップデート、OSやハイパーバイザーのアップデート、データベースなどのミドルウェア、アプリケーションのアップデートなどが必要になる。

 こういった状況を見れば、SpectreやMeltdown問題は、一時的な脆弱性としての問題ではなく、長期間にわたって目を光らせていく問題となるだろう。

 今回は、SpectreやMeltdownという脆弱性だったが、プロセッサのアーキテクチャに基づく脆弱性は、これで終わりという訳ではない。プロセッサベンダーは、膨大なコストと人員を掛けてプロセッサを開発しているが、100%完ぺきなプロセッサは存在しない。このため、今後もこのようなプロセッサに由来する脆弱性が出てくる可能性もある。

 プロセッサに由来する脆弱性ではなかったが、2017年にIntelのvProに使われているIntel AMT(Active Management Technology)、Intel Management Engine(ME)、Intel Server Platform Services(SPS)、Intel Trusted Execution Engine(TXE)のファームウェアに脆弱性が見つかり、アップデートが行われている。特にSPSやTXEなどは、昨年発表されたXeon Scalableシリーズにも影響を及ぼしている。

 サーバープロセッサもサーバーの管理性を高めていくため、Intelだけでなく、サーバーベンダー自身がさまざまな管理機能を付け加えている。今後は、こういった部分に関しても注意を払っていく必要がある。

 実際、Intel vProのIntel AMTは、デフォルトパスワードが同じ文字が使われていて、多くのクライアントPCではデフォルトパスワードを変更せずに運用されているため、パスワードを知っていればアクセスができる。こういった管理面での問題点もある。

 IT管理者が管理機能を使っていなくても、ハードウェアとして機能が入っていれば、それが脆弱性となる可能性が高い。個人的には、サーバーベンダーが自社のサーバーに関してのBIOSやUEFIなどのアップデート情報、OSやハイパーバイザーのアップデート情報、データベースなどのミドルウェアやフレームワーク、アプリケーションに関するアップデート情報をまとめたWebサイトなどを運営してくれると情報が集中して分かりやすいと思うのだが。