IT業界を震撼させたメルトダウンとスペクター ～ OSは信頼出来るのか ?(その2)
今回のブログは、前回紹介した「メルトダウン(Meltdown)」と「スペクター(Spector)」に関する情報の第2弾となります。
★過去ブログ：IT業界を震撼させたメルトダウンとスペクター(その1)
前回は、第1弾として、次の情報を紹介しました。
- コンピューターの仕組み
- CPUとは
まあ、前回は、「メルトダウン」と「スペクター」と言うCPUの脆弱性を紹介する前段階として、コンピューターの基礎知識を紹介するだけに終わってしまいましたが・・・
しかし、最後に付け加えた「量子コンピューター」に関しては、今後、どんどん発展し続け、あと10年後、早ければ5年後位には、現在の「スーパー・コンピューター」の様に、普通に運用される日が来ると思います。
さらに、次の3つを組み合わせる事で、現在では、不可能とされている様々な事が実現されているのではないかと思います。そう考えると、何かワクワクして来ます。
・量子コンピューター
・AI(Artificial Intelligence )
・5G(第5世代移動通信システム：5th Generation)
--------------------------------------------------------------------------------------------------------
このように、現在のIT業界は、久しぶりに、新しい技術革新を迎え、非常に楽しい状況になってはいますが・・・
一方では、この明るい動きに水を指す、今回のブログで取り上げたCPUに関する致命的な設計ミスも明らかになっています。
そこで、今回は、「メルトダウン」、および「スペクター」関して、次のような内容で、脆弱性を誘発した処理、および実際の原因に関して、詳しく図解したいと思います。
それでは今回も宜しくお願いします。
■脆弱性「メルトダウン(Meltdown)」とは
さて、それでは、今回問題となった「メルトダウン(Meltdown)」が発生する仕組みを紹介します。
「Meltdown」は、CPUの高速処理を実現するための「アウト・オブ・オーダー実行(Out of Order execution）」と言う仕組みが原因で発生します。
この脆弱性に関しては、2018 年 1 月 3 日、オーストリアのグラーツにある「Graz University of Technology（グラーツ工科大学）」の研究者と、Google社の脆弱性発見チーム「Project Zero」、およびドイツにある「Cyberus Technology」社によって発見されたと言われています。
「アウト・オブ・オーダー実行」とは、高性能プロセッサにおいて、クロック当たりの命令実行数（IPC値）を増やし性能を上げるための手法の1つで、機械語プログラム中の命令の並び順に依らず、データなどの依存関係から見て処理可能な命令については、逐次処理を開始して実行させて完了させる仕組みです。
つまり、処理の高速化を図るために、出来る限り処理を並列実行させる事を意味します。
「アウト・オブ・オーダー実行」は、結果(意味)に影響を与えないことを保証しながら、可能な限り順序に従わずに処理をどんどん実行することにより、複数命令の同時実行の可能性を広げる最適化手法の1つとされています。
このため、前処理で「例外エラー」等が発生すると、先に実行していた後処理は、処理結果を保証するために取り消される事になります。
ところが、後処理を、どんどん並行に処理しているため、処理が取り消されても、その処理履歴等は、OSのキャッシュ領域に残されたままになります。
これが、「Meltdown」の引き金となってしまうのです。
ちなみに、「アウト・オブ・オーダー実行」に対して、処理を順序通り、シリアルに実行することを、「イン・オーダー実行」と言います。
それでは、どうして「アウト・オブ・オーダー実行」が「Meltdown」の引き金になるのかを下記で説明します。
--------------------------------------------------------------------------------------------------------
(1)プログラムの処理が、「処理①」、「処理②」、そして「処理③」の順番で実行するプログラム群を用意する。
(2)各プログラム(処理)は、次のような順番で、それぞれの処理を行う。
①「処理①」 ：一定時間間隔で、特定のキャッシュ領域を参照して、その特定領域にあるデータを、自身のプログラム内部に取り込む処理を行う。
②「処理②」 ：保護された領域に保存されている「パスワード」を参照し、「パスワード」を取得する処理を行う。
③「処理③」 ：「処理②」のアクセス履歴を元に、保護領域にある「パスワード」を、OSのキャッシュ領域に移動させる処理を行う。
(3)上記プログラムの内、一定時間間隔で同じ処理を繰り返す「処理①」を実行する。
(4)次に、保護された領域にあるパスワードを取得する「処理②」を実行する。
(5)「処理②」を実行すると、権限不足が原因で保護例外エラーが発生して処理が中断される。
(6)「アウト・オブ・オーダー実行」により、「処理②」の実行前に「処理③」が実行され、「処理②」のアクセス履歴から「パスワード」がキャッシュに移動されてしまう。
(7)この時、一定時間間隔で処理を実行する「処理①」が、キャッシュに移動した「パスワード」を自分のプログラム内部に取得する。
■脆弱性「スペクター(Spector)」とは
それでは次に、「アウト・オブ・オーダー実行」が原因で発生する「Meltdown」の次に、「スペクター(Spector)」の原因を説明します。
「Spector」もCPU高速化の弊害として発生する脆弱性ですが、この脆弱性に関しても、前述のグラーツ工科大学の別の研究チームと「Project Zero」が発見した脆弱性です。
こちらは、CPUが処理高速化のために行う「投機的実行(Speculative Execution)」が原因とされています。
それでは、まず「投機的実行」とは、どのような処理なのかを説明します。
CPUは、処理高速化のために、何らかの分岐処理がある場合、分岐条件が確定する前に、一方もしくは複数の分岐後の処理を先読みして実行します。
この「先読みする」技術は、CPUが遊んでいる時間を減らし、高速化を実現する技術で、先読みが外れた場合は、先読みした処理は取り消されます。
そして、このように、判定処理の結果により、本来は必要としない処理を事前に実行する事から「投機的実行」と呼ばれています。(※投機：成否が不確実)
この処理も、前章で紹介した「アウト・オブ・オーダー実行(Out of Order execution）」処理と同様、「命令パイプライン」と呼ばれるCPUの設計技法で、命令を並列化する事で、全体の処理時間の大幅削減を目的としています。
ちなみに、脆弱性「スペクター(Spector)」の命名の理由は、映画「007シリーズ」に登場する『悪の秘密組織スペクター』が語源と言われており・・・となると映画ファンは嬉しいのだと思いますが、実際は、CPUの処理となる『投機的実行 (Speculative Execution)』 に由来しています。
それでは、どうして「投機的実行」が「Spector」の引き金になるのかと言うと、既にお分かりの通り、その原因は「Meltdown」と同様です。
処理の「先読み」を行ってしまう事で、本来は、参照出来ない領域を、特別な権限を持たないプログラムが、自由に参照する事が出来てしまう点が問題となります。
--------------------------------------------------------------------------------------------------------
(1)判定処理を含む「プログラムA」が起動し、判定処理が行われると、「投機的実行」が発生し、「処理A-③」が先読みで実行される。
(2)「投機的実行」で起動された「処理 A-③」が、保護領域にある「パスワード」を参照して獲得し、キャッシュ領域に移動する。
(3)その時、別の「プログラムB」が起動し、「処理B-①」が実行される。
(4)「処理B-①」は、「処理 A-③」が、「投機的実行」によりキャッシュ領域に設定した「パスワード」を取得して、自身のプログラムの内部領域に獲得する。
(5)これにより、「プログラムB」は、不正に取得した「パスワード」を自由に使う事が可能となる。
■その後の対応
今回、コンピューターの頭脳とも言われる「CPU」に、致命的な設計ミスが存在することが明らかになってしまった訳です。
この事実が公表された事で、2018年の年明け、IT業界は、「上を下への大騒ぎ」となってしまったようです。
これまでは、Windows、iOS、あるいはLinux等のOS部分にバグがあるのは、IT業界では、当然と考えられて来ました。
しかし、コンピューターの頭脳や心臓に例えられる「CPU」のバグとなると、これまでとは全く異なるアプローチが必要になります。
つまり根本的な問題の解決のためには、「Windows Update」等での対応ではなく、CPUを含むハードウェア自体の更新が必要になると言うことです。
これまでは、OSのバグに対しては、「パッチ(Patch)」と呼ばれる「修正(更新)プログラム」を配布して、プログラムにあるバグを修正して来ましたので、あくまでもソフトウェアであるプログラムの修正だけで対応する事が可能でした。
プログラムにバグが見つかった場合、メーカー側でプログラムのバグを修正し、そのプログラムを含む、全システムを入れ直す必要があります。
しかし、システムの「全取っ替え」作業を行うと、数時間もの作業時間が必要になってしまいます。
このため、プログラムを修正する場合、必要最小限の作業でプログラムを修正するため、プログラムの差分だけを入れ替える「パッチ方式」が採用されるようになりました。
--------------------------------------------------------------------------------------------------------
私が作っていたメインフレーム用のプログラムの場合、「IMASPZAP」と言う修正プログラムが、ユーティリティー機能として、IBM等のメーカーから提供されていました。
この「IMASPZAP」と言うプログラムは、機械語ベースで、プログラムを、直接書き換える事が出来ました。
例えば、前回ブログ「CPUとは」の章で取り上げた「MVS」と言うアセンブラ言語ですが、これを機械語に翻訳すると、次のようになります。
【 例：MVC(移動処理)にバグがあった場合 】
(1)処理内容
レジスター1が指すアドレスから、5バイトの文字を、レジスター2が指すアドレスに移動せよ。
→ MVC 0(5,R2),0(R1)
(2)バグ内容
文字の移動先が、レジスター2指すアドレスではなく、レジスター3が指すアドレスだった。
→ MVC 0(5,R3),0(R1)
(3)機械語
①元々のソース ：MVC 0(5,R2),0(R1) ： D204,2000,1000
②修正したソース ：MVC 0(5,R3),0(R1) ： D204,3000,1000
(4)IAMSPZAPに与える情報
NAME プログラムA CSECT名
VER D204,2000,1000
REP D204,3000,1000
と言うような情報を与えることで、ソース・プログラム(実際には、コンパイルした後のロード・モジュール)を、直接修正する事が可能でした。
--------------------------------------------------------------------------------------------------------
しかし、これが「ハードウェア」となると、これまでのような「パッチ」では根本的な解決は不可能です。
「ハードウェア」、つまり機械部品が壊れている訳ですから、その部品を交換しない事には根本的な問題を解決する事は不可能です。
今回の件を「車」の故障に例えると、エンジンに欠陥が見つかった様なものです。エンジンが壊れたのに、エンジンを制御するソフトウェアを修正しても話になりません。
根本的な解決を図るのであれば、エンジン本体を交換する必要があります。
と言う事で、CPU提供メーカー、あるいはOSメーカーの対応ですが、下記の状況になっているようです。
一部、主要メーカーの状況だけを紹介します。
- CPUメーカー
|
メーカー |
影響 |
状況 |
対応 |
|
有 |
未 |
コード更新を行ったマザーボードを提供したがバグ発生。供給停止中。2019年発売予定のWhiskey LakeとAmber Lakeで対応予定。 |
|
|
有 |
未 |
||
|
ARM |
有 |
未 |
2019年にハードウェア・アップデートを予定。 |
|
Power(IBM) |
有 |
済 |
ファームウェアとOSにパッチが必要。既にリリース済。 |
- OSメーカー
|
メーカー |
影響 |
状況 |
対応 |
|
有 |
未 |
2018年1月3日に更新プログラムを配布したが他社セキュリティソフトとの互換性が無く配布中止。 |
|
|
有 |
済 |
2018年1月8日配布の「macOS High Sierra 10.13.2 Supplemental Updat」にてSpector対応済。、Meltdown対策は10.13.2以降で適用済。 |
|
|
有 |
済 |
11.2以降でMeltdown対策済。11.2.2でSpector対応済。 |
|
|
有 |
済 |
2018年初頭にカーネル4.15でリリース済 |
|
|
有 |
済 |
セキュリティパッチを配信済だが互換性はメーカー依存。 |
|
|
有 |
未 |
ルーター等に影響がある事は認めているが影響を受ける範囲が限定されているので対応せず。 |
|
|
有 |
済 |
CentOS6/CentOS7でカーネルアップデートがリリース済。 |
|
|
有 |
済 |
カーネルアップデートが実施済。 |
--------------------------------------------------------------------------------------------------------
その他、大規模クラウドを提供している下記のメーカー環境が、非常にマズい状況になっているようです。
・Microsoft Azure
・Google Cloud Platform
これらクラウドと呼ばれるサービスは、物理的に存在する1個の筐体(きょうたい)で、複数ユーザーのシステムを稼働させています。
そして、重要なデータが保存されている特権メモリーのロケーションへの不正なアクセスを防ぐ措置は、CPUによるセーフガードに委ねているだけとなっています。
しかし、今回、「CPU」に設計上のミスがある事が明らかになっているので、事実上、このセーフガードが無効になっているに等しい状況です。
故に、悪意を持ったユーザーが、今回明らかになった脆弱性を突いて、他のユーザーのシステムを参照し、保護領域に隠してあるパスワードやクレジット情報等の重要情報を盗み出す事も可能となってしまいます。
--------------------------------------------------------------------------------------------------------
現在、これら「クラウド・コンピューティング」と呼ばれるサービスは、上記3社の寡占状態にあります。（Amazon、Microsoft、Google)
加えて、これらクラウド環境で使われているCPUも、下記3社が提供する何れかのCPUとなっており、全てのCPUにおいて、脆弱性が存在する事が明らかになっています。
・ARM
クラウド・サービス、およびCPUが、どちらも数社の寡占状態にある状況で、今回の問題が発生しています。
現在のところ、この脆弱性を悪用したマルウェア攻撃は確認されていませんが、もしも、この脆弱性を悪用したマルウェアが登場したら、IT業界というか、この世界は、どうなるでしょうか ?
実際、ドイツのセキュリティソフト評価機関「AV-TEST」は、2018年2月1日に、脆弱性「Spector」、および「Meltdown」を利用したマルウェアのサンプルが発見されたと報告しています。
「AV-Test」によれば、1月7日から22日の期間において、この脆弱性を利用しているとみられるマルウェアのサンプルが、計119個発見されたツイートしています。
--------------------------------------------------------------------------------------------------------
「マルウェアのサンプル」とは、マルウェアの解析を行うための「検体」を意味します。
通常、マルウェアには、メール添付ファイル開封とか、Webサイトを閲覧する事で感染しますが、この時のメール添付ファイルが「検体」となります。
つまり、「検体」とは、」「マルウェアを含んでいる可能性があるプログラム」と言う事になります。
今回、AV-TESTが119個も検体を発見したされていますが、さらに、この検体に関して、アメリカのセキュリティ企業「Fortinet」が、その内容を解析した所、約83%、つまり約99個が、実証実験用のコードとして有効である事を確認したそうです。
セキュリティ分野では、脆弱性を発表する際、その脆弱性が、単なる理論的な脆弱性ではなく、実際に攻撃に転用可能であることを証明するため、論文と同時に「実証(PoC：Proof of Concept)コード」も発表さします。
つまり、今回発見された検体の内、99個は、脆弱性の攻撃に転用可能なプログラムであると言う事です。
考えただけでも寒気がしてきます。CPUメーカーは、もう少し本気で対応を考えて欲しいものです。
--------------------------------------------------------------------------------------------------------
今回の問題に対しては、前述の表に記載した通り、各CPUメーカーは、MeltdownやSpector対応を施す予定になっていますが、このパッチを適用すると、やはり当初の想定通り、30%程度パフォーマンスが低下するとされています。
CPUメーカーは、(Amazon関係者によると)20年以上も、この問題を放置したままパフォーマンスの向上だけを追求して来たと糾弾されていますので、今後の姿勢が問われる事態となっています。
とにかく悠長な事を言ってる暇はありませんので、早く対応を取るべきです。
また、現在は、この脆弱性の亜種、つまり別の設計ミスが数多く発見されているそうです。
やはり、CPUメーカーは、これら亜種も含めて、早急な対応が必要です。
■最後に
今回は、前回に引き続き、「IT業界を震撼させたメルトダウンとスペクター ～ OSは信頼出来るのか ?」の第2弾として、次の内容を紹介しましたが如何でしたか ?
CPUの高速化処理の脆弱性は、前回のブログで、20年以上も前から明らかになっていた事が明らかになっていたと言う情報を紹介しましたが、まさに、その通りで、その昔は、このような高速処理は行われていなかったのです。
Intel社、およびGoogle社では、今回の脆弱性は、1995年以降にリリースされた全CPUに共通の脆弱性だと発表しています。
1995年と言えば、今や伝説と化した「Windows 95(コードネーム「Chicago」)が発売され、全世界にPCブームが巻き起こった年でもあります。
20年以上前というか、24年も前から潜在的バグが潜んでいたなんて・・・全く信じられない事態です。
しかし、このバグを発見した研究者も凄いと思います。
--------------------------------------------------------------------------------------------------------
これまで常識と考えられて来たロジックを、最初から見直してバグを発見するとは・・・何てヒマな、じゃなく、根気強いのかと思ってしまいます。
今回の脆弱性の発見は、詳しくは報告されてはいないようですが、「Linux」と言うOSをベースに、「カーネル空間に存在するアドレス空間のランダム化(KASLR)」と言う処理を狙った攻撃への対応方法を検討、および実装した際に発見されたと言う事になっているようです。
この対応のため、「Kernel Address Isolation to have Side-channels Efficiently Removed（サイドチャネルを効率的に取り除くためのカーネルアドレスの分離、KAISER）」と言う新方式を採用し、実装を開始したそうです。
そして、この新方式の実装時に、今回の脆弱性「Meltdown」が発見され、それとほぼ同時に「Spector」も見つかったと言う事らしいです。
何か、余りに複雑過ぎて、私にも理解するのが難しい話です。
--------------------------------------------------------------------------------------------------------
そして、この「Meltdown」と「Spector」への対応に関しては、「その後の対応」の章に記載した通りなのですが・・・未だに対応出来ていません。
やはり、根本的な処理の設計ミスなので、中々対応が難しそうです。
既に紹介した通り、Intel社は、2018年10月に、2019年発売予定の新型CPUで、「Meltdown」と「Spector」に対応すると発表していますが・・・
この対応は、本ブログに記載した基本的な脆弱性に対してのみの対応であり、その後に発見された「変種」には対応していないようです。
また、AMD社も、同じく2019年に発売予定の新世代「Zen 2アーキテクチャプロセッサー」では、「Spector」の変種にも対応するとしています。
そして、残りの1社、ARM社も、ハードウェア・アップデートを約束し、今後、同社がリリースする全てのCPUには「Spector」系の攻撃に対する耐性を持たせるようにすると発表しています。
「これで一安心」と言いたい所ですが・・・
旧型のCPUを使っているPCやスマートフォンには、(何時提供されるのか解らない)パッチを適用する必要がありますし、このパッチを適用すると、恐らく、と言うか、ほぼ100%パフォーマンスは低下すると思います。
--------------------------------------------------------------------------------------------------------
CPUメーカーは、これまで24年もの間、パフォーマンスの向上だけを求めて、脆弱性への対応を疎かにして来ました。
そして、恐らく、まだ発見されていない脆弱性が、CPUの中に潜んでいると思いますし、これら潜在的な脆弱性を取り除くのは、さらに難しい作業が必要になると思います。
隠れているバグ、潜在的なバグを見つけ出すほど、難しい作業はありません。私も、それは身を持って経験しています。
これまでCPUメーカーは、上辺だけの性能アップを図って来た訳ですから、今後は、全てのバグを治すのは不可能だと思いますが、CPUは、コンピューターの頭脳であり、心臓でもありますので、注意深く設計してくれる事を期待したいと思います。
それでは次回も宜しくお願いします。
以上
【 画像・情報提供先 】
・Wikipedia(http://ja.wikipedia.org/)
・「メインフレーム・コンピューター」で遊ぼう(http://www.arteceed.net/)
・富士通「コラム・セキュリティ記事」(https://www.fujitsu.com/jp/solutions/business-technology/security/secure/column/)
・トレンドマイクロ「脆弱性」(https://blog.trendmicro.co.jp/archives/16735)
