2018年5月9日水曜日

Spectre-NG?

Spectreに類似のCPU脆弱性が8個ほど発見されたと報じられています。マイクロコードの修正とOSなどのソフトウエア修正の両方が必要なため、詳細の開示はこれらの準備が整うまで延期されるようですが、リモートコード実行可能な脆弱性が含まれるというのが気になりますね。

https://www.heise.de/ct/artikel/Exclusive-Spectre-NG-Multiple-new-Intel-CPU-flaws-revealed-several-serious-4040648.html

https://www.trendmicro.com/vinfo/us/security/news/vulnerabilities-and-exploits/spectre-next-generation-new-intel-cpu-vulnerabilities-found

2018年1月19日金曜日

MeltdownとSpectre

そういえば、いまさらですが、MeltdownとSpectreの話。個人的に調べてFacebookなどに書いていた内容を、ここにも書いておきます。まずは、Meltdownの話。


最近のCPUは、命令の実行を高速化するために、複数の命令を並列実行する機能を持っている。たとえば、ある命令がメモリからのデータ読み込みを必要とするため、待ち時間が生じるような場合、次の命令が前の命令の結果に依存しなければ、それを待ち時間の間に実行するというような処理である。これをアウトオブオーダー実行(順序によらない実行)と言う。最近のプロセッサ命令は、実行過程でよりプリミティブなマイクロコードに分解されるため、こうした前処理は常に先行して行われ、依存関係に直接関わる実行ステージのみが未実行の状態で引き続く命令が待機することになる。これにより、命令列の中の複数の命令が並行して実行されながら、結果を保留した状態で待機していて、先行する命令の完了と同時に結果が反映される。また、こうした命令列の中に分岐(条件分岐)命令が存在した場合は、過去の分岐状況に基づいて予測された分岐結果に基づいて、次にどの命令を先行するか決定して実行する。予測が外れた場合、並行して実行された結果は捨てられ、正しいパスで再度実行される(かえって効率が低下する)ため、こうした方式は投機的実行と呼ばれている。
今回、問題になったのは、並行して実行される命令にOSカーネルのみがアクセス可能なメモリ領域にアクセスするような命令が含まれていた場合、たとえ、プロセス自体に権限がなくても(ユーザプロセスであっても)それが実行されてしまうという点。もちろん、その実行結果が確定された段階では、メモリアクセス例外が発生して処理が中断されるため、直接プログラム側からその値を確認することはできないのだが、実際は、この実行によって、アクセスしたメモリのページがキャッシュに読み込まれるといった副作用が生じる。また、例外発生までに一定のタイムラグが生じるため、先行する命令の結果を受けた後続命令もある程度実行されてしまうため、こうした副作用を、読み込んだデータに依存する形で発生させることができる。この問題は、ソフトウエアへの依存性はなく、こうしたプロセッサのアーキテクチャに存在するため、様々なOSプラットフォームや同種のアーキテクチャを持つCPUで発生する。

あるページがキャッシュされているかどうかは、そのページに対するアクセス速度を調べることで判定ができるが、これを使用してサイドチャネルを作る手法は既にいくつか既知になっている。(たとえば、Flush + Reloadなど)キャッシュを削除しておいて、他のプロセスがどのページを再度キャッシュしたかを調べることができれば、これを悪用してプロセス間でデータ受け渡しが可能になる。(もちろん、そう単純ではないが・・・)
たとえば、先に実行される命令が、カーネルページのアドレスにアクセスして1バイトのデータを取得した後、その値×ページサイズをインデックスにして、後続の命令が実際に実メモリがマッピングされている仮想アドレスにアクセスしたとする。当然、カーネルページへのアクセスでは例外が発生することになるが、この例外発生の前に、カーネルページへのアクセスによるデータが確定して、準備が整ってそれを待っていた後続の命令が実行されてしまう。つまり、ある先頭アドレス+読み出したデータ×ページサイズの位置のページがキャッシュされることになる。もちろん、そのプロセス自身は例外によって読み出したデータを知ることができないが、他のプロセスから、どのページが新たにキャッシュされたかを知ることができれば、読み出したデータの値がわかる。これが、Meltdown攻撃の基本的な原理。サイドチャネル攻撃との組み合わせで効率が悪いように思えるが、それでも平均して500KB/s程度のデータ読み出しが低いエラーレートで可能とのことである。
CPUアーキテクチャの問題であるため、この攻撃を原理的に防ぐ方法は、ハードウエアの改修以外にない。
一方、Linux等のOSでは、ユーザプロセスの仮想メモリ空間に、すべてのカーネルメモリと実メモリがマッピングされている。このことによって、上の攻撃で、最悪の場合、全実メモリの情報やカーネルメモリ内の情報を読み出すことができる。もちろん、それを悪用するためにはカーネルメモリの構造や他のアプリケーションのメモリ構造を知っている必要がある。また、カーネルにおいても、最近ではASLR(KASLR)つまり、アドレス配置のランダム化が行われており、攻撃の難易度は高くなっているが、これも実際のマッピングを推測する手法はいくつか存在する。
Windowsにおいては、Linuxのように全実メモリをプロセス仮想空間にマップするようなことは行っていないが、依然として重要な情報を持つカーネルページがマップされているため、Meltdown攻撃が機能する可能性が高い。
Linuxにおいては、最新の改修で KAISER(KPTI)と呼ばれるパッチが導入された。これにより、当面、全実空間やカーネルページの大部分にアクセスできなくなるが、依然として一部のカーネルページにはアクセス可能である。ただ、KASLRを介してマッピングがランダム化されていることもあって、攻撃難度はかなり上がることになる。当面は、これ(KAISER)が最良の対策となる。ただ、こうしたページに含まれるカーネル空間のポインター値からKASLRのマッピングを推測できる可能性はあり、最終的にはこうしたポインターのすべてをユーザ側からアクセスできなくする必要があるとのこと。
WindowsやMacOS X, iOSにおいても同様のパッチが既に提供されている。思うに、この攻撃自体の難易度は高いものの、影響範囲が様々なOSプラットフォームやハードウエアを越えて非常に広いことから、有効な攻撃コードが出回る可能性も否定できない。仮想環境やコンテナ環境などにおいても、隔離環境からホストOSや他のインスタンスの情報にアクセスできるなど広く影響を与えることから、とりわけクラウドサービス環境における対応は急務と言えるだろう。

次に、Spectreの話。

Spectre攻撃は、Meltdown同様にキャッシュへの副作用を利用してサイドチャネルから情報を得る方法だが、カーネルメモリや仮想空間にマップされた実メモリページではなく、特定のプロセスの仮想空間内のデータを狙う手法である。従って、Meltdown対策としてのKAISERは有効ではない。攻撃対象となるのは、CPUが持っている分岐予測実行(投機的実行)機能。

分岐予測と分岐先予測

Meltdownの時に書いたように、最近のCPUは、ある命令の待ち時間の間に後続命令の実行準備や先行命令に依存しない命令を実行して結果を保留する、アウトオブオーダー実行の機能を持っているが、これを含めて命令コードを先読みするパイプライン機能は分岐命令によって乱されるため、分岐の多い処理ではパフォーマンスが低下する。これをカバーするために付加されたのが分岐予測の技術である。最近のCPUでは、よく使用される条件分岐命令の仮想アドレスと、その最近の分岐の履歴をテーブルとして保持していて、この情報に基づいて次に先読みすべきコードを決定している。また、間接ジャンプやリターン命令といったダイナミックに飛び先が変わる命令については、よく使用される分岐先アドレスを保持していて、これを用いて分岐先を予測し先読みを行う。分岐予測の結果を高速に利用するため、各命令の仮想アドレスは下位30ビット程度をハッシュテーブル化して保持され(BTB:Branch Target Bufferと呼ばれる)、実行時は分岐命令がデコードされているかどうかにかかわらず、先読みのために使用される。このアドレスは仮想アドレスであるため、たとえば、異なるプロセスであっても、同じ場所に分岐命令があれば(ASLRなどのため、共有ライブラリであってもこの可能性は極めて低いが)同一のものとして扱われる。

分岐予測については、外部からその分岐をコントロールできれば、あらかじめ分岐有無を学習させることが可能である。また、分岐先予測については、対象となる命令の仮想アドレス下位30ビットが等しくなる位置に同じ命令がある攻撃用プロセスを準備できれば、他のプロセスから分岐先予測を攪乱することも可能である。(論文では20ビット程度でもよかったと書かれている)

基本的な攻撃の原理

分岐を伴うコードで、予測結果によって先読みされる部分に、外部から与えたデータで任意の仮想アドレスを参照するような命令を持つ部分を探し、この分岐命令についてそのコードを先読み実行するように学習させた上で、参照したいメモリアドレスを与えて、予測を失敗させる。これにより、もし参照したメモリブロックがキャッシュされていなければキャッシュ要求が発生し、キャッシュされる。あらかじめキャッシュを削除してからサイドチャネルでキャッシュされた場所を調べる手法は、Meltdownと同様。

分岐先予測を使った攻撃ではもう少し自由度が上がる。メモリ参照を行うコードは分岐命令とは全く違う場所にあってもよい。この場合は、攻撃プロセスを使って、分岐先予測を攪乱し、メモリ参照を行うコードのアドレスをBTBに押し込んでしまえばいい。これは、バッファオーバフロー攻撃時のROP(Return Oriented Programing)と類似の手法である。もちろん、実行結果は最終的に破棄されることになるが、キャッシュは残る。

以下、具体的な攻撃コンセプトの例。

A) 条件分岐を攻撃する方法(分岐予測への攻撃)例

1) 標的とするプロセスのプログラム内で、外部から与えられる値によって分岐条件が変わり、投機的実行によって、その値に依存する位置のメモリブロックをキャッシュする副作用を発生するようなコードを見つける・・たとえば、指標値による二重のテーブルルックアップ

if (x < size_a1)
  y = a2[a1[x] * 256];

のようなコード。これは機械命令に落ちる際に if 条件を満たさなければ分岐するようなコードになるが、この分岐予測が「分岐しない」となる場合は、xによってa1 + xのメモリにある値が参照され、それに対して256(キャッシュブロックのサイズの倍数の値)を掛けた値だけa2に加えた位置へのアクセス要求が発生し、そのブロックがキャッシュされる。

2) この分岐に対して、いくつか正常な(size_a1より小さな)値を与えて学習させた後に、xに不正な(size_a1より大きな)値を与えると、分岐予測によって、不正なxを用いた計算が先行して(投機的に)行われる。たとえば、事前にキャッシュをあふれさせたりフラッシュしてしまうことで、条件評価の際にsize_a1をメモリから取得しなければいけないなどの時間がかかるようにしておく必要がある。これにより、a2 + (a1 + x) * 256 の位置のブロックがキャッシュされる。

3) サイドチャネルを使って、新たにキャッシュされたブロックのアドレスを調べると、a1 + xにある値が推定できるので、この作業をxを変えながら行うことで、標的プロセスの仮想メモリ空間内にある値を読み出すことが可能になる。

B) 間接分岐やリターン命令を攻撃する方法(分岐先予測への攻撃)例

1) 標的プロセス内で、2つのレジスタ(R1, R2)に外部から操作可能な値を持った状態で実行される間接分岐(メモリ間接のジャンプ)命令やリターン命令などを見つける。

2) 同じく標的プロセスのコードや使われている共有ライブラリ(DLL, SOなど)内で、まず、R1をオフセットとしてメモリをDWORD参照し、その値をR2に加える(32bit演算)ようなコードと、その次にR2を使ってメモリを間接参照するなんらかの命令を持つ部分を見つける。たとえば、以下のような例(実際のWindowsのコードの一部)が書かれている。ここで、EDIとEBXが外部から制御可能。edxの値は既知である前提。

adc edi,dword ptr [ebx+edx+13BE13BDh]
adc dl,byte ptr [edi]

3) 1)の間接分岐もしくはリターン命令について分岐先予測ロジックを攻撃し、2) のコードを分岐先と予測するように学習させる。

4) R1を参照したいアドレス(CPUによってバイトオーダーを考える必要あり)にし、R2をメモリ参照によってアクセスされるアドレスの先頭に設定するような値を標的プロセスに外部から与えて 1)のコードを実行させる。これにより、間接分岐やリターン命令がメモリアクセスを待っている間に分岐先予測によって2)が投機的に実行され R2 + [R1]<<24 + [R1+1]<<16 + [R1+2] << 8 + [R1+3} の位置のメモリ(バイトオーダーに注意)がキャッシュされる。

5) サイドチャネルを使用して新たにキャッシュされたブロックのアドレスを調べることで、4)のアドレスがわかる。A)ほど単純ではないが、こうした手法をR1の値を変えながら繰り返せば(メモリアクセスバウンダリーの問題は考慮が必要だが)標的プロセスの任意のメモリの値を取得する事は原理的には可能である。

C) JavaScriptを使用したブラウザ攻撃の可能性

JavaScript実装の多くが、JIT(実行時コンパイル)を行っているため、分岐命令やそれに伴った予測実行コードを意図的に生成することができると考えられる。サイドチャネルを作るためのキャッシュの破棄やキャッシュされたかどうかの判断は、巨大な配列を使用することで間接的に可能になる可能性がある。これによって、ブラウザに実装されているサンドボックス機能等のプロテクションが回避される可能性がある。

とりあえず、参考までに・・・・

活動サマリーなど

皆様、あけましておめでとうございます。

長い間、ブログの更新をサボってしまったので、その間あったトピックスをいくつか紹介しておきます。

7月 Interpol World コンファレンス(シンガポール)参加
   CSAジャパン(日本クラウドセキュリティアライアンス)IoTセキュリティセミナ
   DEFCON 23 (ラスベガス)参加
9月 (ISC)2 World Congress (オースティン)参加
   JAPAN IDENTITY & CLOUD SUMMITにて講演

CSAジャパン IoT WGでは、8月にIoTへのサイバー攻撃仮想ストーリー集(第一版)を発行しましたが、この編集にもリーダーとして係わっています。終盤は、個別の業務多忙のため、あまり公的な活動に参加できていませんが、今年はまた積極的に参加していきたいと考えています。

2017年5月29日月曜日

「つながる世界」を破綻させないためのセキュアなIoT製品開発 13のステップ 公開(CSAジャパン)

一般社団法人日本クラウドセキュリティアライアンス(CSAジャパン)から、CSA IoT ワーキンググループの "Future-proofing The Connected World: 13 Steps to Develop Secure IoT Products" の日本語翻訳版が公開されました。

「つながる世界」を破綻させないためのセキュアなIoT製品開発 13のステップ

この翻訳版は、私も参加している CSAジャパン  IoT WG のメンバー中心に半年以上をかけて翻訳・レビューしたものです。

IoT関連記事を寄稿しました

株式会社イプロス様のサイト Tech Note にIoTセキュリティの基礎知識を連載開始しました。

https://www.ipros.jp/technote/basic-iot-security1/

8回にわたって、IoT製品・サービス提供時に留意が必要な事項などを解説する予定です。

2017年3月1日水曜日

明るい未来か混沌か・・・

しばらくブログもサボってしまいました。ホームページに至っては、1年放置という状況。とりあえず、本業が忙しかった・・・・ということにしておいてください。

今年参加した二つの大きなイベントで、なんとなく対照的な未来像を見ました。ひとつは1月に毎年ラスベガスで行われる世界最大規模の家電ショーであるCES、もう一つは2月にサンフランシスコで開かれた、これも毎年恒例のRSAコンファレンスです。


前者は、コンシューマ向けの電子製品や最新テクノロジーが満載、自動運転車からテレビ、スマート家電、3Dプリンター、そしてゲーム機まで、様々な製品やコンセプト展示が、ところ狭しと並びます。
2年前にも一度行ったのですが、そのときは、ほとんどがコンセプト展示だった自動運転車は、既に各社とも、実際に走る実験車を展示しており、コンセプトカーの多くは、さらにAI搭載と、明らかに大きく進んでいます。
家電系は、大画面の有機EL(LED)4K/8Kスマートテレビを筆頭に、いわゆる「繋がる家電」が目白押し。3Dプリンターはさらに高機能化と低価格化し、様々な素材を使って造形ができるようになっています。ゲーム機はVR(仮想現実)ゲームが主流。体験コーナーでは、VR+体感型の絶叫系ゲームに長蛇の列ができるなど、こちらも人気を集めたいました。
VR、AR(拡張現実)は様々な用途で実用化されつつあります。特に、ARは、日常の仕事や生活のアシストに不可欠のものになっていくと思われ、透過型グラスのディスプレイ、自動車用のHUD(ヘッドアップディスプレイ)などが、多く展示されていました。

ロボットは、こちらも進化していて、クラウドのAIと連携した様々な接客や介護、見守り用のロボットが展示されていました。
ちょっと気になることといえば、自動車以外の分野で日本企業の存在感が希薄に感じられたことです。各社とも、そこそこの規模で展示はしているものの、内容はかなり絞り込んだ印象を受けました。一方で、存在感を年々増しているのが韓国や中国の企業です。大手企業のブースは総合的な展示で、かつての日本メーカーを彷彿とさせます。まさに、Before/Afterな感じです。また、各国とも、国が支援した形で、自国の企業を集めた展示コーナーを作っていて、様々な新興企業が展示をしていました。日本からはJETROが、同じようなブースを構えていましたが、ちょっと存在感に欠ける印象でした。
さておき、CESでは、未来はこんなに素晴らしい・・・といった印象が大きく、かつて少年時代に夢見た未来像がどんどん実際のものになっていくという「わくわく感」があります。それが、CESを見に行きたいという最も大きな理由なのです。もちろん、こうした技術の爆発的進歩や拡大に対して危惧がないわけではありませんが、それらをどうにか解決して「手に入れたい未来」がそこにあるのです。


 一方、今回参加した(この原稿はサンフランシスコで書いているのですが)RSAコンファレンスは、冒頭から「混沌」に包まれていました。
初日に行われた、一連のキーノートで受けた印象は、まさに「混沌」です。端的にまとめれば、「技術の爆発的な進化が混沌を生み、様々な想定外を含むセキュリティ問題が発生するだろう」という予言です。
そして、一連のキーノートから得た「結論」は、「これから来る困難な時代に、我々は協力して臨まなければならない」というものでした。つまり、「何が起きるか予想もできないから、とにかくみんなでかんばろう」という、ちょっと精神論めいたイメージです。
そこまで暗いイメージを作り上げるのは、やりすぎだろう・・・と感じたのですが、FUDじゃないか、という前に、我々の業界の現状をもう一度考えてみる必要があるのかもしれません。実際、CESで見た技術の爆発は非常に印象的です。各分野の技術を引っ張っているのは、いずれも世界トップレベルの研究者や技術者です。さらに、これからAIがそうした進歩を後押しする時代になれば、進歩はさらに加速するでしょう。いわゆる「シンギュラリティー」(技術的特異点)は、2045年よりも、ずっと早く訪れるかもしれません。そんな技術の進歩の最先端に対し、セキュリティの「専門家」は何ができるのでしょうか。
自ら手を下すにはハイレベル過ぎる領域です。基本は述べられても、実際の実装や現場での対応は多くの「セキュリティ専門家」には非常に困難な仕事になるでしょう。まして、我々が相手にするのは、そうした最先端技術を「使う」側の人たちです。我々同様、彼らもそうした技術の中身や本質を理解することは困難です。そういう意味では、「セキュリティ屋」さんたちが暗くなってしまうのは当然なのかもしれません。一方、攻撃者は、少数精鋭で、その分野を極めてくるはずです。そうなれば、核ミサイルを木の盾で防ごうとするようなもので、まったくもって歯が立たないでしょう。もちろん、迎撃ミサイルを作ることは可能です。しかし、そのためには、攻撃側と同じレベルの(狭い分野での)高度な技術知識が必要です。しかし、人材の面から言えば、そうした「専門家」の大量育成は不可能です。(CTFなどで育成できるレベルの人材ではありません)一方で、守るべき前線は広大で、どれだけ人がいても足りません。つまり、こうした非対称性の拡大が、これから起きようとしている(と彼らが言っている)「混沌」の本質なのかもしれません。つまり、今回のRSAコンファレンスで感じた「混沌」は、すなわち「セキュリティ業界」の行き詰まり感なのだろうと思うのです。


さて、こうした両極端を目にしたわけですが、どちらが・・・という議論は、おそらく不毛でしょう。なぜならば、どちらも現実だからです。そして、我々が欲しいのは「明るい未来」です。ならば、どうすれば「混沌」を解消して、明るい未来を手に入れられるのでしょうか。少なくとも我々は、「不都合な現実」をたくさん知っています。でも、いまやそれらの多くは我々には(少なくとも技術的には)どうしようもありません。そろそろ、我々は「セキュリティ業界」という枠を崩して、ITという大海原に散らばっていく必要があるのかもしれません。そうして、様々な分野の技術者や専門家と協力して、それぞれの分野におけるセキュリティの底上げを「内部から」していく必要があるのだろうと思うのです。今回、RSAコンファレンスに参加して、こうした思いを強くした次第です。

2016年10月4日火曜日

執筆書籍「IT管理者のための情報セキュリティガイド」が出版されました

エクスジェンネットワークス株式会社様とのコラボで出版した、執筆書籍「IT管理者のための情報セキュリティガイド」がインプレスR&Dの Next Publishing から出版されました。Kindole, Kobo,i-Booksなど電子書籍版の他、Amazon オンデマンド印刷サービスを使用して、印刷本としての購入も可能です。

以下、まえがきを転載しておきますので、興味があれば是非、ご覧ください。

はじめに

 商用化から20 年以上が経過し、いまやインターネットは生活やビジネスに不可欠な基盤となっています。その一方で、インターネットを舞台とした犯罪や事件、事故は毎日のように発生し、私たちのビジネスや生活を脅かしています。そのような中、セキュリティの知識や経験を有する「専門家」の不足が叫ばれ、育成のための施策も徐々に拡大しつつあります。

 しかしながら、セキュリティ専門家の育成、とりわけ現場を理解し、適切な対策をアドバイスできる経験をもった人材の育成は簡単ではありません。また、こうした人材にはセキュリティの知識だけでなく、コンピュータやネットワークに関する基本的な知識や経験が不可欠です。このような専門家の不足を補う最善の方法は、現場を知り抜いたIT エンジニアや管理者の皆さんに、自らの仕事の一部としてセキュリティに関する役割を担っていただくことではないかと、私は思っています。

 そもそもIT分野におけるセキュリティは、たとえばネットワークやサーバの管理・運用と密接に結びついています。これらとセキュリティを分けて考える理由はありません。むしろ、実際の管理・運用にセキュリティ要素を組み込むことは、極めて自然なことのように見えます。多くのITエンジニアや管理者が、今の仕事にセキュリティという塩味を少しきかせるだけで、不足しているといわれている「専門家」の大部分はカバーできるだろうと筆者は考えているのです。

 現場のITエンジニアがセキュリティを学ぶ場合、まずは自分の守備範囲のセキュリティから学ぶとよいでしょう。たとえば最近のネットワークエンジニアには、ファイアウォールやUTMなどのセキュリティ機器を扱う機会もあるはずです。設計段階でネットワークセグメントの構成を少し変えるだけで、リスクを大きく減らせる場合も少なくありません。それは、むしろ自分の専門領域のスキルアップとして捉えることができます。また、IT管理者やマネージャはセキュリティ全般について広くエッセンスを知っておく必要がありますが、必ずしも各分野を深める必要はありません。各分野のエンジニアがセキュリティ要素を自分の仕事に取り込めていれば、管理者はそれらを俯瞰して調整する役割に徹することができるからです。

 本書は、IT管理者が意識すべき情報セキュリティ上のポイントを網羅的に解説するものです。特に第1 章では、中規模から小規模組織におけるIT管理者が、最低限留意すべき情報セキュリティ上の項目を中心に据えて解説しています。IT管理者は、さらに、セキュリティの基本であるリスク管理について学ぶことで、これを従来のITリスクの一部として捉えることもできるでしょう。

 一方で、IT エンジニアは自分の役割に応じ、必要な箇所を読むことができます。個々の分野についての技術的な基本事項や実際のオペレーションを押さえているエンジニアであれば、この内容から実装に結びつけることは難しくないでしょう。このため本書では、読者は基本的なサーバ用オペレーティングシステムや、ネットワークに関する知識を有していることを前提としています。また、個々の製品やサービスなどの実装に依存する内容については、一部を除き踏み込んでいませんので、それぞれのマニュアルなどを参照してください。

 本書が、ITの現場におられる皆さんのスキルアップやキャリアアップに繋がることを願ってやみません。

2016 年9 月
二木真明