リンクとか備忘録とか日記とか

2002.02.28

6. ■ うぉぉおおお。今すぐオレに本家 Slashdot の奴らに言い返せる位の英語力をくれー！＞ Slashdot | Mac OS Auto-Execution Vulnerability
   っつーか筆遅いんだよ。オレ。ぐふぅ。
   
   # yourCatさん。ナイスっす。あ。日記読ませてもらってます....。
   # って、ここで挨拶してどうするよ。＞ オレ
   
   
5. ■ ↓の最後の方を受けて、太洋さんが3DCG デザイナーであることの証明に彼の新作にリンクしとこう。＞ 寄生虫
   3DCGなのーがき (笑) は太洋さんの日記『ギャラリーに新作アップ』まで。
   # でさ。太洋さん。<TITLE> とかギャラリーページのコメントが謹賀新年系なのはそのママで良いの？
   ## で、ホントお疲れさんでした。＞ 太洋さん　いや、ホントはコレ言っときたかったのよ。
   
   
4. ■ で、いつか書こうと思っていた事を。幾人かの名誉の為に。
   まだ 2002.01.28 番外編：Auto file execution vulnerability in Mac OS の件でアレなんですが、私や太洋さんが色々書く前に“知っていた”もしくは“書いていた”方々がいらっしゃるんですよね。実は。
   
   
   • 太洋さんトコのログ経由、[1] flite site さんの所の『[824] soire fri feb, 1st 13:19』。「僕も実は前から気付いていたのですが、同様のことを書いている人がいることを知りました。」と述べてらっしゃいますね。まぁやはり気付いていた方はいらしたんだなぁなどと。
     
     
   • 2chの新Mac板『【速報】Mac版 IEにセキュリティホール【速報】』の >>106と>>107 経由、スラッシュドット ジャパン | Internet Explorer for MacOSに巨大なセキュリティーホール での 別にIEでなくとも (スコア:2) ( nidak のコメント: Thursday October 04, @03:33AM )
     こちらはもうマンマですね。問題点から実行の仕組みから回避策までしっかり書かれています。脱帽です。ってゆーか、前述の2chのスレで知ったので2/3か2/4にはもう知っていて、読んだ瞬間に、このまま自分の手元でドキュメントをまとめたり告知したりし続けようかどうしようかかなり迷いましたね。でも実は既に各ベンダーに告知した後だったりして「うぇぇ、引くに引けないなぁ。んー。」なんて思ったりしましたが。今でも「Bugtraqに自分が投稿して良かったのかなぁ」とか「日本語の情報でこれだけ集まるなら世界的には結構知ってる人も多かったりして、Bugtraqに投げる程の事だったのかなぁ」なんて思ったりもします。
     
     ちなみにこの/.Jへのコメントには他にも沢山良いコメントが有って、読んでなかったのが悔やまれました。
     Re:勘違いではなく (スコア:0) ( Anonymous Coward のコメント: Thursday October 04, @04:56PM ) でもStuffit Expanderのイメージ自動マウントとQuickTimeのAutoStartに触れてますし、Re:ダウンロードした場合 (スコア:1) ( jbeef のコメント: Thursday October 04, @11:28PM ) は「流石 jbeef さん (って私の知ってる jbeef さんと同一人物であれば、ですが) 。」と思えますし。
     とゆーか「IEの.hqx 自動デコード→自動実行のスレッドにこんなに沢山おいしいコメントが有ったとは....」って気分でした。この件はこのページでも大して深く取り上げてなかったんですよね。何だか完全にノーマークで頭ぶん殴られた気分でした。
   
   ま、ですから、今回のこの脆弱性、やっぱり気付いてる人は結構多くてそれらの方々は自分で対処されていたりして、でも大勢のMacユーザが気付いてなくて、ほとんどの人が対処してなかった、ってだけなのかも知れないですね。
   
   そう言えば、かの2chのスレで >>119 の様に言われてましたが。そんなつもりは毛頭有りませんし、太洋さんにも無いですが。って他人なのに断言するのも何ですが無いでしょう。だってねぇ。私がDTPオペで、彼は3DCGのデザイナーですから。セキュリティで名前売ってどうすんの？って感じなんですよ。いや、仕事くれれば*私は*嬉しいけどさ。でもセキュリティの仕事なんて出来んもの。今日の2. で書いた様に私ヘタレですから。
   
   って、そーゆー事が言いたかったんじゃなくて、この件を既にご存じの方がいらっしゃった、とゆー話でした。
   
   
3. ■ って、先に小島さんがセキュリティホール memo上で「登場してますね」って書いて下さってますね。_o_
   
   
2. ■ で、まぁやっとこさBugtraqに載った様で ＞ http://msgs.securepoint.com/cgi-bin/get/bugtraq0202/269.html
   いやホント。皆さん有り難うございました。色々と。って、まだお返事書いてない方々もいらっしゃるんですが (汗) 。そういえば Tea Room for ConferenceのNo.620にもコメントしてないし (大汗)
   
   でまぁ投稿３回目。初投稿から約２週間ですか。えーと。何でBugtraqでmoderateされなかったかとゆーとですね。無茶苦茶恥ずかしいんですが。恐らく私がいー加減なSMTPサーバを使ってるせいです。きっと。いや、自分で立てたんですけどね。そのSMTPは。まぁ要は私がヘタレだって事で。そんなヘタレがBugtraqに投稿していーのかってのも有りますが。んですからね、自分のトコのSMTP使わずに、subscribeしてないvm_converter@mac.comからMac OS XのMail.appでsmtp.mac.comをauthentification入れて使ってみましたよ。そしたらOKでした。
   で、まぁ、subscribeしてるかどうかはやっぱり関係有りませんでした。その節はホントにお世話になりました。＞ awacs@hawkeye さん
   
   ですから皆さん、もしBugtraqに投稿する事があれば身元のきちんとしたSMTPを使いましょう。って、そんな事でコケる人が他にいるとも思えませんが。トホホ。
   もうね「常時接続性さえ確保できればいーや。relayにも踏み台にもならないようにしてるし。手元にSMTP有った方が早くていーんだもーん」って安易な気持ちでSMTP立てるの止めますよ。ホント。まさか自分に跳ね返ってくるとわね (萎) 。いやSMTPだけの問題じゃ無いんですけどね。当然。でも、所詮シロートなんで精進しますです。あ、いや、しばらくこのままですけどね。近日中に回線入れ替えるんで、その時に。はぁ。
   
   しかしBugtraqって投稿すると“Undelivered”とか“User Unknown”とか“failure”とか“out of the office”とかドカドカ来るのねぇ。全部で20通弱来ましたよ。あんたが休暇中かどーかなんて知りたくないっちゅーの。ML管理者の方々のエラーメール嵐の気分をホンのちょびっとだけ味わいました。ま、でも実際はこいつらが届いたお陰で「あぁ投稿に成功したんだな」って解ったんですけどね。
   
   まぁ、初めてのお使いみたいな気分でしたよ。一介のDTPオペレータにしちゃ、いー経験させてもらいましたわ。
   って、日本以外じゃまだまだ終わってない話だったっけ。ま、私の中じゃやっと一段落つきました。ふぅ。んじゃま回線移行でもやりましょかね。
   
   
1. ■ 2002.01.28 番外編：Auto file execution vulnerability in Mac OS に、■各ベンダーの対応状況 を追加、■謝辞など を 英語版のドキュメントに合わせて修正しました。遅くなりまして済みませんでした。
   
   

2002.02.21

4. ■ って書こうと思ってた大事な諸々を書いてなかった。
   
   ぴぐもんさん。有り難うございました。＞ 2002-02-17(その02)
   余裕が出来たら参考にさせてもらいます。_o_
   
   あと思いっきり遅れまくってるってゆーか一月近く経ちつつあるんですが、一言述べておきたく。
   EVERYDAY PEOPLE さんと言いますか、nightingale..さん。お疲れ様でした＆有り難うございました。
   
   はまもとさん。お疲れ様です。ホントに。
   connect24h-free（常時接続の宴予備校）盛況ですね。「あーすげぇ未読メールがたまってくー」な状態ですが。頑張りすぎない様に頑張って下さい。＞ 富永(ぬわあ)さん
   
   
   あ。日本語ドキュメントの方の謝辞とか直してない.....。ごめんなさい。皆様。
   えーと。後程。ごめんなさい。こんな日記書いてる位ならそっちやれば良かった....。ってゆー位ならSecureMacの方か....。んー。ぐるぐるだわ。
   
   
3. ■ とゆー訳で、花粉症も発症してさらに萎え萎えのまま、またしばらくさようなら。既に日記じゃなくて 週記 になってる今日この頃ですが。ってゆーか「あ？出たの？10.1.3。あーうー。」って状況です。まだご存じない方ってあまりいらっしゃらないかと思いますが、Mac OS XでソフトウェアアップデートでGO！とゆー事で。sudo が更新されてないのはpostfixとセットな話だったからじゃないですかね。ま、だからって「何故上げないの？」って話は有る訳ですが。そんな程度しか追っかけられてません。
   
   
2. ■ 2/15の2. で書いた 2002.01.28 番外編：Auto file execution vulnerability in Mac OS についてBugtraqに投稿した件ですが。反応が無かったので、Date: Tue, 19 Feb 2002 00:10:28 +0900 つまり2/19未明に今度はちゃんとsubscribeしているアドレスから同じ内容で投稿し直しました。トホホ。
   そうしたら Date: 19 Feb 2002 12:58:47 -0000 つまり日本時間で2/19の21:58に『Returned post for bugtraq@securityfocus.com』なるメールが ezmlm から届きました。一部引用すると、

   I'm sorry, the list moderators for the bugtraq list have failed to act on your post. Thus, I'm returning it to you. If you feel that this is in error, please repost the message or contact a list moderator directly.

   だそうで。repostした後に届くとは。しかしやはり先に送った奴はモデレート対象にさえなっていなかった様で。トホホホ。んでも、後に送った方もまだBugtraqに流れてこないですね。んー。何か根本的に送ってる内容がダメなんでしょうかねぇ。はぁ。既にかなり萎え萎えなんですが。
   
   しかし最初に送った方が Date: Thu, 14 Feb 2002 21:25:42 +0900 に送っていてリターンメールが丁度５日後。Bugtraq位の規模になるとそれ位かかるのかとちょっと吃驚。まぁ後から送った方もまたダメだったら５日後位に戻ってくるんでしょう。そしたら.....んー....どうするかなぁ。「contact a list moderator directly」かコンパクトにまとめなおして再送か、か。んー。コンパクトにする余裕も無いしなぁ。ってゆーか英文の再構成する余裕が有る位ならSecureMacの方にかかりたいんですが。
   
   あ。一応、Bugtraqに投げたメールそのままのを上げておきます。Subjectは『Auto file execution vulnerability in Mac OS』のまんまです。何か「○○がダメ」とか助言頂けるととても嬉しいです。vm_converter@mac.com 宛まで宜しくどうぞ。「もうまるっきりダメ」とか全否定されると萎え萎えのショボショボになっちゃうのでお許し下さい。
   
   んでも、ほぼ同様のメールを投げたMozilla.org (Bugzilla) はちゃんと反応してくれたんだが。んー。
   # あ。オレが投げるとダメだったりして。そういやBugzillaに投げたのオレじゃないや。
   
   
1. ■ うわぁぁああ。ごめんなさい。ごめんなさい。ごめんなさい。ごめんなさい。ごめんなさい。＞ SecureMac.com日本語化計画
   
   お流れにはしたくないものの、未読メールの前に多重債務者の様な気分でいたりしますです。むにゅぅ。
   
   

2002.02.15

5. ■ 言い忘れてましたが、2. で書いた英語版のドキュメントの [Thanks] の部分に関して訂正・削除の依頼など有りましたら vm_converter@mac.comまでご連絡下さい。とは言っても既に皆さんにメールは送りましたが。
   
   あと「私も情報提供したはずだが載っていない」という方や「オレも情報提供したのに載ってねぇじゃねぇか ｺﾞﾙｧ!!」な方もご連絡頂ければ幸いです。宜しくお願いします。
   
   
4. ■ あ。日本語版の方の謝辞も書き直さなきゃ...。
   
   
3. ■ Auto file execution vulnerability in Mac OS の ◆必須ではないが有効な対処 のStuffit Expanderの部分に、
   
   ・[環境設定...] ＞ [保存先] で [その都度指定 ] を選択する
   　（解凍の度にダイアログが表示されて保存先を聞かれるので、ダウンロード後に意図しない解凍処理が始まってもキャンセルする事が出来ます）
   というのを追加しました。（実は下記の英語版ドキュメントには既に追加してあります。）
   
   この対処法は、再びRayさんから教えて頂いたものです。
   ◆重要度が高い必須の対処として万人にお勧めするものではありませんが、私個人もとても気に入りました。
   全てのブラウザがNetscape 6.xやMozillaの様にダウンロード開始時にダイアログを表示する様になるとも思えませんので、全てのダウンロード終了→自動解凍の際に毎回ダイアログが表示されるのは私は良い事なのではないかと思います。
   
   Rayさん、度々の情報提供有り難うございます。
   
   
2. ■ 昨晩やっとBugtraqへの投稿を終えました。色々皆様有り難うございました。って、まだ採用されていませんが。
   で、投稿するに当たって今公開している日本語のドキュメントから英語のドキュメントを作りました。興味の有る方は↓からご覧下さい。基本的に英語のスキルはご容赦を。
   http://homepage.mac.com/vm_converter/mac_autoexec_vuln.html
   
   # あ。ヤベー（汗）。今気付いたんだけどBugtraqにvm_converter@mac.comで投稿しちゃった....。こっちのアドレスではsubscribeしてないんだった。うへぇ。ヘタレ過ぎ＞オレ。えーと....どうすっかな...（萎）
   
   
1. えーと。下の2/13分はつらっと書いてアップするの忘れてました。まぁ大した内容じゃないのでそのままにしておきます。
   
   

2002.02.13

4. ■ 先日、Free Designerz Circle (FDC) のオフ会に顔を出させて頂いたりして。いや一応わたくしDTPやってるフリーランスなので。デザイナーじゃないけど。って、その節は有り難うございました＞KOUJIさん＆わださん＆皆々様方
   で、何故かいらしていた、廃刊したMACLIFEに在ったapexの編集長の森さんと話し込んでしまったり。あぁ何故かって事はないですね。しかしやっぱアツいですね。森さん。無茶苦茶楽しく且つ有意義な一時でした。他の方々ともデザインとかDTPの話なんて全然しないで、Mac OS Xとかとかとかな話ばっかりしてましたが。
   
   # ○○さん。あまり英語版のドキュメントには期待しないでくださいね。
   
   
3. ■ あぁいや、だからそのスレに俺、vm_converterって名前で書き込んでるんだけど...。＞ 【速報】Mac版 IEにセキュリティホール【速報】の >>117 (2ch、新Mac板)
   いやまぁ、もう名前出さないとは思うけど。
   
   
2. ■ そういえば ■ を「まねっこ」されていたりして。＜セキュリティホール memoさん
   でも、私のは直接は pigmon.log(ぴぐもん録) さんの真似だったりして。●を■に変えるとゆー安易な。しかし手打ち＆コピペとゆーアナログな。せっかく mi 使ってるんだからマクロを組もうかと思いつつそのまんま。
   
   
1. ■ 2/3の1. で「2/11にはBugtraqへ投稿を行う」とか言ってましたがまだですね。はい。まぁ向こうの時間で2/11のつもりだったので2/12に送る予定だったのですが、まだですね。はい。まぁその内。自他共に色々有ったりして。
   
   

2002.02.08

5. ■ Auto file execution vulnerability in Mac OS の ◆重要度が高い必須の対処の内、
   • “QuickTime設定”コントロールパネルで [CD-ROMを自動的に再生する] をオフにする
   • Stuffit Expanderの [環境設定...] ＞ [ディスクイメージ] で [ディスクイメージをマウント] のチェックを外す
   の２項目で実際の設定画面を見られる様にしました。2/1の2. で太洋さんの所から直接引っ張った画像をまた利用させてもらっています。
   
   
4. ■ Auto file execution vulnerability in Mac OS の ◆必須ではないが有効な対処の内、Mac OS (インターネットコントロールパネル)：の部分を書き換えました。以前は [詳細設定] ＞ [ヘルパー] を変更する様に書いていましたが、これでは不十分でしたので [詳細設定] ＞ [ファイル対応] を変更する様に書き換えました。
   
   ちなみにこれはRayさんという方から頂いた情報です。有り難うございます。随分前にメールを頂いていたのに、掲載が遅れて済みませんでした。[ヘルパー] の方で行けると信じ込んでいたもので。ごめんなさい。
   
   もう一つRayさんからは、Stuffit Expanderの [環境設定...] ＞ [Internet Config] で 全てのチェックを外す”という情報を頂いているのですが、これを行っても例えばIEのファイルヘルパー設定の方が優先されてしまったりする事もあるようで、確実な事が言えないので掲載を控えております。
   # ちょっと検証が手に負えなくなってますね。ごめんなさい。
   
   
3. ■ 今、つら〜っとWebを巡回して気付いたんですが。下の (MS02-002) の件、私が見たMac系のサイトではほとんどが、英語版 (各国語版) か日本語版のアップデータ配布ページを直接紹介してるんですね。んー。確かにアップデータだけかましてりゃぁいーのかも知れませんが、この件は“MS02-002”つまりMicrosoftが「自社製品に見付かった2002年の２番目の脆弱性である」と定義し、その説明のドキュメントが既に有る訳ですから。先にそちらを紹介した方が良いんじゃないかと思う次第。
   あんまりこーゆー事書くとMacな方々から嫌われちゃうのかも知れないけど、ここらへんが2/3の1. で書いた「Macintoshのセキュリティ情報に関しては、Macintoshのコミュニティの情報伝播速度＆範囲は速くて広いが、情報の確度やS/N比に於いてセキュリティ関係者による伝達よりも劣る」と感じる由縁です。って、まぁ「Macintoshのコミュニティって何よ？」って話も有る訳ですが。
   
   まぁ“木を見て森を見ず”になりません様に、と思ったり。私はやっぱり「対処法だけ述べれば良い」という気にはなれないのです。
   
   話は跳ぶ様で実は跳ばないのですが“インフォームド・コンセント”つまり“説明を受けた上での同意”を受けてから治療なり施術なり何なりを行う事は、何も医療の世界だけじゃないと思うのですが。あぁでも、例え話ってのは往々にして情報を歪めちゃうから書かない方が良かったかな。
   
   
2. ■ Office v. X for Mac ユーザーの方は必ず目を通しましょう。＞ 不正なネットワーク リクエストにより Office v. X for Mac が異常終了する (MS02-002)
   “Network Product Identification (PID) Checker”というOffice の製品 IDチェック機能、つまり有り体に言えばコピー防止機能を経由して、Office v. X for Macにサービス拒否 (DoS) 攻撃をしかけられる、というもののようですね。是非リンク先のドキュメントをご確認下さい。日本語版修正プログラムも用意されています。
   
   もちろんさらに気になる方は、原文の Microsoft Security Bulletin MS01-002：Malformed Network Request can cause Office v. X for Mac to Fail も読まれた方が良いかと。
   
   でね。太洋さん。この件、Macintoshトラブルニュースさんも (もっと早く英語版の方で) 取り上げてる訳で、抜けてるのはマズイと思う訳です。＞ 太洋さんの日記 2002年 2月 06日『アンテナ』
   あと、Web Scripter's Meeting さんも是非加えといて下さいな。更に言えば、このページは“定期的”にMacのセキュリティ情報を追っかけるのには向いてないと思うけど。たまに番外編の時だけで良いんでないの。もし見て頂くとしても。
   
   追記　2002.02.08 20:00：太洋さんの日記 の『アンテナ』、追記して下さったようで。どうも。しかし太洋さんの日記はとっくに他の話題に移っていて「うらやましいなぁ」などと思ったり。これから英語圏に情報が伝わるのかと思うと「いつまで付き合うんだ。オレ。」などと思ったり。英語で質問のメールが来たらさすがに引いちゃうなぁ。などと。
   
   
1. ■ ずぅっっと前にご連絡頂いていて、不義理にも掲載していなかったものを一つ。
   ふりょさんという方のサイト RS WebPage の、2002年第4週の日記の2002/1/20(日)分に“ブラウザでの JavaScript の無限ループ問題についてサマリー”が載っています。「ブラウザの名称、バージョン。OS の名称、バージョン。無限ループが含まれた JavaScript を実行した際にどうなるかをまとめました。」との事。メーラとの組み合わせの検証として、Netscape 6.2とOutlook Express 5.5も載っておりますね。恥ずかしながら私もほんの少しだけ検証を手伝わせて頂きました。JavaScriptで無限ループさせると各ブラウザがどうなるか、について興味のある方は是非どうぞご覧下さい。
   
   あ。ちなみにふりょさん。「テストコードとしてはこれを用いました。」の“これ”ですけど、Mac OS版のIE 5.1.3 (とOpera 5.0とiCab 2.7) では見に行けませんでした。Mozilla 0.9.7で見れましたが。“view-source:http://〜”だからでしょうけれども。
   今私は、Mac OS用とMac OS X用ブラウザのほぼ全てを持ってますんで (笑) 。今度はもっと沢山のブラウザで検証に協力できるかも知れません。でも各ブラウザとかFTPクライアントとかの初期設定をデフォルトに戻したりカスタマイズしたりまた戻したりってのを延々と繰り返してたんで、一回クリーンインストールからし直したいってのが本音だったりしますが。
   
   それにしても掲載が遅くなりまして済みませんでした。＞ふりょさん
   忘れてた訳じゃないんですけどね。1/28あたりに「やっと一息つけたからサイト更新でもするか」ってなったら、あの脆弱性に当たっちゃったもんで。その後のドタバタの中で紹介すると埋もれちゃいそうで嫌だったんです。ごめんなさい。
   
   

2002.02.07

1. ■ 私事＆仕事の方も、今回の脆弱性の件もやっと一段落ついたので、ゆるゆると行きたいと思います。
   メールを頂きました方々、有り難うございました。これからお返事を書いていきます。済みません。
   
   officeさんのTea Room for ConferenceのNo.620にもコメントしなければいけないなぁなどと思いつつ。でも設定が元に戻ってからにさせて頂きますね。
   
   そうそう。このページ。１月分をずーっと引きずっていましたが、
   ○1月分＋2月分の2/5までを1月分としてバックナンバーへ
   ○1/28 以降をこのまま２月分として引きずる
   としました。まぁ1月分と2月分の両方に1/28 〜 2/5 までが入っているという事です。しかし1/29 〜1/31位までのページ内のリンクが“わや”になってしまってるんですよね。皆さんから頂いた情報を例の脆弱性の過去のドキュメントにリンクしていた部分なのに。済みませんです。余裕が出来たら整理しないといけませんね。整理した上で、まだちゃんと書き上げていない ■謝辞など の所に加えたいと思います。
   
   あ。でもあのドキュメントの英語版作んなきゃいけないんだった。んー....。

2002.02.05

1. ■ やっとドキュメントを一通りまとめ終わりまして、古いドキュメントと入れ替えました。↓
   2002.01.28 番外編：Auto file execution vulnerability in Mac OS
   
   今まで『Mac file execution vulnerability』という名前で公開してきたドキュメントを『Auto file execution vulnerability in Mac OS』としました。名前を変更したのは、Bugtraqで報告された Macinosh IE file execuion vulerabilityなどの検証の延長から発展したものだけれども、最終的に行き着いた“AutoStartを使った手法”はこのBugtraqの脆弱性を利用していない為、別種のものと考えたからです。実は、先日各ベンダーに送ったメールもこのタイトルで送っております。
   
   また長くなってしまったので恐縮なのですが、読み返して頂けたら幸いです。
   
   旧URLでも閲覧できますので現在既にリンクを張られている方はそのままで結構です。（だと思います。違ってたら速攻で直します）新しくリンクされる方は、http://homepage.mac.com/vm_converter/200202_diary.html#20020128_AutoStart_vulnでお願い致します。
   
   色々各方面にコメントしたいのですが、朝納期の仕事にまだ手を付けてないという....。今は12:00です....。
   
   

2002.02.03

1. ■ しばらく前に関係の有ると判断した各ベンダーに太洋さんと共同で報告を済ませました。報告したのは、apple.com, apple.co.jp, microsoft.com, microsoft.co.jp, aladdinsys.com, act2.co.jp, netscape.com, netscape.co.jp, mozilla.org, icab.de, omnigroup.com、です。報告の末尾に「既に日本語で情報公開をしてしまっている為、2/11にはBugtraqへ投稿を行う」との旨、付け加えてあります。
   
   ところで、この様に今回、本来であれば“各ベンダーに連絡を取り、対応を待ち、対応如何によってから情報公開する”という手順を踏むべき所を先に詳細まで情報公開してしまっている訳ですが、この件について数人の方から「先にベンダーに報告すべきだった」や「詳細を公開する必要が本当に有ったのか」や「現在あがっている情報から脆弱性の利用法については削除すべきでは」などといったご意見を頂いております。率直に言って「イタイ...」と思ってらっしゃる方もいるでしょうね。
   
   ちなみに脆弱性の報告や公開に関しては、日本語だと以下の２つのドキュメントを参照すべきかと。
   ○BUGTRAQ-JP: FAQ
   ○Shadow Penguin Securityさんに於ける『セキュリティホール情報の公開に関するガイドライン』
   読んで頂ければ解ると思いますが、前述の通り“各ベンダーに連絡を取り、対応を待ち、対応如何によってから情報公開する”というのが本来です。自分でそれを破っておきながら言うのも気が引けますが、皆様が脆弱性の報告や公開をなされる時は是非この２つを参考になさって下さい。
   # で、済みません。実は昨日初めて読みました。ごめんなさい。ごめんなさい。
   
   で、この様なご意見に対し、今は返す言葉がうまくまとまりません。済みません。「そうだよなぁ→んー→ (鬱) 」と「んーそうだったんだろうか→んー→でもうまく言えない→ (鬱) 」が自分の中で繰り返されている状態です。日頃、趣味とは言え、Bugtraqをはじめとするセキュリティの情報を取得しているくせに、なぜこの度先に公開してしまったのか。これはどうもうまく言えません。一言で言えば「先に公開すべきと判断したから」なのかもしれません。でもその様な明確な意志を持ってして行ったという訳でもないのですが...。
   今回の“ディスクイメージを使う手法”と“AutoStartを利用する方法”のそれぞれは、Mac OSやブラウザを初めとするネットワーククライアントや解凍ソフトが利便性を向上しようと希求した結果であり、それを便利と感じているユーザがいる以上（というかそれは確かに便利であり）、恐らく各ベンダーはその利便性を後退させる事には消極的でしょう。その利便性の後退もベンダーへの報告では要求してはおりますが。ってこれも先に公開した理由にはならないですね。んー。
   でも例えばブラウザからダウンロード機能が削除されたり、Stuffit Expanderで.sit.hqxなファイルを解凍しても.sitが出来るだけで完全な解凍までしてくれなくなったら、それはどうなんでしょう？　誰も使わなくなるでしょうね。そこまでの利便性の後退は要求していませんが。
   様々なユーザーに対し、本当に対処すべき事を伝えたり、何をどこまで利便性との秤にかけて自分の判断で対処してもらったり、というには、全ての段階に於いての対処を示す必要があり、全ての段階の対処は何に起因しているか知る為には全ての情報が必要なんじゃないか、とも思います。言ってしまえば「ベンダーの対応なんか実はどうでも良くて、自分や友人を含むわざわざMac OSなんてマイナーなOSを選択しているユーザーがこのままこのOSを使える様に早く教えてあげたかった（ってゆーか手元の設定で対処できるし）」という事なのかも知れません。
   それともう一つ、私は実はMacintoshのセキュリティ情報に関しては、セキュリティ情報のセキュリティ関係者による情報伝播速度＆範囲よりも、Macintoshのコミュニティに於けるそれの方が速くて広いと感じております。情報の確度やS/N比は前者の方が高いですが。って「ハァ？何言ってんの？」という感じでしかも喧嘩売ってるみたいですね。これじゃ。えーと、そのつもりは無いのですが....。私は今どちらにも知り合いがいて、どちらも好きですし。それにベンダー自身が情報公開すれば情報伝播速度＆範囲＆確度など全て上がるかもしれませんし。上がらないどころか公開もされないかもしれませんし。
   
   ですが、まぁ後先の問題はこれとは別ですね。色々な批判は甘んじて受け入れます。私に関しては。甘んじて受け入れれば脆弱性を勝手に公表して良い訳では無いのですが。んー。
   
   ただし、対処法のみを残して利用法の詳細な情報を削除するつもりはありません。頂いたご意見に対する太洋さんの見解『公開に踏み切った理由』が既に上がっておりますが、「この脆弱性に関しては、対処法を見るだけで、攻撃手法がバレバレになってしまう」に同意しているからです。太洋さんの意見に同意できる所と出来ない所とは有るのですが、この点に関しては同意です。また、概要のみにするつもりや全情報を削除するつもりもありません。後先を間違っておりますが、既に数千以上の人間が詳細までを目にしているからです。そうする位なら詳細な利用法を含んだ全情報を提示して「これこれこうだからこうなって、こうすれば良い」の方が理解しやすいと考えるからです。
   
   この件に関し、ご意見が有る方も是非vm_converter@mac.comまでどうぞ。恐らくすぐにはお返事できないかと思いますが。って、こんな長文書いてて言うのもアレなのですが。しかもまだきちんとした脆弱性のまとめ情報も作れていないのですが。んー。色々なご意見を参考にすると「じゃぁどうやってまとめるのがベストなんだろう？」ってのが解らなくて。脆弱性を探して検証して報告して応対して公開して....という方々ってすごいなぁと思う昨今です。
   
   って、読み返したら何言ってんだか良く解りませんね。でもこの混沌＆暗鬱が私の現状なのでそのまま上げておきます。あ。もちろんこれらは私の話ですので、太洋さんの見解は太洋さんの方を読んで下さい。＞『公開に踏み切った理由』
   
   あと一部で誤解がある様なので、一応書いておきますが、私は単なる一介のDTPオペレータです。もちろんこれを免罪符にするとかそういう事じゃないんですが。
   
   あと一つだけ疑問を呈してみます。“見付けた脆弱性への対処が、ベンダーによる対応よりもユーザー各個人での対応の方が好ましいと判断した場合、ベンダーに連絡を取るのが先であるべきなのかユーザーに伝えるのが先であるべきなのか”です。「それを判断するのは発見者じゃないんじゃないの？」という話も含めて。「当然ベンダーでしょ」から「すぐに教えて欲しい」からまぁ色々。どうしても私にはこの疑問が解消できません。いや、この話も含めての脆弱性の公表に関する帰結が先に挙げた２つなのでしょうけれども。「じゃぁ結論出てんじゃん」という風にどうも得心が行かないのです。はぁ。
   
   でも一気にまとまったドキュメントを提示できないなら、やはり公開すべきじゃなかったのかも知れませんね。どっちが後先とかとも更に関係なく。まとめます。はい。
   
   

2002.02.01

3. ■ 2chの新Mac板で良い事を言っていたので、引用します。今関わっている脆弱性は正にこの一言。

   ここを読むとこの問題はMacでインターネットをしてるユーザーに対する警告ということですな。

   「ここ」とは即ち太洋さんが更新した情報『【重要】MacOSにファイル実行の脆弱性』の事であり、この下の2. にソースごとコピペしている一つ下のの情報の事です。
   
   この脆弱性は始まりがIE 5.0に対するもので、その後、当方や太洋さんや皆様のお陰で影響の有るブラウザが特定されましたが、今現在太洋さんが提供している情報は全てのMac OS 及びMac OS X用のGUIで動くブラウザに影響があるだけでなく、FTPクライアントなどStuffit Expanderに処理を渡す多くのダウンロードツールにも影響が有る訳です。
   
   そして今現在はStuffit Expanderで使われるファイル形式を利用していますが、他の解凍ソフト、もしくはバイナリのまま落として実行できる形式も疑ってかかるべきなのでしょう。
   Mac OSの良さとして、昔からアプリケーションやOS、Finderの機能を組み合わせて使うというものが有りますが、今回はこれが完全に仇になっている訳です。
   自分が好んで使ってきて、つい数日前までは普及しているパソコン向けOSとしては最もネットワークセキュリティ的に安全であったろうMac OSの、皮を一枚一枚はいでいく作業は辛くもあり、怖くもあり、そして楽しくもあります。太洋さんも『なんで見つけちまったかな(TT)』で「というわけで、しばらくこいつにつきあうことになりそうです。」と述べておりますが、私もしばらく付き合う事になるでしょう。そして多くのMacユーザーがしばらく付き合う事になるのでしょうね。とりあえず月が変わったのにページを変えないでおりますが、しばらくこのページのカレンダーはめくれないでしょう。きっと。
   
   という訳で、今日明日をかけてドキュメントをしっかりまとめたいと思います。と、同時に何かしらの形でこの情報を日本ローカルでなく（この情報は今現在恐らく全く日本ローカルです）世界にいる多くのMacユーザーに届けていかなければならないのかも知れません。取りあえず昨日仕事で外出した際に英和・和英辞典は買ってきましたよ（笑）。
   
   と、同時に当然、各ベンダーにもね。＞Appleさんとりあえず“CD-ROMを自動的に再生する”はデフォルトでオフにして下さい。もしここを見ていたら。Mac OSはもうメンテしないとか言わない様に。Classic環境として使ってもダメなんだから。
   
   願わくばこの脆弱性が悪用されませんように。
   あ。だとしたら世界に伝えない方がいいのかな？（笑）
   
   
   
2. ■ 太洋さんが新しいexploitをアップしてくれました。そろそろ私と太洋さん２人でドキュメントを上げるのも限界を感じてきており、皆様も混乱されるでしょうから、太洋さんのものをそのままアップします。当然、本人の了承済みです。
   ------------------------------ここから-----------------------------
   「IEアプリ実行問題の実行環境　2002年 1月 28日」 で報告した脆弱性の中に、全く新しい脆弱性が潜んでいました。
   
   新たに発見した脆弱性は今まで報告してきたIE、iCabだけではなくすべてのブラウザで動作することが可能です。（ただし、Mozilla、Netscape6.xではダウンロード時にキャンセルを行うことで回避できます）
   
   【実行環境】
   実行環境を開く
   
   この脆弱性は、以下の条件が満たされたときに実行できます。
   ・QuickTime設定の「CD-ROMを自動的に再生する」がオン
   ・StuffitExpanderの「ディスクイメージのマウント」がオン
   ・StuffitExpanderの「解凍を継続する」がオン
   ・ブラウザでダウンロードが始まったときに、Stuffitへファイルを渡す設定になっている。
   ・OS 8.x〜-9.x、またはClassic環境が起動している（OS X環境でも動作する）
   
   【対処法】
   ・QuickTime設定の「CD-ROMを自動的に再生する」をオフにする[厳守]
   
   
   ・StuffitExpanderの「ディスクイメージのマウント」をオフにする
   
   
   ・StuffitExpanderの「解凍を継続する」がオフにする
   
   
   ・ブラウザでファイルのダウンロード制限、Stuffitへ渡さない設定を行う。
   IEではセキュリティゾーンでこの設定が可能です。
   iCabでは環境設定＞ダウンロード＞開始・後処理の「インターネットコントロールパネルの設定に従って処理」をオフにすることで可能です。
   
   
   【概要】
   概要を私がまとめると前回のように混乱を招く可能性があるので、必ず石川さんのページをごらんになってください。
   ■2002.01.28 番外編：Mac file execution vulnerability
   
   【コメント】
   前回の反省から、文章を簡潔にまとめましたが、少々書きます。
   このコメントは、私の見解を多分に含んでいますので、その旨了承ください。
   
   このセキュリティホールは、非常に、かなり、とても、ヤバイです。形容詞が四つしかないのは、私の語彙の問題ですってあんたライターもやってるだろこら
   対処法があるとはいえ、初期状態では全く無防備なMacが大量に存在しているはずです。
   
   とにかく、すべてのMacユーザーが対策を進めることを願っております。
   
   例によって、連絡はtaiyo@vinet.or.jpまたはBBSまで。
   ------------------------------ここまで------------------------------
   追伸＞皆様　太洋さんに情報を送る際、Ccでvm_converter@mac.comにも送ってもらえると助かります。
   
   
1. ■ 皆さん。2002.01.28 番外編：Mac IE file execution vulnerabilityの件、新しい利用法を太洋さんが見付けてしまいました....。もう一段進化しています....。取りあえず皆様、すっきりまとめる時間が無いので、とある方に書いたメールをそのまま2002.01.28 番外編：Mac IE file execution vulnerabilityに追記しておきます。ぜひ読んでください。既にIEやiCabだけの問題ではなくなっています。
   
   さらに悪い事態になっている事がお判り頂けるかと。全てはOSを含む各プログラムのデフォルト設定の不味さにあるのやもしれず。
   
   その内、太洋さんがまたexploitを公開してくれるでしょうから、その時はまたアップします。
   
   

2002.01.31

2. ■ 1/29の4. で触れた、Apple Roomさんの『●Internet Explorerの巨大なセキュリティホール（^^） 2002.1.28@640』への情報提供者であるえいはちさんからメールを頂きました。有り難うございます。以下に抜粋して引用します。ホントは全文にしたい所ですが。

   ・セキュリティーホールへのパッチ、またはアップデータが配付されるまではIEは4.5または4.51（以下IE4.5xと略）を使用する
   
   というものです（ただし4.50については一部サイトでの認証切れ問題が起こるため、マイクロソフトの「マックトピア」からパッチをダウンロードする必要があるかもしれません）。
   
   　というのも、「アップルルーム」への投稿にも書きましたが、IE4.5や4.51では指摘されているような問題が発生しないのです。太洋さんのページにあるJavaScriptON版では、Netscape Communicator 4.7xと同じように、ダウンロードそのものを許しません。バージョンダウンといっても、4.5xは5.x同様128bitで暗号化されているので安全（のはず）です。

   この、IE 4.5や4.51で大丈夫という件、実はApple Roomさんの記事を読んだ時点で気付いてました。が、このバージョンのIEにどんな脆弱性があったか私が覚えていなく、また調べる余裕もなかったので掲載していませんでした。ですが（私の中では一応という形で）対処法に追記しておきます。
   
   メールでのお返事はまた後で ＞ えいはちさん
   
   
1. 2002.01.28 番外編：Mac IE file execution vulnerabilityで情報を頂いているので、また更新したいと思います。
   
   しかし、そろそろもっと簡便にまとめないとなぁと思っております。さすがに読みにくくなってきましたので。
   でもそんな事より気になっているのは、この件、日本人それも多くはMacユーザーしか知らないんじゃないかという事。他の国の人はどうしてるんだろう？とか。どうしたもんかなぁなどと考えていますが。
   
   

2002.01.30

7. 一気にいくつも書きましたが、また更新を離れます。ごめんなさい。余裕無くて。
   まだ情報がありましたら、vm_converter@mac.comまでメールで教えて頂ければ幸いです。
   
   
6. ■ 西谷さんという方からMac OS X＋IE 5.1.3に関する情報を頂きました。有り難うございます。で、引用します。
   

   「Mac OS X 10.1.2＋IE 5.1.3日本語版＋Stuffit Expander 6.5.1英語版」で太洋さんのページの「IEアプリ実行問題の実行環境」を実行したところ、Stuffit Expanderの環境設定で[ディスクイメージをマウント] のチェックにより次のようになりました．
   
   チェックされていない・・・ダウンロードファイルが解凍されて止まる。
   チェックされている・・・・ダウンロードファイルの解凍後にDisk Copyが起動してイメージがマウントされる。その後は「ファイルが見つかりません」のアラートが出て止まる。
   
   このことから推察すると，イメージのマウントはMac OS 9.xかMac OS Xかを問わずStuffit Expanderの設定によって決まるのではないのでしょうか。

   との事。確かにStuffit形式やBinhex形式（MacBinary形式もかな？）になっているディスクイメージファイルを自動的に解凍→マウントするかどうかはStuffit Expanderに関わっているようですね。
   私の所ではMac OS XのStuffit Expanderをデフォルトで入ってままのを使っていたので気が付きませんでした。情報有り難うございます＞西谷さん。
   
   で、どこに情報を追記したものか迷いましたが、■Mac版IE 5.1.3およびその他のブラウザについてに追記しました。
   それから、対処法に関して“Stuffit Expanderのディスクイメージのマウントをオフにする”というのが、IEへの対処法に書いてあったのを、基本的だけど重要な対処法の所に移して、ちょこちょこ書き換えました。
   
   そろそろ全面的に整理し直した方が良いのかも知れませんね。問題の概要とすっきりした対処法だけのドキュメントを作るとか。んー。。。
   
   
5. ■ iCabの最新版であるPre2.71に於いても同様の脆弱性があるとの情報を、かんきちのタワゴトver5.33さんの掲示板で見ましたので、その情報を■Mac版IE 5.1.3およびその他のブラウザについてに追記しました
   
   
4. ■ これはメールでなくて、単に私が見ただけですが。T's iBook DualUSBさんの2002/01/28より引用しますが、
   

   問題の本質は、Refreshタグで指定パスのファイルが実行できること 、です。

   ん。その通りです。スパっと書いていらっしゃいますね。私もこう書ければといつも思います。
   でも検証してないので何とも言えないですが、もしかしてこの脆弱性ってRefreshとか使わないでも行けるんと違うか？とか思ったりもしています。で、もう一つ引用。

   しかし本質的な対策は、Refreshタグでファイルの起動ができるセキュリティホールを持つ、これらのブラウザを使うのを止めるべきです （少なくともパッチが出るまでは）。

   あぁ。これも言われてしまえばその通り。でも私はIE派だったりして。んー。どうしよう...。とゆー感じ。
   脆弱性を検証している本人がこんな事ではいけないと思いつつ、でもやっぱりIE以外を使うのは今はまだちょっと....な状態で。
   ただしiCabに関しては、セキュリティホールは持つものの、きちんとした対処をすれば
   
   一応、対処法に“これらのブラウザの使用を止める”旨追記しておきました。
   
   
3. ■ ぐるりさんからメールで情報提供頂いたのですが、太洋さんのexploitで使用されているAppleScirptについて。って私がココに書く事なのかどうかアレですけれども。太洋さんの作ったexploitで使われるAppleScirpt『openTrash』では

   tell application "Finder"
   	select trash
   	open selection
   	activate
   end tell

   となっている訳ですが、これを

   tell application "Finder"
   open trash
   activate
   end tell

   とすれば、Mac OS Xでも動くものになるというお話。
   直接この脆弱性を関係のある話では有りませんが、有り難うございました。
   また、ぐるりさんから可能性の話として、Mac OS X上のAppleScriptで

   do shell script plain text -- the command or shell script to execute.
   の方が恐いです。
   do shell script "sudo rm -rf /"
   とかやられて、思わず管理者password入力してしまったときのことを考えると...。

   との話が有りましたが、私も同感です。Mac OS Xの方がMac OSよりも自由度の高い面が多い訳で、まぁリモートの穴が見付かった時の被害は大きいだろうなぁなどと思っております。
   
   ちなみにぐるりさんと言えば。Mac OSメール環境（OME）ですね (^^) 。初めてOMEから出されたメールを受け取ったのでした。
   
   
2. ■ が。まず先に。 Easy Packageの閉鎖のお知らせ を。
   おおおおお。何も貢献していない私には何も言えませんが...。お疲れ様でした＆有り難うございました＆お世話になりました。
   ネタ元は、田中 俊光さんのサイトの 覚え書き（のつもり）● 2002/01/30、からでした。
   
   
1. とか言って、こんな時間になってしまいましたが。
   幾つか2002.01.28 番外編：Mac IE file execution vulnerabilityで情報を頂いているので、更新したいと思います。
   
   昨日のリンクURL取得用の■、全部28日になってましたね。ごめんなさい。テンパってたもんで気付きませんでした。
   
   

2002.01.29

6. ■ また追記です。今度は、■Mac版IE 5.1.3およびその他のブラウザについてに追記しました。
   memo MLの [memo:2782] Re: Mac IE file exec vuln in IE 5.1.3 で、この件について篠田さんという方がさらに多くのブラウザについて追試して下さった結果を投稿されていましたので、それに関してです。
   
   で、ホントごめんなさい。しばらく（恐らく夜まで）更新が止まります。
   
   
5. ■ また対処法に追記です。
   あるけみすと＠Digitalians' Alchemy さんにご指摘頂いたんですが、“Macintosh HD を他の名前に変える”というこの脆弱性の本質に対する基本中の基本について書いてませんでした (汗) 。
   同じ意味で、ブラウザのダウンロード先を“デフォルトのDesktop Folderから変更する”ってのも重要ですね。
   
   という訳で併せて追記してさらに「IEとiCabでの対処法」としていたのを単に「対処法」と変更しておきました。
   ってゆーか、この２つ変えるのが自分の中でデフォルトになってたんで、すっかり失念してました。済みません。
   
   後は、Stuffit形式やBinhex形式などStuffit Expanderに渡される形式以外に自動解凍や自動実行されるものがあるかとか、ファイルなどの操作法としてAppleScript以外にも有るんじゃないかとか、フォルダアクションってどうなのよ？とか、とかとか....。んー。
   余りに気にしなきゃいけない事が多すぎて既にパンクしてますので、vm_converter@mac.comまでメールで突っ込んで頂ければ幸いです。あ。太洋さんの所でも構わないですけどね。すぐ私にも伝わりますから。
   
   # ってゆーか。そろそろマジで仕事戻らんとヤバげだよね。オレら。＞太洋さん
   # しかし、自分の流した情報のケツまで持つのってホント大変ですねぇ。
   
   
4. ■ IEとiCabでの対処法に、さらに追記しました
   ってゆーか書いちゃうと、IEのセキュリティゾーン設定で“高”にするとか“カスタム”にして [ファイルのダウンロード] を“無効”にするというものです。
   これすると、IEでファイルのダウンロードが出来なくなっちゃいますけどね。
   
   あ。この件はApple Roomさんの『●Internet Explorerの巨大なセキュリティホール（^^） 2002.1.28@640』を見て知った、とゆーか失念してたのを思い出したとゆーか。有り難うございます。＞Apple Roomさん及び投稿者のえいはちさん
   
   
3. ■ 太洋さんが同じ日記上（『IEアプリ実行問題の実行環境　2002年 1月 28日』）において、JavaScriptオフでも動作する方法を提供されていますね。こんどはフレームを使っていますね。
   # じゃ、仕事戻るから後よろしくね。＞太洋さん
   # ってゆーかホラ。ここより君の所に流れてる方が多そうだし。
   
   
2. ■ すみません。2002.01.28 番外編：Mac IE file execution vulnerability の件、騒がすだけ騒がせておいて実は対処法についてまるっきり述べてませんでした。
   いや、テンパってたものでごめんなさい。太洋さんが元々挙げていた ＆ 私の考えた ＆ Rjさんとの検証結果による ＆ iCabを極めるの掲示板のiCabにセキュリティホール！？というスレッドを見て知った、IEとiCabでの対処法について追記しました。
   
   
1. 基本的に昨日の続きです。

2002.01.28

1. ■ 相変わらず忙しくて余裕は無いのですが、想定される被害が余りにも大きそうなので番外編を一つ。
   ってか、ヤバイす。これ。急いでるんで乱文乱筆失礼をば。
   ってか再開したと思ったら、こんな超弩級ホールかよ。みたいな。
   以下の情報を既に知ってる方でも、タルくても最後まで読むのがお勧めですよん。
   

■2002.01.28 番外編：
Auto file execution vulnerability in Mac OS

■この脆弱性の概要

1. Webブラウザが“悪意のあるプログラムを内包したStuffit形式などで圧縮されたディスクイメージ”のダウンロードを自動的に始めてしまい、
2. ダウンロード後に、Stuffit Expanderに処理が渡される事で、自動的に解凍された上で自動的にディスクイメージがマウントされ、
3. Mac OSの機能 (QuickTimeがCD-ROMなどを自動再生する機能) により、マウントされたディスクイメージ内の悪意のあるプログラムが自動実行される。

■この脆弱性の詳細

●基になった脆弱性その1：Macinosh IE file execuion vulerability

●基になった脆弱性その2：METAタグによる強制ダウンロード

●基になった脆弱性その3：ディスクイメージの利用による任意のプログラムの実行

●Auto file execution vulnerability in Mac OS（AutoStartを使った手法）

1. 自動実行される様に設定したプログラムを内包したディスクイメージを作成する。
2. 作ったイメージをStuffit形式 (以下 *.sit) にしてアップロードする (もしくはBinhexやMacBinary) 。
3. “その2”の脆弱性を利用したWebページを作成する。
4. WebブラウザでそのWebページが閲覧されると“その2”により、強制的にダウンロードが始まる。
5. ダウンロード後にStuffit Expanderに処理が渡され、自動的に解凍された後ディスクイメージが自動的にマウントされる。
6. ディスクイメージ内のプログラムがQuickTimeのCD-ROMの自動実行機能により実行される。

• FetchによるStuffit形式のファイル処理サポートが、バージョン1.1.1???からで19??年リリース
  （バージョン3.0.3英語版のFetch HelpのRelease Notesを参照。3.0.3のリリースは1997年）
• QuickTimeによるCD-ROMの自動実行機能のサポートがバージョン2.0からで、2.0は1994年発表
  （98/6/4 Macintosh トラブル Date Archives (Macintosh トラブルニュース (Macintosh News)) およびアップル年譜 (m2zakiのHomePage) の２つを参照）
• Stuffit Expanderによるディスクイメージファイルのサポートがバージョン5.0からで1998年リリース
  （act2製品 対応OS表を参照）

◆この脆弱性の影響が有る環境

○Mac OS 8.x 〜 Mac OS 9.2.2（恐らく漢字Talk 7.5.x (System 7.5.x) 以降全てかも知れません）

○Mac OS X をClassic環境と併用して使った場合^*1（手元では10.1.2＋9.2.2の組み合わせのみ検証）

○恐らくQuickTime 2.0以降全てのバージョン (手元の検証ではJ-5.0.2を使用)

○Stuffit Expander 5.x 〜 6.5.1 for Mac OS

○Stuffit Expander 6.5 〜 6.5.1 for Mac OS X^*2

○“脆弱性その2”に影響が有るブラウザ の内、ファイルダウンロードの後処理をStuffit Expanderに渡すもの^*3

○同様に、ファイルダウンロードの後処理をStuffit Expanderに渡す全てのMac用ネットワーククライアント ^*4

*1：Mac OS Xを単体で使っている際は影響が有りません。CD-ROMの自動実行機能がONになっているClassicを起動すると影響が出ます。

*2：現行のMac OS Xに付属のStuffit Expander 6.0.1 for Mac OS X には自動マウント機能が無い為、この脆弱性の影響を受けません。

*3：OmniWebでは4.1 beta 11で影響が有る事を確認しましたが、4.0.6ではStuffit Expanderに処理が渡らない為大丈夫な様です。ただし4.0.6でもダウンロードは始まります。

*4：手元の検証では、Mac OS 9.2.2上でFetch 3.0.3、NetFinder v2.3.1、Vicomsoft FTP Client 3.0.1に於いて手動でFTPダウンロードした際に影響が有る事を確認しています。Mac OS XのClassic環境で使用した場合の影響は検証し切れておりません。

■これらの脆弱性への対処

• “QuickTime設定”コントロールパネルで [CD-ROMを自動的に再生する] をオフにする → こちらで実際の設定画面をご覧下さい
  （Auto file execution vulnerability in Mac OS への対処です）
• Stuffit Expanderの [環境設定...] ＞ [ディスクイメージ] で [ディスクイメージをマウント] のチェックを外す → こちらで実際の設定画面をご覧下さい
  （Auto file execution vulnerability in Mac OS と“脆弱性その3”への対処です）
• ハードディスクやボリュームなどを“Macintosh HD”や“名称未設定”などの初期状態の名称から変更しておく
  （“脆弱性その1”への対処です）
• Webブラウザの初期状態のダウンロード先を変更しておく（“脆弱性その1”への対処です）
  以下、各ブラウザでの変更方法。
  
  • Internet Explorer：[初期設定...] ＞ [受信ファイル] ＞ [ダウンロードのオプション] ＞ [ダウンロードフォルダ] で変更
  • Netscape Communicator 4.x：[設定...] ＞ [Navigator] ＞ [アプリケーション] ＞ [ファイルのダウンロード先] で変更
  • Netscape 6.x：ダウンロードのダイアログで毎回設定するのでデフォルトの場所は有りません^*1。
  • Mozilla：ダウンロードのダイアログで毎回設定するのでデフォルトの場所は有りません^*1。
    *1：既にダウンロード開始時のダイアログで [このファイルを開く前にメッセージを表示する] のチェックを外して [OK] してしまっていた場合にはダイアログが表示されない場合が有ります。その場合は [設定...] ＞ [Navigator] ＞ [サポートアプリケーション] ＞ [ファイルを開く] でリセットボタンを押してください。
  • iCab：[環境設定...] ＞ [ダウンロード] ＞ [初期設定] ＞ [保存場所とパスの階層] ＞ [ダウンロードフォルダ] で変更
  • Opera：手元にあるPPC版5.0b4.411では変更方法が解りませんでした。（[Preferences...] ＞ [Folders and Apps] ＞ [Download Files to] にそれらしきものがありますが、変更のボタンを押しても何もできません）
  • OmniWeb：[Preferences...] ＞ [Downloads] ＞ [Download folder] で変更。
    
• Mac OS X を使う場合、ファイルのダウンロード先としてユーザーのホームディレクトリを使わない様にする
  

• Stuffit Expander：
  • [環境設定...] ＞ [解凍] で [解凍を継続 (可能な場合) ] のチェックを外す
    （Stuffit形式で圧縮されたディスクイメージファイルのマウントもこのチェックを外すだけでできなくなりますが、.sit.hqxの様な二重に圧縮されたファイルを一気に解凍する事はできなくなります）
  • [環境設定...] ＞ [保存先] で [その都度指定 ] を選択する
    （解凍の度に保存先を聞かれるので、ダウンロード後に意図しない解凍処理が始まってもキャンセルする事が出来ます）
  
  
• Mac OS (インターネットコントロールパネル)：幾つかアプリケーションがこのコントロールパネルのヘルパー設定を使用して、ファイルダウンロード後の処理をStuffit Expanderに渡しているのでそれを変更します。
  • ファイルダウンロード後の処理をStuffit Expanderに渡さない様にする
    [コントロールパネル] ＞ [インターネット] ＞ [詳細設定] ＞ [ファイル対応] でStuffit Expanderを使う様になっている設定を選択し、[変更...] ＞ [詳細オプションの表示] ＞ [動作：] で [アプリケーションを開く] から [ファイルに保存] に変更します。[ファイル対応] の所でアプリケーション順に並べるとどのファイルがStuffit Expanderで処理されるかが解ります。
  
  
• Internet Explorer：
  • ファイルダウンロード後の処理をStuffit Expanderに渡さない様にする
    [初期設定...] ＞ [受信ファイル] ＞ [ファイルヘルパー] で、Stuffit Expanderに関連づけられているファイルタイプの設定を解除する。アプリケーション順に並べるとどのファイルがStuffit Expanderで処理されるかが解ります。編集方法は、各項目を選択し、[変更...] ＞ [ファイルヘルパーの編集] ダイアログ上で、[処理方法] を [アプリケーションで後から処理する] から [ファイルに保存する] に変更。（圧縮ファイルをダウンロードしても、Stuffit Expanderで処理されず、ディスクへのダウンロードのみ行われます）
  • ファイルのダウンロードが行われない様にする
    [初期設定...] ＞ [セキュリティゾーン] で、設定を [ 高（最も安全）] にするか、[カスタム] にして [ファイルのダウンロード] を [無効] にする 。 (ただし一切のダウンロードが出来なくなります)
    
    ※ここに過去に載っていた対処法に“IE 4.5を使用する”というのが有りましたが、IE 4.5でもAuto file execution vulnerability in Mac OS の影響を受ける事が解っております。
    ※“脆弱性その1”つまり既知のパスの既知のファイルを実行される件に対する有効な対処法は有りません。セキュリティゾーン設定の [アプリケーションとファイルの起動] は無視されます。
  
  
• Netscape Communicator 4.x：
  • ファイルダウンロード後の処理をStuffit Expanderに渡さない様にする
    [設定...] ＞ [Navigator] ＞ [アプリケーション] にて、Stuffit Expanderに関連づけられているファイル形式の処理方法を、[ディスクに保存] に変更する。または [未定義：プロンプトを表示] に変更し、ダウンロード時に現れるダイアログで [保存する] を選択する。 （圧縮ファイルをダウンロードしても、Stuffit Expanderで処理されず、ディスクへのダウンロードのみ行われます）
    
    ※“脆弱性その2”つまりWebページを見ただけで強制的にダウンロードが始まってしまう件へには、恐らく有効な対処法は有りません 。(ダウンロードを阻止する設定を見付けられませんでした)
  
  
• Netscape 6.x：既に◆重要度が高い必須の対処で述べた様に、意図しないダウンロードが始まったらダイアログでキャンセルして下さい。そうすればここで述べた全ての脆弱性の影響を受けません。（ただし手動でダウンロードを開始した場合は別です）また、既にサポートアプリケーションの設定でStuffit Expanderへの関連づけを行っている場合は削除をします。
  
  
• Mozilla：既に◆重要度が高い必須の対処で述べた様に、意図しないダウンロードが始まったらダイアログでキャンセルして下さい。そうすればここで述べた全ての脆弱性の影響を受けません。（ただし手動でダウンロードを開始した場合は別です）また、既に Helper Applications の設定でStuffit Expanderへの関連づけを行っている場合は削除をします。
  
  
• iCab：
  • “脆弱性その1”と“その3”で利用されるWebページのMETAタグによるプログラムの起動を阻止する
    [環境設定] ＞ [特別] ＞ [セキュリティ] ＞ [HTMLリンクによるプログラムの起動] を [許可しない] か [常に訊ねる] に変更する
  • ファイルダウンロード後の処理をStuffit Expanderに渡さない様にする
    [環境設定...] ＞ [ダウンロード] ＞ [開始・後処理] ＞ [ダウンロード後...] で、[インターネットコントロールパネルの設定に従って後処理] のチェックを外した上で、Mac OS のインターネットコントロールパネルの設定を変更する。
    
    ※“脆弱性その2”つまりWebページを見ただけで強制的にダウンロードが始まってしまう件へには、恐らく有効な対処法は有りません 。[ダウンロード開始] の [起動時] と [オンライン移行時] の両方を [開始しない] にしても無視されます。
  
  
• Opera：Operaもダウンロード開始時にはダイアログを表示しますが、Stopボタンを押すのが間に合わなかった場合にはダウンロードが始まりプログラムが実行されてしまいます。Operaでの対処法は現在よく判っておりません。
  ※“脆弱性その2”つまりWebページを見ただけで強制的にダウンロードが始まってしまう件へには、恐らく有効な対処法は有りません 。(ダウンロードを阻止する設定を見付けられませんでした)
  
  
• OmniWeb：
  • バージョン4.0.6を使う
    手元の検証では、OmniWeb 4.0.6では“脆弱性その2”によりダウンロードは始まりますが、Stuffit Expanderに処理を渡さないようです。4.1 beta 1では脆弱性の影響を受けます。
  • 影響を受けるOmniWeb 4.1 beta 1もダウンロード開始時にはダイアログを表示しますが、Stopボタンを押すのが間に合わなかった場合にはダウンロードが始まりプログラムが実行されてしまいます。OmniWeb 4.1 beta 1での対処法は現在よく判っておりません。
  
  
• 各種ネットワーククライアント：“脆弱性その2”の影響を受けないので強制的に自動ダウンロードが始まる事は有りません。手動でダウンロードした場合に影響が有ります。ただし、これらをMac OS XのClassic環境で使用した場合の影響は検証し切れておりません。以下、Fetch 3.0.3の英語版を例にして、ファイルダウンロード後の処理をStuffit Expanderに渡さない様にする方法です。
  • Fetch 3.03：
    • ファイルダウンロード後の処理をStuffit Expanderに渡さない様にする
      [Custromize] メニュー ＞ [Post-Processing] で [Opening Application] がStuffit Expanderであるものを削除します。

■各ベンダーの対応状況

■謝辞など