Backdoor!!

ディスクの整理をしていたら、以前、VTCというコミュニティのイベントで話した VMware の VMwareTools と Hyper-V の統合サービスの実装についての話が発掘されたので、SlideShare にアップロードしておいた。

http://www.slideshare.net/tshiroyama/backdoor-vmwaretools

古い話だが、ここら辺の仕組みは現在でもさして変わらないだろう。
なお、PPTXでアップロードするとフォントがおかしくなるのでPDFでアップしたところ、背景の黒が抜けて真っ白になっている。読めなくはないのでそのままにしているが、読みにくい場合はダウンロードしていただければちゃんと背景が黒いPDFが手に入るので、そちらを見て欲しい。(や、フォントずれを探して直すのはさすがに面倒なので...)

対比としては、かなりまじめにハードウェアを再現しており、あまりこうした準仮想化的手法には頼らない VMware と、VMBus という架空のバスすら作ってしまうぐらい割り切ってしまった Hyper-V というのがかなり面白かったのを覚えている。

再現性と性能を両立させているだけあって、VMware の方が技術としては確かに 高いと言えるが、一方で自社のOS(Windows)はもとより、Linux ですらカーネルに仮想化専用の構成を突っ込んでしまって標準化させてしまった Hyper-V はそれはそれで面白いし、何より現実的と言える。

実際、WindowsServer 2008, 2008R2 以降であるならば、どちらで仮想化してもさして変わらないぐらいまではもってこれている。一方がベンチマークを公開する事に対してかなり厳しい姿勢を取っているのでなかなか適切な資料はないが、そうした最近のOSについては、性能についても優位性というのは言えなくなってきている。

聞くところによると、XBox One ではあのカトラーが開発に関わっており、仮想化環境上でゲームが動いているとか。チューニングはされているだろうし描画性能を稼ぐためのそれこそ特別な「バックドア」はあるのだろうが、もはや仮想化が性能に対してそこまでひどいインパクトを与えるものではない、という傍証にはなるかと思われる。

機会があれば最新のソースを引っ張ってどうなってきたかを読み比べてみたいものだ。

VMware Tools でカスタムスクリプトを実行させる

VMware Tools には、ゲストOSの起動/終了時、および仮想マシンをサスペンドやレジュームしたときにスクリプトを実行する機能がある。

Windows の場合は 「%ProgramFiles%\VMware\VMware Tools」 以下に以下のバッチファイルがあるのが見てとれるだろう。このバッチファイルが、それぞれのタイミングで実行されるスクリプトだ。

• poweron-vm-default.bat
• poweroff-vm-default.bat
• resume-vm-default.bat
• suspend-vm-default.bat

なお、Linux, FreeBSD, Solaris などUNIX系のOSの場合、/etc/vmware-tools 以下に同等のファイルが存在する。
OS X をゲストOSとして動かしている場合は、/Library/Application Support/VMware Tools/ 以下だ。

これらのスクリプトを編集することでOSの起動直後や終了前に様々な処理を追加する事ができる。特に View のデスクトップVMなどでは、終了前に ipconfig /flushdns, ipconfig /release をかけておきたいものだが、この機能を使えば簡単に実現できる。

ただ、特に Windows 版では、上記のスクリプトはインストール時に少々きつめの制限がかかってて、編集に苦労する。また resume と suspend については、実は空ではなく VMware 社自身の処理が入っていたりもする。念のために残しておきたいものだ。

そこで、デフォルトのスクリプトを編集するのではなく、スクリプトを別途作成、デフォルトのスクリプトに代わって VMwareTools に実行させる。これがカスタムスクリプトだ。

Fusion 4.0 や vSphere 5.0 までの VMware Tools では、GUIからカスタムスクリプトを指定することができた。

Fusion 4.0 までのタスクトレイのメニュー

VMware Tools を開くを選ぶと、各種設定が可能

しかし、Fusion 5 や vSphere 5.1 ないしそれ以降の VMware Tools ではこのUIがなくなってしまっている。

Fusion 5.0 ないしそれ以降のタスクトレイのメニュー

VMware Tools についてを選んでも情報が見えるだけだ

では、カスタムスクリプトを指定するにはどうすればいいかというと、GUIではなくコマンドラインからになる。VMwareToolboxCmd というコマンドが増えており、これをつかうのだ。
(Linux/FreeBSD/Solaris は /usr/bin/vmware-toolbox-cmd 、OS X は何故か /Library/Application Support/VMware Tools/vmware-toolbox-cli とコマンド名からして他のUNIX系と異なる)

Windows 版ではこのコマンドは VMware Tools のインストールディレクトリにある。
ただ、何故かこのディレクトリをカレントディレクトリにして使うことを前提としている節があるので、まず cd しておいたほうがいいだろう。

使い方は、「VMwareToolboxCmd help」を実行すると表示される

現在のシャットダウン時に実行するスクリプトのパスを表示するには「VMware Tools script shutdown current」で表示される

シャットダウン時のカスタムスクリプトを設定するには「VMware Tools script shutdown set "フルパス"」で指定する。相対パスは使えないので注意だ。

なんでこんなことをいまさら書いているかというと、カスタムスクリプトを仕掛けておいた vSphere 4.x 時代の仮想マシン(テンプレート)をずっと使っていたのだが、新しく作った仮想マシンでも同じくカスタムスクリプトをしかけようとして、見てみたら VMwareTools の GUI が無くなっており、設定ができなくなって焦ったから、だったりする。

VMware Tools のアップデート追記

昨日公開した VMware Tools のアップデート情報だが、間の悪いことにこれに関係するもう一つ新しいアドバイザリ VMSA-2012-0007 が出ていたので追記したい。

これは、Windows 向けの VMware Tools のフォルダの権限付けにミスがあり、これを突くことでゲストOS上の特権を奪えるというものだ。

上記のアドバイザリを参照して頂ければ分かるが、この脆弱性をもつ製品は非常に幅が広い。

• VMware Workstation 8.0.1 とそれ以前
• VMware Player 4.0.1 とそれ以前
• VMware Fusion なら 4.1.1 とそれ以前
• ESX/ESXi なら 3.5, 4.x, 5.0 

まぁ、要するにこの脆弱性への対応パッチやアップデートを含まれてない製品全て、ということになる。ホスト製品の場合はそれぞれ後継製品に、ESX/ESXi の場合は該当パッチを適用することで内蔵される VMware Tools に更新されるので、アップデートやパッチ適用後、Windows をゲストOSとする仮想マシン全ての VMware Tools をアップデートする必要がある。手間がかかるが必ず実施した方が良い。

なお、VMware Fusion 4.1.2 をダウンロード、その中の VMwareTools を確認したところ、バージョンは 8.8.3 (8.8.3.12575)、ビルド番号は 683185 のようだ。

VMware Tools のアップデート

少々旧聞だが、VMware 製品のセキュリティアップデートを通知する Security Advisories & Certifications に掲載された VMSA-2012-0004, VMSA-2012-0005 にて 「Windows版VMwareTools に含まれるディスプレイドライバ(XPDM, WDDM双方)にてメモリ管理の脆弱性があり仮想マシン内の Windows で特権を奪われる可能性がある」旨が告知されている。

対策としてはパッチ適用(ESXi500-201112402-BG など)になるが、これは ESX/ESXi に含まれる VMwareTools のイメージをアップデートするだけだ。具体的にこのパッチでのアップデート事項は KB 2007672 を参照して欲しい。

すぐに気がつかれたかと思うが、ただパッチを当てるだけでは問題は解決しない。各仮想マシンの VMware Tools をアップデートする必要がある。

逆に言えば、パッチを当てなくても VMware Tools さえ最新版を入手、アップデートすればこの問題については回避できる。

最新版の VMware Tools (Windows版)は以下ページから入手できる。

http://packages.vmware.com/tools/esx/latest/windows/index.html

x86(32bit)と x64(64bit)があるのでそれぞれ入手して欲しい。

また、VMSA-2012-0005 では VMware Workstation 等ホスト製品については問題がないとされているが、これはその環境で仮想マシンを動かしている場合に限られる。

VMware Workstation 7.1.5 より前、Player 3.1.5 より前、VMware Fusion 4 より前の各製品で作成、当時の VMware Tools をインストールしている仮想マシンを ESX/ESXi 環境に持って行った場合、VMware Tools のバージョンが古くてやはり問題が発生する。

もちろん、そもそも仮想マシンを ESX/ESXi 環境に転送しないなら問題はない。

対策としては、VMware Workstation なら 8へアップグレードする、7.x なら 7.1.5 にする、Player なら 3.1.5 をダウンロードしてアップデートする、VMware Fusion なら 4 を購入し、その上で VMware Tools をアップデートしておくといい。

とはいえ、仮想化製品をそうもアップデートできない、購入できない場合もあるだろう。その場合はやはり上記のページから VMware Tools をダウンロード、アップデートしておいた方が安全だ。

なお、VMSA-2012-0004 では同じ問題を記述しているが、こちらは VMware View に対するアドバイザリで、対策として「View 5.0 か 4.6.1 へアップグレード後、各仮想マシンごとの ViewAgent をアップデートする」という手順が記載されている。

脆弱性は VMware Tools 内のディスプレイドライバなので奇妙な話だが、View を使ってる場合は ViewAgent もあわせてアップデートしておいた方がいいだろう。

カスタム静止スクリプト

かつて VCB (VMware Consolidated Backup)のころ、アプリケーションレベルでの静止点を取得するためにスクリプトを走らせる機能が存在した。これがカスタム静止スクリプトだ。

これは VCB時代のドキュメントの仮想マシンバックアップガイド(PDF) の P.44 に記載がある。VCBによるバックアップ開始時に  %WINDIR%\pre-freeze-script.bat が実行され、終了時に %WINDIR%\post-thaw-script.bat が実行される。

ただ、当時試したところ動いている様子がなく気になっていたのだが、その時は急ぎ確認する理由もなかったのでそのままにしておいた。

そして、先日 カスタム静止スクリプトについて調べる機会ができたので少々確認をしてみた。

ご存じの通り、VCB のサポートは vSphere 4 までで終了し、現在では VADP (vStorage API for Data Protection) が利用されている。VCBはコマンドベースの技術でバックアップソフトからVCBのコマンド(vcbMounter.exe)を呼び出して連携をとっていたが、VADPはライブラリで提供され、バックアップソフトはこのライブラリのAPIをコールする事で連携をとっており、より密接な制御が可能となった。

さて、では VADPでカスタム静止スクリプトがあるかというと、まだ存在する。これについては、KB1006671が詳しい。

ESX/ESXi のバージョン	カスタム静止スクリプトのパス
3.5U1 とそれ以前	%WINDIR%\pre-freeze-script.bat %WINDIR%\post-thaw-script.bat
3.5U2 とそれ以降	C:\Program Files\VMware\VMware Tools\backupScripts.d\
4.x	%WINDIR$\backupScripts.d\
5.0	両方の場所を確認する
5.1, 5.5	%WINDIR%\pre-freeze-script.bat %WINDIR%\post-thaw-script.bat

なお、backupScripts.d フォルダはデフォルトでは作成されていないので、利用する場合は自分で作成する必要がある。backupScripts.d フォルダ以下にあるバッチファイルなどが全て実行されるが、その順序はバックアップ作成時はアルファベットの昇順(A-Z)で、終了時は降順(Z-A)となる。
Windows XP では 3.5U2 以降で実行していても旧来の pre-freez-script.bat 等が使われるようだ。

見ての通り、実は ESX/ESXi 3.5U2 以降でパスが変わっているのだ。これで当時うまく動かなかった理由が判明した。

私が VMware Infrastructure 3.5 を使い出したのは U2 の頃からで、それ以前は 3.0.3 を中心に 3.5 は様子見をしていたからだ。

なお、Linux など Windows 以外のOSの場合は、/usr/sbin/pre-freeze-script, /usr/sbin/post-thaw-script が実行されるようだ。これについては VMware DataRecovery 管理ガイドの P.8〜9 あたりに記載がある


追記: VCB サポートは vSphere 4.0 までではなく 4.1 までだったので訂正。そういえば 4.1 も VCB1.5u2 でサポートされていたのでした。
追記:20150106, 気がついたら対応表が変わってたのでこちらも更新