スピーカー 1
この問題を特別強く受けるサービスとしては、
AWSやGoogle CloudのGCPといったクラウドサービスですね。
こういったクラウドサービスは仮想化環境を駆使して、
いろんな利用者とかいろんな会社さんのパソコンをAWSとかGoogleの管理のもと提供してあげますよというような、
このCPUとかメモリとかのコンピューティングリソース貸し出しサービスみたいなところがあるので、
多くのいろんな利用者を抱えているわけですけれども、
特定の利用者の攻撃によってその包装PC、大元のパソコンを経由して、
他の企業のやっていることを盗み見たりとか、そういうことができてしまえるのではないかという、
そういう懸念につながってしまうので、
そういったクラウドサービスにとってはかなり大きな出来事ということになっています。
スピーカー 1
実際日本では代表的な会社さんとして、
桜インターネットさんが告知したりとかして、
スピーカー 1
この影響調査のために一時的に新規受付を止めたりとか、
そういう事態にも発展しているというものになっています。
どこまでのことができたのかという技術的なところはいろいろあるんですけれども、
先ほど冒頭に言ったIPv4のヘッダーとか言われてもよくわかんないと思うので、
簡潔に一言レベルで何とか言ってみようかなとすると、
コンテナの中から外へ、インターネットのところへネットワーク通信をしたいと、
ホームページを見に行きたいとか、
そういう通信行為を行おうとした時には、
大元のパソコンのネットワークを経由して外に出ていくことになります。
コンテナから一回大元のパソコンの方に、
こういう通信を外にしたいんだけどと言って、
スピーカー 1
その大元のパソコンがさらに外へ送るという段階を踏むんですが、
この大元のパソコンの方で通信のデータを横流しする時に、
スピーカー 1
その通信の中身が合っているかどうか、
ちゃんとしたものかどうかというチェックを、
本来は毎回毎回するに越したことはないんですが、
それだとちょっとパフォーマンスが落ちちゃうからということで、
後回しにして、後からその中身の妥当性をチェックするというような、
非同期な処理になっています。
その結果、後からやると行った時に、
その処理の範囲ですね、
どういう範囲をどういう風にチェックするかという処理の中で、
不正な範囲を指定しても、処理が正常な処理として実行されてしまう、
というのが今回の問題でした。
なので、本来はある通信のこの範囲の通信のデータが正しいかどうか見てという処理が、
もっと大きく他の通信の処理データを見たりとか、
そういうことができてしまえるというものになっていました。
今回は32バイトほどのデータの流出というのが検出されたようです。
スピーカー 1
今回これが直接いろんな人に影響を出るかと言われたら、
先ほどのような大手のクラウドサービス事業者の影響というところには尽きるんですけれども、
今時点でこの問題に対して言及されていないクラウドサービスとかを利用されている方は、
かなり不信感を持ってクラウドベンダーを見た方がいいくらいの、
クラウドベンダーとしては必ずチェックしなければならない、
重要度の高い脆弱性であったということで共有でした。
はい、以上です。
はい。
スピーカー 2
ちょっとわかってない。
さくらは新規加入を止めますと言いました。
Googleとかマイクロソフトはどういう対策を取っているんですかね?
スピーカー 1
ちょっと調べます。
というのもありますし、
スピーカー 2
新規加入を対策するだけでいいのかな、みたいなところがだいぶ怪しいなと思って。
スピーカー 1
そうですね。
スピーカー 2
要は敷地内にあるこの部屋を貸しますよってやってるけど、
その敷地に出入りする時には手影を取らないといけませんみたいな。
その手影をハックして、
その敷地内にある情報にアクセスすることができますみたいな話だと思うんだけど。
そうすると新規加入をストップしただけじゃダメで、
今やってる通信全部が非常に攻撃の対象になりうる気がしていて。
スピーカー 1
そうですね。
スピーカー 2
それはどうするのって感じがするんですよね。
そうですね。
スピーカー 1
既存顧客もこれを利用して攻撃できてしまうっていうのはその通りですね。
今いるユーザーを止めるだけではダメで、
すべて使ってるサーバーを停止するくらいのことをやらないとこの問題を防げないんですね、根源的には。
今知られましたけど、AzureとかGCPはこの問題についてまだ公式見解出てないんですね。
大丈夫なのかな、会社として。
スピーカー 2
どうなんですか、はい。
スピーカー 1
AWSが速報を出せたのはおそらく内々に共有されてたっていうのもあるでしょうけれども、
そもそもAWSってOSとかかなり低レイヤーのところから自作してるんですよね。
CPUチップとかも自作してるし。
なんでカーネルレベルのこの問題っていうのがあんまり該当しなかったのかなとは思います。
スピーカー 2
汎用機ではないからこの穴が実はなかったと。
スピーカー 1
とか入ってない。もしくはもうだいぶ前から認知してて、
自分たちのOSだったのでパッチをすぐ当てられていたみたいなところかもしれない。
もしかしたらAWS対策しましたって公式に言ってるのもちゃんと読み解いたら、
実はユーザーが個人で開発しているLinuxイメージについては当然対象外ですとか、
いろいろ条件付けて書いてあって、素直にAWSだから関係ないですって言える話かどうかは、
スピーカー 1
もう少しちゃんとAWSの公式のやつを見てくださいって感じですかね。
スピーカー 2
特定のLinuxに対して脆弱性があるという話なので、
何かガチガチにカスタマイズしてて、そもそもこういう機能をスペックアップのために使ってないとかだと、
気にしないで済むとかそういう話か。
スピーカー 1
そうですね。もちろんAWSの提供している仮想サーバーの上でさらに仮想化をユーザーがすべてできるんですよね。
なんか提供されているマシンの上でさらにどっかみたいな、
そういう仮想化サービスを入れてもう一段仮想化してみたいなことができるんですけど、
そこまでいくと当然AWSとしてもサポート外というか、
自分たちでそういうものを運用されているんだったら、
影響範囲かどうかは自分で調べてくださいってなるんで。
なるほど。AWSを借りて何かしらのサービスを提供しておろしているとかだと、
スピーカー 2
その会社自体が管理対象になるからってことね。
スピーカー 1
そうそうそう。
AWSが提供する普通のコンピューターサービス、EC2とか言われている仮想サーバーの上で作業しているだけだったら、
AWSの責任範囲としてちゃんとこの問題がないよっていうのは見てくれるんですけど、
その上でさらに仮想化を一層かましてそこでサービス運用しますって言われたら、
もうAWSからしたら知ったことじゃないになっちゃうっていう。
そういう話ですね。
スピーカー 2
なかなか大変ですね。
大変ですね。
スピーカー 1
これはもうどの事業者とかどの開発者であってもやっぱりコンテナにする理由って、
そのコンテナが独立性が担保されてて他に影響しないよねっていうことを色々見ているからこそ、
スピーカー 1
コンテナで隔離されてるんで大丈夫ですとか色んなところで方言として使ってきた文脈があるので、
その文脈をぶっ壊すこのニュースはなかなかエンジニアの今までの説明が苦しくなるから、
個人的には非常に辛い感じがします。
スピーカー 2
コンテナって確か私の記憶通りだと6、7年くらい前な気がしていて流行りだしたのって。
だから化石みたいなサービスはこれを使ってないから安全という可能性があるわけ?
それで言うと全然コンテナは流行りだしたのはそうなんですけど、
スピーカー 1
この技術自体はかなり昔からあるので全然そんなことないですね。
スピーカー 2
そうなんだ、なるほどね。
スピーカー 1
古い似たようなサービスだとVMウェアとか聞いたことないですか?
あれもそういうコンテナを作るサービスの一つなので。
スピーカー 2
やってることは一緒ってことね。
スピーカー 1
そうそうそう、やってることは一緒。
スピーカー 2
なるほど。
スピーカー 1
歴史的には結構長い。
それをフル活用してシステムを組んでいったりとかするっていうのは結構最近って感じ。
スピーカー 1
だから6年前に流行ったやつとそれまでで何が違うかというと、
それまでのところでいったら仮想化環境になっても、
その仮想化された環境に全てのアプリケーションをぶち込んで、
データベースを全部ぶち込んで1台のPCとして振る舞わせる。
でもその仮想化のベースになっているOSとかコンピュータリソースの設定、
CPU何コアつけるとかメモリ何ギガ割り当てるとか、
そこを共通化できるから特定のアプリケーションとかシステムを構築したときに
CPUとかメモリが足りなくて動かなくなるとか、
そういうことが起きないよねっていうレベルの仮想化っていうのが
6年よりもっと前の世界の話で、
そのコンテナが入り出したところでいくと、
スピーカー 1
1機能1仮想化しちゃえばいいじゃんと。
そのデータベースに書き込むコンテナとか、
データベースを持っているだけのコンテナとか、
そんな感じで1個ずつコンテナにしちゃって、
何かアップデートしたら全体をアップデートするんじゃなくて、
その1個のコンテナだけアップデートしたらいいよねとか、
パッチ適用もそれだけで済むよねみたいな、
そういう分散管理のために出てきたのが最近って感じ。
なるほどね。
なんかでもあれだな、
スピーカー 2
その言い方だけ聞くと確かにコンテナ間での通信が多いから、
そこの利便性を高めるといろいろ大変なことが起こりそうな感じがしますね。
スピーカー 2
使いやすいように分かりやすい風潮を符号化しますとか言ったら漏れたりとか、
スピーカー 1
そういう意味だと、
一時期IntelのCPUでやったメルトダウン攻撃と似たような話かもしれないですね。
あれもHypervisorのパフォーマンス向上のために、
CPUにリクエストしてくる処理を20個くらいバッファーでためられていたら、
スピーカー 1
そこに条件分岐とかあって、
この場合はこう、この場合はこうっていうのがあったとしても、
その先の処理までもCPU側で先に処理しておいて、
本当にそうだったら処理した結果をそのまま採用する、
違ったら破棄するみたいな、そういう処理があって、
その効率性を担保する処理のやっちゃった結果を抜き出せば、
セキュリティとかパスワードとか通ってなくても、
CPUは先に実行してくれてるから、
侵入したことができる、
侵入したことと同じことができるみたいな、
そういうことがメルトダウン攻撃だったと思うんですけど、
今回の件も似たようなもんじゃ、似たような感じですね。
スピーカー 2
似たような不具合がポロポロ出てきそうで嫌ですね。
スピーカー 1
確かにこれはさすがに標準な一角感はありますね。
スピーカー 2
キューキューキューキューキューキューキューキューキューって。
キューが増えてきる。
スピーカー 1
キューをどんどんたわさないといけない。
そう感じがしますね。
スピーカー 1
そんな気はしますね
そうだな