virtualization.info 日本語

このコラムはvirtualization.infoのセキュリティコラムシリーズ（パート1、パート2、およびパート3参照）の最終回となっており、セキュリティの高い環境に対する仮想化の影響について解説する。

ご存じのように、仮想化ベンダーは各社の重要なセールスポイントとしてセキュリティ関連のマーケティングを展開している。扱いやすさの改善、マシンのメモリの完全表示、そしてローレベルで各プロセスを検査する機能は、間違いなくセキュリティ分野のどのハイパーバイザーにとっても重要かつ決定的な機能となっている。 
では、われわれはベンダー各社の主張を信じるべきだろうか？仮想マシンの方が一方のハードウェア版よりも「はるかに安全」だと考えて良いのだろうか？

ことCPUへのローレベルアクセスに関しては、仮想化は全く透過的でない。CPUの機能にはエミュレートできない（あるいはそうすることが賢明でない）ものもいくつかあり、ここまで詳細なレベルまで見た場合、仮想と物理の両システムの同等性はほとんど現実的とは言えない。
もちろん、この技術のそのような側面を浮き彫りにすることに関心を示すベンダーは1社もなく、ユーザもここまでローレベルの分析にはさほど関心がないようだ。

現実問題、このような状況であることは何年も前から有名な話で、セキュリティ研究者らは仮想化インフラに対してローレベルの攻撃を仕掛け、この問題を何度も利用してきた。
ところが、これらの攻撃の大半は控えめに言っても実行が難しいが、実世界に深く関係する問題も多い。

まずは大胆な主張から始めよう。現行の最先端仮想化技術を考えた場合、仮想マシンで完全なハードニングを行うこと（あるいは少なくとも物理マシンと同等のセキュリティを確保した仮想マシンを持つこと）は不可能ではないにしてもかなり難しい。

ハードニングは、「縦深防御」として知られる侵略者が防御の最前線を突破しても攻撃の影響を緩和することを目指した一連の複雑なセキュリティ手続きの重要なコンポーネントの1つだ。一般的に、サーバのハードニングにはサーバ上で動作するOSやサービスのセキュリティを高めるための複数の処理が関係してくる。

このプロセスとしては、ベストプラクティスの適用、パーミッションの強化、OS専用機能の有効化などによるソフトウェアコンフィギュレーションのセキュリティレベル向上も含まれる。今日Linux OSの存在が大きくなったUNIXの世界におけるサーバのハードニングの場合、システムの基本的動作の変更や、場合によってはOSのコアコンポーネントであるカーネルへのパッチの適用が必要になる場合も多い。

これらの手続きの背景にある最大の目標は、たとえ攻撃者が1つ以上のネットワークサービスに障害を引き起こしても、必ず侵入領域を可能な限り最小限にとどめ、ビジネスへの影響も最小限にとどめるようにすることだ。

たとえば、適切なハードニングが行われたサーバでは、攻撃者がウェブアプリケーションに障害を引き起こしても、ハードニングが行われていないサーバのように攻撃者が権限を引き上げてネットワーク上のほかのマシンにまで攻撃を拡大するようなことは防ぐことができる。

特定のハードニングテクニックを適用すれば、マシンに対する管理者権限までも与えてしまうような決定的な脆弱性（その脆弱性が既知ものであってもなくても）を悪用する攻撃も阻止できる。

仮想化はハードニングに強い影響を与える、という言う場合はまさにこれらのテクニックのことを指している。ここで1つの例を考えてみよう。

GRSecurityは知名度の高いLinuxカーネル用パッチセットで、そのセキュリティレベルを大幅に引き上げることができる。  インターネットから見える公開拠点サーバで幅広く利用されており、セキュリティの知識が深いシステム管理者の間で知名度が高い。

UDEREFは高度なハードニング機能で、GRSecurityに実装されている。x86アーキテクチャの内部に関する深い知識が必要なためUDEREFの細かい動きには触れないが、UDEREF機能がLinuxカーネル上における多くのKernelレベルの悪用（マシンに対する管理者権限を与えてしまう最も危険なタイプの攻撃）をうまく無効にできることは事実だ。

UDEREFは、Linuxカーネルによるメモリセグメントの処理方法を変更し、いわゆるユーザランドとカーネルスペース間のデータの移動に関連したセキュリティ侵害を事実上ブロックする。大半のOSではユーザランドとカーネルメモリスペースを処理する方法が要因となり、カーネルのバグの多くが（ある程度まで）悪用される可能性がある。
しかし、ではそれが実世界とどう結びつき、仮想環境においては何を意味するのだろうか？

そこで登場するのがvmsplice()バグだ。

Linuxシステム管理者の大半は良くご存じのように、有名なvmsplice()バグは昔からあるカーネルレベルの攻撃で、ローカルユーザならだれでも普通に使ってroot権限（管理権限）を取得できる。見つかったのは2006年で、すぐに公に知られるようになり、アンダーグラウンドで流行し、blackhat攻撃で幅広く利用されている。

UDEREFは、vmsplice()（および関連する各種攻撃）による悪用を不可能にした。つまり、どのLinuxシステムもある程度の時間無防備だったが、UDEREFを使ってハードニングが行われたマシンがそうなったことは一度もなかった。ことミッションクリティカルなサーバに関してはとてつもなく大きな違いだ。

なぜこれが関係してくるのだろう。それは、VMwareなどではUDEREF対応のカーネルをVMとして動かすことができないからだ。もっと正確に言えば、可能ではあるものの、パフォーマンスがあまりにも劇的に低下するためVMware環境を検知すると自動的に無効になってしまう。

仮想化環境では動作しないGRsecurityのもう1つの機能であるPAGEEXECでも同様のことが言える。これらの障害はコミュニティーでも有名で、Hardened Gentooチームはハードニングが行われたVMwareゲストをかなり以前からテストしてきた。

Hardened Gentooは、拠点サーバやリスクの高いインフラで利用するLinux OSの高セキュリティディストリビューションをサポートするオープンソースプロジェクト。

仮想化ベンダー各社は、マシンのセキュリティレベルを劇的に改善し、場合によってはこれまで見えなかったrootkitsをネット上で検知できるようなアーキテクチャを提案している。

これらの機能はセキュリティに対するわれわれの考えを確実に変えるだろうが、結局、仮想化ベンダーが自分たちの主張を裏付けられるようになるまで、仮想ゲストが物理マシンと同等のセキュリティを確保することはできないのだ。

ラベル: Security