Mac OS Xのセキュリティホールを利用するということですが、 どのバージョンで脆弱性があるのか、ダブルクリックで起きるなら Mac OS 9以前でも同様ではないのか、それから具体的な対策方法 がファイルをダブルクリックしないこととしか示されていませんね。 またJPEGとGIFでも同様だと書いてありますが、PNGやTIFFやPDF なら大丈夫ってことなのでしょうか。Mac
Carbon/CFMのアプリケーションに適当な拡張子をつければ、このトロイの木馬と同じことが可能になりますので、拡張子を持つ全ての書類でこの脆弱性を用いたアタックが可能になります。
Mac OS 9以前であっても同様。拡張子でアイコンがつかないタイプのファイルであれば、任意のアプリケーションのアイコンでも貼付けておけばいいわけです。
もっと具体的で詳細な情報が欲しい (スコア:2, 興味深い)
どのバージョンで脆弱性があるのか、ダブルクリックで起きるなら
Mac OS 9以前でも同様ではないのか、それから具体的な対策方法
がファイルをダブルクリックしないこととしか示されていませんね。
またJPEGとGIFでも同様だと書いてありますが、PNGやTIFFやPDF
なら大丈夫ってことなのでしょうか。Mac
Re:もっと具体的で詳細な情報が欲しい (スコア:5, すばらしい洞察)
harden-mac MLには[harden-mac:0620] Re: First Mac OS X Trojan Horsel [ryukoku.ac.jp]が投稿されています。
手前味噌で申し訳ないが私の日記 [hatena.ne.jp]では考察も入れています。
この手のネタではリンク貼っても読まない人が多いみたいなんで要約しますが、
Carbon/CFMのアプリケーションに適当な拡張子をつければ、このトロイの木馬と同じことが可能になりますので、拡張子を持つ全ての書類でこの脆弱性を用いたアタックが可能になります。
Mac OS 9以前であっても同様。拡張子でアイコンがつかないタイプのファイルであれば、任意のアプリケーションのアイコンでも貼付けておけばいいわけです。
Appleに望む対処、つまりSecurity UpdateでAppleがこの脆弱性をつぶすときに取れる手段は以下が考えられます。
・Carbon/CFMの禁止
これは、まぁ、無理でしょう。
・アイコンに実行可能バッチの追加
実行属性を持つファイルのアイコンに、エイリアスなどと同様、アプリケーションであるパッチをつけることで、ユーザ任せの回避策ですが、これもあり得る解決策ですね。ただ、アプリケーションを何らかの手法で実行されてしまう可能性もないとは言えないので、実効性は薄いと考えます。
・アプリケーション起動パスの制限
/Applicationsや~/Applicationsなどの限られた場所にないアプリケーションを起動できなくすることで、現在表面化していない様々な脆弱性に対処できます。
ぜひとも、アプリケーション起動パスの制限が実装されてほしいものです。
切り分け？ (スコア:3, 参考になる)
- Carbon app を普通のファイルに偽装させる
- mp3 ファイルのid3 タグにスクリプトを仕込む
は別の物として考えるべきだと思います。上の場合はファイルの上にポインタを合わせるとファイル情報の要約が 出るようにしておけば防げます。
つまり拡張子やアイコンを信じるのではなくて、ls -l とfile の結果を信じる、 ということです。
下の場合には仕組みがよくわかってないので何ともいえませんが
QuickTime なりの実装に問題があるように思えます。
他の方も書き込んでますが、ここの情報が欲しいです。
今回のタレ込みはこの下の問題を言っているのであって上の問題と ごっちゃにしない方がいいと思います。
Re:切り分け？ (スコア:3, 参考になる)
今回の警告と同じような動作をするサンプルが、既にあがっているのですが
http://www.scoop.se/~blgl/virus.mp3.sit
このファイルではMP3ファイルのID3タグ内にppcのCarbonアプリケーションが埋め込まれ、ファイルタイプがAPPLとなっています。ダブルクリックするとID3タグ内のアプリケーションが実行されますが、iTunesで普通にMP3として音声を聞くことも可能です。
この方法を用いても同じことができる、というだけで同じ手法を用いたトロイの木馬が今回発見されたものかどうかは判りません。ここのきり分けをせずに投稿していました。
ようやくわかった！ (スコア:1)
たぶん、今回の話のキモは、このことなんですね。
だから、QuickTimeやiTunesについての話ではないと。
Finderについての脆弱性であると。
ファイル消せちゃうとか、メール送れちゃうとかは、「コードが動けば何でもできる」という部類に属する話で。
そうであれば、最大の謎、GIFファイル等にも感染するっていう意味も、何となくわかるような気がします。
既存のファイルに、実行コードをコピーして、アプリだよって言ってしまえば、ダブルクリックで実行してしまうと。
もしそうなのであれば、ファイルの種類は問いませんね、きっと。
＃もちろん、私がわかった気になっているだけで、全く違う話かもしれません。
Re:切り分け？ (スコア:1)
MP3のヘッダぶんコードフラグメントの開始位置をオフセットさせるのがキモなんですね。
事実上、アプリケーションなコードフラグメントがオフセット0以外から始まってるのって
ほとんどないような気がするので、Launch時にそのへんを見て警告を出すような機能拡張
（つーか、今はどうやって実装したらいいんだ？）で、防御できたりするかも？
Re:切り分け？ (スコア:1)
まさにそのような処理をするための措置が、[harden-mac:0632] [slashdot.jp]にあがっています。
LaunchCFMAppがCFMなアプリケーションを起動する前にチェックするプログラムのソースファイルとその使い方がアップされています。
参考までに。
Re:切り分け？ (スコア:2, 参考になる)
リンク間違ってるし（笑
[harden-mac:0632] [ryukoku.ac.jp] ですね。
--
vm％パスワード忘れた
Re:切り分け？ (スコア:0)
みたいな少々不細工な仕様にでもしないと、避けられない気がします。
これって昔から存在する伝統的な脆弱性と言えるかもしれませんね。
拡張子に見合う書類のアイコンがバインドされてたら、通常は判別出来ま
Re:もっと具体的で詳細な情報が欲しい (スコア:2)
そういう否定されているレガシーなやり方では全くダメですね。
同じパスにインストールされるアプリケーションに付属する書類は
実行出来てしまうのだし。それにMac OS 9でどうやるんですか？
局所的かつ暫定的としか思えない方法には反対します。Appleには、
もっと上手くまともな対処をやってくれるように期待しています。
Re:もっと具体的で詳細な情報が欲しい (スコア:1)
Re:もっと具体的で詳細な情報が欲しい (スコア:1)
古めのマシンでディスク容量ケチる時に、アプリ本体を別ディスクに移している場合など、猛烈に困りそう。
**そんなユーザは今更いうなという気もするが、XPostFactoで無理やり入れてる人などモロにきそう・・・。
Re:もっと具体的で詳細な情報が欲しい (スコア:0)
ファイル消去とかの悪意のあるコードを入れたAPPLなファイルに hoge.mp3 というファイル名を付けただけのものと大差ないような。アイコンだってカスタムアイコンでmp3のふりをすれば同じ事。これを脆弱性と呼ぶのなら、アプリ起動を禁止するほか無い！？
Re:もっと具体的で詳細な情報が欲しい (スコア:1)
というのがあります。ダブルクリックしてiTunesで再生された
*.mp3ファイルを、「MP3ファイルではないかも知れない」と判断する
人は少ないでしょう。
見た目だけならこれまでもだませたと思うので、今回のは
APPLタイプがついたファイルの中にJoy!peffを見つけたら、
CFMアプリだと思って無条件にローンチしてしまう起動サービスに
脆弱性がある、と表現するのが正しいのかな。
確か上記8バイトはCFMなアプリの先頭に付くはずなので、今回の
例でいうと ID3ヘッダなどを無視してることになりますからね。
Re:もっと具体的で詳細な情報が欲しい (スコア:0)
>APPLタイプがついたファイルの中にJoy!peffを見つけたら、
>CFMアプリだと思って無条件にローンチしてしまう起動サー
>ビスに脆弱性がある、と表現するのが正しいのかな。
>
>確か上記8バイトはCFMなアプリの先頭に付くはずなので、
違い
Re:もっと具体的で詳細な情報が欲しい (スコア:1)
適当にググったらそう書いてあったので、そう思い込んでました(^^)ゞ
で、ちょっとまじめに探してみたんですが、このへん [apple.com]でしょうか…。
Mach-Oにも適用可能となると、影響が大きそうですね。
Re:もっと具体的で詳細な情報が欲しい (スコア:1)
を入れてしまったことに問題がある訳ですね(拡張子でファイルを
偽装するなんてWindowsで使い古された手で、Macには通じない
ものだったのに)。ファイルタイプと クリエイタータイプでファイル
の種類を判断することを徹底させて、拡張子は基本的に便宜上の
付属品と見なす方が良いですね。
Re:もっと具体的で詳細な情報が欲しい (スコア:1)
ほかのMP3やJPEGなどのファイルに感染する可能性というところでひっかかって、自分も最初誤解していたのですが、今回配付されていたコンセプトファイルに関しては自前でアイコンを持っているので、拡張子はあんまり関係ありませんでした。
普通のデータファイルで単純にファイルタイプを"APPL"に変更すると、そちらが優先されてアプリケーションのアイコンとなります。なので、アイコンを偽装しようとすると、自前で持つか、カスタムアイコンを貼り付けるかということになるので、拡張子には関係なくなるのではないかと、いまのところは思うようになりました。
Re:もっと具体的で詳細な情報が欲しい (スコア:0)
エイリアスに矢印の目印つけるように、APPLや.appにも目印つけたらいいのに
（完全解決とは行かないけど、拡張子に惑わされにくくなるのでわ）
Re:もっと具体的で詳細な情報が欲しい (スコア:0)
アイコンを欺瞞したドキュメントをダブルクリックすると隠された
親アプリケーションが起動する様にし、ドキュメントが普通に開いた
時と同じ動作をしつつ陰で悪さ