> >

報告に対する謝辞

報告してくださったのは HiTsu さん と あつしさんです。ありがとうございます。お二人の報告により、この件について調査し実際に何が起きているのかを説明する機会を得ました。

OSX.Exploit.MetaData.B とは何か

VirusBarrier X4 は手元にないので実際に私自身が確認できていませんが、OSX.Exploit.MetaData.B というのは恐らく Intego の文書「MAC OS Xにメタデータの脆弱性」に書かれているものの亜種と Intego 社が考えているものであると推測しています。この文書の英語版「MAC OS X METADATA EXPLOIT」はまさにこの名前だからです。

この Mac OS X の脆弱性は比較的最近話題になったもので、2006 年 2 月の後半に各所で報道されています。例えば

• Mac OS Xに深刻な脆弱性が発見される - 出所不明のZIPアーカイブに注意 (MYCOM PC WEB)
• Mac OS Xに深刻な脆弱性--「Safari」ブラウザの取り扱いに注意 - CNET Japan

などです。

これらの情報のソースは Secunia の「Mac OS X File Association Meta Data Shell Script Execution」というセキュリティ勧告です。この勧告では当該の脆弱性に関するテストを行うためのページが用意されています。これはテストというよりも実際にこの脆弱性を利用して自動で計算機を起動するためのアーカイブファイルが置かれていて、実証と言った方が適切でしょう。

この実証アーカイブの内容を調べると次のようになっています。

• Secunia.mov という名前のファイルとそのリソースフォークが入っている。
• Secunia.mov の内容は計算機を起動するシェルスクリプトである。
• Secunia.mov は実行パーミッションが付いている。
  これは UNIX の一種である Mac OS X にとっては Secunia.mov がコマンドであることを意味します。
• Secunia.mov のリソースフォークは Secunia.mov はターミナルで開かれるファイルであることを示している。

この仕掛けにより、Secunia.mov という一見 QuickTime ムービーであるかのようなファイル名を持つファイルは、ダブルクリック(open)によってターミナルが開いて実行するシェルスクリプトになっているのです。

この脆弱性の発見当時、Safari や Mail という Mac OS X にバンドルされているソフトウェアは、このようなアーカイブをダウンロードした場合、自動で展開し更に自動で実行するようになっていました。つまり、アーカイブファイルへのリンクをクリックする(辿る)だけで自動でそのアーカイブファイルに入っているシェルスクリプトが実行されてしまうようになっていました。

当該の脆弱性のステータス

Apple はこの脆弱性に対抗するためのアップデートを既に二つ提供しています。そのアップデートと関連箇所の引用を示します。

Security Update 2006-001

Safari、LaunchServices
CVE-ID：CVE-2006-0848
利用可能な OS バージョン：Mac OS X v10.3.9、Mac OS X Server v10.3.9、Mac OS X v10.4.5、Mac OS X Server v10.4.5
影響：悪意のある Web サイトを表示すると、恣意的にコードが実行される危険がある。

説明：実際にはアプリケーションであるファイルを画像またはムービーなど安全なファイルタイプであると見せかけることができます。Safari の「一般」環境設定で「ダウンロード後、"安全な" ファイルを開く」オプションを選択している場合、悪質な Web サイトを表示することで、このようなファイルが自動的にダウンロードされて実行される危険があります。実際に、公開されている Web サイトにおいてシェルスクリプトが自動実行されることが確認できています。このアップデートでは、追加のダウンロード検証を実行してユーザに警告が表示されるようにする (Mac OS X v10.4.5) か、ダウンロードされたファイルが自動的に開かないようにする (Mac OS X v10.3.9) ことで、問題を解決しました。

Security Update 2006-002

Safari、LaunchServices、CoreTypes
CVE-ID：CVE-2006-0397、CVE-2006-0398、CVE-2006-0399
利用可能な OS バージョン：Mac OS X v10.4.5、Mac OS X Server v10.4.5
影響：悪意のある Web サイトを表示すると、任意のコードが実行される危険がある。

説明：「Security Update 2006-001」では、画像やムービーなど安全なタイプのファイルに見えるものの実際にはアプリケーションであるファイルを Safari が自動的に開くという問題を解決しました。今回のアップデートでは、「Security Update 2006-001」で対処済みの悪意のあるファイルタイプに対して、その変形版が自動的に開かれないよう識別するための検証を追加しました。この問題は Mac OS X v10.4 よりも前のシステムには影響を与えません。この問題の報告は CERT/CC 社の Will Dormann 氏と Andris Baumberger 氏の功績によるものです。

Secunia の勧告でもこのアップデートを適用するのが解決方法だと書いてありますが、次の注意書きもしてあります。

The update does not completely fix the vulnerability as it is still possible to trick users into opening malicious shell scripts (masqueraded as a safe file type) in ZIP archives. Do not open files in untrusted archives.

このアップデートは当該の脆弱性に完全な対処をするものではありません。ユーザを騙して ZIP アーカイブの中にある(安全なタイプのファイルに偽装した)悪意のあるシェルスクリプトを開かせることがそれでも可能だからです。信頼できないアーカイブを開いてはなりません。

ここで Secunia の勧告は「automatically(自動で)開かせる」とは言っていません。つまりユーザがダブルクリックなどで(安全なタイプのファイルに偽装した)悪意のあるシェルスクリプトを開く操作する可能性があるからまだ危険が残ると言っているのだと解釈できます。

結局どんな場合が危険とされているのか

以上のことからアップデートを行った最新の Mac OS X においては次のようなファイルが危険であるとされていることになります。

1. ファイルの拡張子などにより単なる書類のように見せかけたファイルがあり、
2. そのファイルの内容はシェルスクリプトになっていて、
3. そのファイルに実行パーミッションが付いているときに
4. そのファイルのリソースフォークでターミナルで開くように設定されて
5. しかもそれが ZIP アーカイブになっているとき
   私の考えでは、ここは ZIP アーカイブに加えて、sit アーカイブ、Mac OS X 10.4 以上の tar アーカイブと tar.gz アーカイブのようにリソースフォークが保存されるアーカイブとすべきです。

iBlogFreezer の何が問題とされてしまっているのか

ここまで解説してようやく iBlogFreezer の話に移行できます。iBlogFreezer を提供するためのアーカイブは次のようなものです。

1. iBlogFreezer に拡張子は付けていない。
2. iBlogFreezer の内容はシェルスクリプトになっている。
3. iBlogFreezer に実行パーミッションが付いている。
4. iBlogFreezer のリソースフォークでターミナルで開くように設定されいる。
5. しかもそれが sit アーカイブになっている。

a. iBlogFreezer に拡張子は付けていない。

Mac OS X は一種の UNIX です。UNIX (のベース部分)では拡張子という概念でファイルの種類を表しません。実際、Mac OS X の /usr/bin/ というディレクトリにある UNIX 由来のコマンド達には拡張子は付いていません。私の公開物やこのブログで書いている様々なアプローチが示すとおり、私がスクリプトを書くとき Mac OS X を UNIX として扱い、そして UNIX では元来拡張子という概念でファイルの種類を特定せず、コマンドには拡張子を付けない習慣です。iBlogFreezer もそのために拡張子を付けていません。

ですから偽装でもなんでもなく、コマンドとしての iBlogFreezer の自然な状態です。

b. iBlogFreezer の内容はシェルスクリプトになっている。

iBlogFreezer の動作を最も簡単に実装するのはシェルスクリプトだと判断し、シェルスクリプトで実装してあります。

シェルスクリプトは Mac OS X 自体の中でもたくさん使用されています。実際、Mac OS X を起動する度に皆さんはシェルスクリプトのお世話になっています。

c. iBlogFreezer に実行パーミッションが付いている。

内容がシェルスクリプトであってもそれに実行パーミッションが付いていなければ、それは UNIX システムから見たらただのテキストファイルです。シェルスクリプトは実行パーミッションが付いて初めてコマンドとなります。

ですから iBlogFreezer に実行パーミッションが付いていなければ、iBlog データのバックアップという目的を iBlogFreezer は達成できません。

d. iBlogFreezer のリソースフォークでターミナルで開くように設定されいる。

この設定の具体的な方法は iBlogFreezer の配布用エントリの「実行方法」というセクションに書いてある 1 から 7 までの手順です。

私個人の使用においてはこの措置は必要ありません。私の公開物やこのブログで書いている様々なアプローチが示すとおり、私にとってターミナルを通してコマンドを使って Mac OS X を利用することは自然なことで、面倒ではないからです。むしろこっちの方が私にとって便利です。

ただ、iBlog は比較的多くの人が経験するようにデータが壊れやすいソフトウェアです。このため正常な状態のバックアップが iBlog を利用する上で重要です。自分のために作ったものであるとはいえ、それを使うことは多くの iBlog ユーザを利することになると考え iBlogFreezer を公開しています。

この公開主旨から見て、ターミナルを介してコマンドとして使用する素の iBlogFreezer では比較的敷居が高く、iBlogFreezer の意義を享受できる人が限定されてしまいます。

この限定を取り払うためには他の Mac OS X の書類やアプリケーションと同じように Finder から開くこと(ダブルクリックするなどの行為)によって iBlogFreezer を実行できることが大切だと考えました。

e. しかもそれが sit アーカイブになっている。

d の設定はリソースフォークに書き込まれます。リソースフォークを含まないアーカイブではダウンロードした人に d の設定をさせることになります。しかし、より多くの iBlog ユーザが支障なく使えるようにするためにはそのような設定をわざわざしなくても既にそうなっていることが望ましいと考えました。それでリソースフォークが残るアーカイブを選択する必要があったのです。

以上、なぜ iBlogFreezer が今の状態であるかを説明しました。そしてその結果できあがった状態はセクション「結局どんな場合が危険とされているのか」と酷似しています。違いは

• 悪意のあるシェルスクリプトではないこと
• 偽装されていないこと

です。偽装されていないことはほぼ自明です。

悪意は本当にないのか

これは最終的には私個人の心の中の問題ですからそれは信頼していただくよりほかはありません。しかし私はそれを検証する手段を提供しています。これはこのブログで公開するソフトウェア全般に共通するポリシーの一つです。

「ここで公開するソフトウェアは、その動作の全てを利用者が知ることが可能でなければならない」というものです。そしてそのポリシーの実現方法として「ここで公開するソフトウェアは、ソースを全て公開する」という手段を採用しています。そしてテキストファイルの一種であるスクリプト(Perl スクリプトやシェルスクリプト)は、その性質からして完全なソース公開がされたソフトウェアです。なぜならば、実行可能な状態で既にテキストエディタで開くことにより、内容の全てを参照できるからです。コンパイルしてバイナリファイルとして出来上がるソフトウェアでは、ソースを提供したとしてもバイナリを提供していては、そのバイナリに公開されていないソースが使用されているという疑いを晴らすには、公開されたソースを使って同じ環境でビルドしなければなりません。全く同じ環境を揃えることが誰にでも実際にできるわけではありませんし、ソフトウェアをビルドすることになると尚更です。しかし、シェルスクリプトはテキストを閲覧することができさえすれば誰にでも内容を確認することができます。そしてテキストを閲覧するということ以上に情報の取得として相互運用性に富んだ方法はまずないでしょう。

つまり、iBlogFreezer も含めここで公開しているソフトウェアは全て、いつでも誰でもその内容の全てを検証することが可能でなのです。もし私が悪意のあるコードを入れていたとしてもそれを見付けることができます。そのソフトウェアをテキストエディタで開いて調べれば良いのです。

このようなポリシーと方法で公開することで私は常に私の公開ソフトウェアが監視されている状態を作り出しています。それは個人がソフトウェアの公開にあたって最小のコストで最大の安心を生み出す最善に近い方法だと考えています。

超要約

OSX.Exploit.MetaData.B が指す攻撃は実行してはならないシェルスクリプトを実行させることです。実行してよいシェルスクリプトを実行することではありません。実行してよいシェルスクリプトであるかどうかはあなたが判断してください。私は判断材料も提供しています。

# と要約しすぎると何だか怒っているみたいだなあ。

追記

2006年3月29日

Mcafee Virus Scan for Macintosh (Virex) の最新 DAT ファイル (3月22日付けの 4724) にはこの Mac OS X の脆弱性を利用したトロイの木馬への対応が含まれています。

• OSX/Exploit-ScriptEx
• OSX/Exploit-ZipShell

現時点での最新の DAT ファイルを用いて iBlogFreezer および現時点でのアーカイブファイルである iBlogFreezer-1.1.sit をスキャンした結果、正常であることを確認してあります。

また Norton AntiVirus for Macintosh (NAV 7.0.2) の最新ウィルス定義ファイルには該当するものが見付けられませんでしたが一応検査してみました。同様に問題ありません。なお、サイト上では現時点の最新ウィルス定義ファイルの更新日は2月 28日 2006と表記されていますが NAV 上では 3月1日 と表記されています。

というわけで、上の説明からみても他の対策ソフトウェアの反応から見ても VirusBarrier のVirusBarrier X4 の過剰な反応と考えています。

2006年4月2日

VirusBarrier X の現時点での最新のウィルス定義(06/02/28)でもチェックしましたが同様に問題ありません。このウィルス定義にはここで取り上げている Mac OS X の脆弱性への対策が含まれています。

Intego VirusBarrier XおよびX4と2006年２月23日付けのそのウイルス定義ファイルが、この種類の隠された実行ファイルに対する保護を提供します。

2006年4月2日の Intego セキュリティ・メモ から引用

VirusBarrier X4 の方は 06/03/13 が最新です。X4 向けのこのウィルス定義あるいは X4 自身による反応と思われます。この違いが何を意味するかは私には不明です。

2006年4月4日

VirusBarrier X で 06/04/01 のウィルス定義ファイルによってようやく似た現象に出会えました。しかしながら相変わらず iBlogFreezer には特に反応しません。

ウィルス定義ファイルが更新されたのでディスク全スキャンを行いました。私のディスクの中で三つの自作シェルスクリプトが OSX.Exploit.MetaData.B であると 06/04/01 を用いた VirusBarrier X で報告されました。この三つはどれも上に解説したようにターミナルで開かれるようにしてあるものです。試しにその中の一つを「駆除」してみたところ、ターミナルで開くという指定が外れただけの変更でした。

しかし全てのそういうシェルスクリプトに反応したわけではありません。iBlogFreezer には何ともいいませんでした。相変わらず挙動が不明です。