TidBITS: Apple News for the Rest of Us  TidBITS#731/24-May-04

今週話題になったセキュリティの脆弱性は本物で、Mac OS X の核心に触れるものでもある。Adam がこの問題を検討し、自分の身を守るにはどうすればよいかを説明する。また、Matt Neuburg がこの問題の起こった原因を分析する。Joe Kissell は Apple Mail のスパムフィルタについて解説する。これは彼の新刊の電子ブック、“Take Control of Spam with Apple Mail”の内容の一部を紹介したものだ。Adam のもう一つの記事では、Mac をインターネットの額縁に変えてくれるプログラム、Envision を紹介する。ニュースの部では、Apple 社内のちょっとした配置替えと、Office 2004 と SubEthaEdit 2.0 のリリースをお知らせする。最後に、来週は休刊です!

記事:

Copyright 2005 TidBITS: Reuse governed by Creative Commons license
<http://www.tidbits.com/terms/> Contact: <[email protected]>


本号の TidBITS のスポンサーは:


MailBITS/24-May-04

31-May-04 の TidBITS 号は休刊 -- 今週のこの特大号の後、合衆国の Memorial Day の祝日に合わせて一週間のお休みを頂く。またこの週は主任編集者の Jeff Carlson の誕生日にも当たっており、私も MacDesign カンファレンスに出席する予定だ。TidBITS Talk はいつも通り変わらずに続けるし、またどうしても延ばせない緊急ニュースについては私たちのホームページにご注意あれ。(私たちとしては退屈な二週間が続く方が有難いが。)それでは 2003 年 6 月 7 日の次号でお目にかかりたい。[ACE](永田)

<http://www.macdesignconference.com/>
<http://www.tidbits.com/>

Microsoft Office 2004 出荷 -- Microsoft が公式に Office 2004 for Mac OS X をリリースした。これは殆ど普遍的に存在している生産ツール・スイートの、大幅な改訂版だ。今後私たちが実際にこのソフトウェアを受け取って、Word、Entourage、Excel、それに PowerPoint の各プログラムごとに追加された新機能や修正されたバグなどを調べ、それだけの価値があるかどうかを評価してから、それぞれの変更点などについて詳しく報告して行きたいと思う。現時点で言えるのは、購入価格が $400(定価)あるいは $150(教育用)でアップグレード価格が $240 だということだ。フル・スイートを購入したくない人は個別の製品の購入もできる。また、試用版 (186 MB) のダウンロードもでき、これは 30 日間のみ動作する。忘れないで頂きたいのは、 Office 2004 が Mac OS X 10.2.8 またはそれ以降を必要とすることだ。[TJE] (永田)

<http://www.microsoft.com/mac/products/office2004/office2004.aspx>
<http://www.microsoft.com/mac/products/office2004/howtobuy/howtobuy.aspx>
<http://www.microsoft.com/mac/default.aspx?pid=office2004td>

SubEthaEdit 2.0 でコラボレーションを磨く -- Coding Monkeys から SubEthaEdit のバージョン 2.0 がリリースされた。これは同社のユニークなリアルタイムの協同作業用テキストエディタだ。今回のリリースではいくつかの新しい編集機能が追加された。例えば正規表現ベースの検索・置換、テキストの自動補完、分割ウィンドウ表示、改行コードの自動変換、読み込み専用アクセス、などだ。また、Rendezvous を使って他の人々をあなたのローカルネットワークに招き入れ、書類を共有することもできるようになった。開発者向けの機能としては AppleScript や ActionScript のシンタックス・ハイライトや、モード別の環境設定などがある。SubEthaEdit 2.0 はバージョン 1.0 と互換でないので、協同作業する人たちすべてが最新バージョンを走らせていなければ書類を共有できない。このプログラムは 1.2 MB のダウンロードで、非商業用の利用ならば無料、商用ライセンスの価格は $35 となっている。[JLC](永田)

<http://www.codingmonkeys.de/subethaedit/>

Apple が新たに iPod 部門を創設 -- このデジタル音楽プレイヤーがいかに Apple の基盤を支える重要な存在であるかを反映しているのだろう、同社は副社長の Jon Rubinstein が率いる独立の iPod 部門を新たに発足させた。同氏はこれまで Apple のハードウェア開発を統括してきた。これと同時に独立の Macintosh 部門も創設され、こちらは現在ワールドワイド・セールス及びオペレーション責任者の Tim Cook が舵取りの役に就くことになる。この人事異動をめぐって大袈裟に騒ぎ立てようという向きもあるようだが、私たちの見るところこれは単に Apple の市場動向の現実を反映した普通の社内再編成に過ぎないように思われる。[JLC](永田)

<http://www.reuters.com/newsArticle.jhtml?type=topNews&storyID=5198496>


Apple Mailのスパムフィルタを知る

文: Joe Kissell <[email protected]>
訳: 古川敬章 <tac@mac.com>

Apple Mailのほとんどのユーザと同じように、私はPantherへの乗り換えのメリットと噂された、新しい迷惑メールフィルタが広告通りに良いものであることを大きく期待していた。何ヶ月もフィルタに地道に学習させたが、今でもその結果には満足しているとはいえない。Appleの掲示板を読んだところ、それは私だけの話ではないようだ。スパム退治をあきらめる(か、Mail以外のメールソフトに切り替える)代わりに、私は問題をより詳しく見てみることにした。私の手元に集まった何千ものスパムメールを武器に実験し、フィルタの動作のしくみの実際と、なぜそれは時々壊れるのかを調べた。すると、少なくとも問題の一部は、他のApple製アプリケーションに比べて、この Mail というアプリケーションには一目では使い方がわからないところもある。

いいニュースと悪いニュースがある。いいニュースは、Mailの迷惑メールフィルタは適切に設定すれば、あなたの受信箱にスパムを寄せつけないための頼れるツールになることだ。悪いニュースは、迷惑メールフィルタが最高にうまく動いていてもなお、不要なスパムメールは完全に退治できないことだ。幸い、他のアプリケーションやテクニックでフィルタの欠点を補うことができる。背後にある仕組みがわかれば、迷惑メールフィルタをより上手く使ったり、補ったりすることができるようになる。

私の時間をかけた研究と実験の結晶はTake Control電子ブック、“Take Control of Spam with Apple Mail”に収めてある。この記事はそれからの抜粋である。

<http://www.tidbits.com/takecontrol/spam-Apple-Mail.html>

Mailの迷惑メールフィルタの仕組み -- Mailの迷惑メールフィルタには2つのモードがある。トレーニングモードと自動モードだ(完全にオフにすることもできる)。初心者はこの2つのモードで何がなされるか混乱しているかもしれない。実際、自動モードに切り替えてもフィルタの学習機能が働き続けるのかどうか疑問に思う人が多い。(Appleのドキュメントではあいまいにされているが、自動モードでも学習機能は動く。) では、順に詳しく説明してみよう。

新着メールが来ると、Mailはルールリストには現れない、内蔵のルールを適用する。通常メールが迷惑メールと間違われないために、この特別なルールは他のすべてのルールよりも後に適用される。ただし、他のルールの一つがアクション“Stop evaluating rules”を含んでいるときは動かない。また、すでに他のルールによって移動や削除がされていないメールにのみ適用される。

環境設定の「迷惑メール」ペインを開いて「詳細...」をクリックすれば、迷惑メール用の特別ルールを見ることができる。オプションの選び方によって、送信者が過去の受信者リストやアドレスブックに含まれているか、また宛先フィールドにあなたのフルネームが含まれているか(スパムは普通含まないので)をチェックできる。(過去の受信者リストは迷惑メールフィルタの便利な付加機能だ。もっとも、電子ブックで私が詳細に説明しているように、間違ったデータが入り交じり逆効果になりやすいが。)これらの質問のどれかの答えがイエスならば、フィルタは停止してメールは手つかずになる。だがもし3つの条件のどれにも当てはまらない場合は、最後の条件である「メッセージは迷惑メール」がチェックされる。この条件にも引っかかれば、フィルタはあなたの指定したアクションを実行する:トレーニングモードでは、メッセージの件名の色が茶色になる。自動モードでは、メールが「迷惑メール」メールボックスに移動される。(このアクションは両モードの2つしかない違いの一つだ。もう一つの違いは、自動モードではすべてのアカウントの迷惑メール用メールボックスがメールボックスリストの一つのアイコンになることだ。)

「メッセージは迷惑メール」という条件はよくわからない名前だが、もし条件に合うときは、Mailの潜在意味解析フィルタ(後述)がその任意のスパムの基準を上回ったことになる。この境界値は変更できないが、後でユーザがメールを「迷惑メールでない」とマークすると、Mailがそれのメールと似たメールがスパムと解釈される可能性が下がる。

Panther版のMailではスパムのチェックにまた新たな条件が加わった:接続プロバイダのメールサーバーのスパムフィルタによって挿入されるヘッダだ。多くのプロバイダはSpamAssassinやBrightmailなどのサーバーサイドのスパムフィルタを使用している。そのようなフィルタがメッセージをスパムの可能性があると判断した場合、例えばX-Spam-Flagなどの特別なヘッダで印を付ける。(これらの特別なヘッダは通常表示されないが、表示> メッセージ > 全てのヘッダ を選ぶと表示できる[コマンド-シフト-H]。)

メールにこのヘッダが含まれていると、プロバイダのスパムフィルタ(Mailに内蔵ものよりも高度かもしれない)がそのメールをスパムと疑っている。「インターネットサービスプロバイダが設定した迷惑メールヘッダを信頼する」チェックボックスがオンになっている限り、Mailはそういったメールを迷惑メールとしてマークする。(ただし、アドレスブック内の誰かから送られたものだったりその他の理由で除外された場合を除く。)サーバーサイドのスパムフィルタの中には、スパムの目印にX-Spam-Flag以外のヘッダを使うものもある。Mailに他のヘッダを認識させるには、設定ファイルを直接編集するほかない。電子ブックではその方法を全て説明した。

統計的フィルタリングについて -- スパムは着実に増え続けているので、固定のキーワード、パターン、ルールなどに基づいてメッセージをはじくフィルタは次第に効果が薄れていく。統計的フィルタは、メールを処理するごとにいわば独自のルールを生成する。最もよく使われている統計的スパムフィルタの方式は、ベイズ式フィルタ(Eudora, SpamSieve, SpamAssassinなどで使用されている)である。

Apple Mailではこれに関連した適応的潜在意味解析(LSA)という方法を用いている。どちらの方法も、与えられたメールがスパムである確率を、すでにあるスパムメールと非スパムメールの内容の解析に基づいて計算する。またどちらも新しい「良い」あるいは「悪い」メッセージのサンプルにあたるごとにより正確になる。ユーザの視点から見ればベイズ式フィルタとLSAフィルタは似ているが、いくつか重要な違いがある。

ベイズ式フィルタ -- 話を思い切り単純にして言うと、ベイズ式フィルタは主に2つのリストからなっている:「良い単語リスト」と「悪い単語リスト」だ。ユーザが使うごとに、リストは動的に作られていく。メッセージを迷惑メールだと指定するごとに、フィルタはメッセージ内のすべての単語を「悪い単語リスト」に加える。メッセージが通常メールだと指定すると、そのたびすべての単語が「良い単語リスト」に加えられる。もちろんほとんどの単語は両方のリストに現れることになるので、フィルタはそれぞれの単語がスパムのキーワードである確率を、「良い」メッセージと「悪い」メッセージに現れた割合に基づいて計算する。

新着メールが届くと、フィルタはそのメールの内容の平均スパムスコアを計算し、もしそれがあらかじめ決まった境界値を超えていると、そのメールはスパムと見なされる。ベイズ式フィルタは非常に動的で、個人個人の受け取るメールに適応する(ある人にとってのスパムが他の人にはハム、ということもあるからだ)だけでなく、スパマーの戦略の変化にも適応する。このシステムは完璧ではないが、来月、火星の不動産のセールスの新手の詐欺がはびこっても、手動でいくつかのメールをスパムとマークすればベイズ式フィルタはそういったメールを拒絶するようになる。ほとんどのベイズ式フィルタはメールのヘッダや他の属性を考慮して、長い(しかし隠された)普通の文を含んだメールにだまされないようにしている。

Mailの潜在意味解析 -- ベイズ式フィルタが比較的単純な単語の登場回数計算に基づいているのに対し、LSAフィルタ(潜在意味解析フィルタ)ではさらに、すでにスパムと認識されたテキストとの意味の類似性に基づいて「スパムらしい」単語や言い回し、メッセージを特定する。LSAフィルタは個々の単語にスコアを割り当てるのではなく、単語の出てくる全体的な文脈を考慮に入れる。例えば、“enlargement”という言葉は写真に関する話題に出てくる場合は通常スパムのキーワードではないが、整形手術や安く手に入る処方薬などの文脈ではスパムのよい手がかりだろう。(もう一度言うが、これは話を単純にしたものである。LSAについての詳細は、MacDevCenterにあるFrancois Joseph de Kermadecの3部書の2巻目“The Fight Against Spam”を見てほしい。)

<http://www.macdevcenter.com/pub/a/mac/2004/05/18/spam_pt2.html>

ベイズ式フィルタと同じように、LSAフィルタは使うにつれ学習していく。ただし、ユーザが地道に間違いを正し続ければの話である。Mailでは、フィルタが認識しそこなったスパムメールを全て迷惑メールとしてマークし、間違って迷惑メールとされた普通のメールを「迷惑メールではない」としてマークすることになる。

論文では、LSAはずる賢いスパマーに巻かれない、もっと洗練されたテクニックに見える。しかし実際には、MailのLSAの実装はまだ改善の余地がある。私自身がテストしたところでは、ベイズ式フィルタよりも学習速度が遅かった。スパムでないものをスパムと間違って認識する傾向があり、どこまでをスパムとするかの境界を調整することもできない。また、文字のパターンでなく単語のパターンを探すので、見るからに明らかなスパムのメッセージが検出されずに残ってしまう。

Mailは「良い」メッセージと「悪い」メッセージの特徴の統計を~/Library/Mail/LSMMap2という1つのファイルに記録している。ところで参考までにLSMとは、“least square method”(最小2乗法、LSAに使用されている数学的アルゴリズム)の略である。このファイルが破損すると(残念ながら破損しやすい)、迷惑メールフィルタは正しく機能しなくなる。

LSMMap2ファイルは修復できないが、手動で削除するかMailの迷惑メールフィルタの環境設定にあるボタンでリセットすることができる。これで迷惑メール関連の最も深刻なたぐいの問題は解決するが、それまでのフィルタの学習内容は失われるので、新しく迷惑メール/通常メールの区別を十分に行ってデータベースが再構築されるまでは正確さが落ちる。

Mailの迷惑メールの統計ファイルはそもそもどうして壊れるのだろうか。ファイルが開いたままクラッシュしたとか、不適切に電源を落としたといった事以外にも、メッセージをフォルダに入れたり迷惑メールとしてマークするなどの普通の操作でも、メッセージ自身に何かおかしい部分が含まれているとLSMMap2ファイルを損傷することがある。損傷が起こるのは防げないが、回復をより簡単にする手順はある(詳しくは電子ブックを参照)。

迷惑メール/通常メールのマーキング -- 統計的フィルタは使い続けると次第に精度が上がる(し、スパマーたちもその都度それをかいくぐる新しい方法を見つける)ので、迷惑メールはフィルタを通過してそのまま通常メールとして現れることがある。(いわば間違いの間違い。)そういうメッセージはただ削除してもよいが、そうすると同じようなメールをまた受け取ってしまう確率を増やす事になってしまう。削除する代わりに、マークされていないスパムをそれぞれ選択して、手動で迷惑メールとしてマークする(メッセージ>マーク>迷惑メール を選択[Command-Shift-J])

単にメッセージを迷惑メールフォルダに入れてもだめなことに注意。迷惑メールのフラグ(メッセージリストの「紙袋」アイコンで表示される)が立って初めてメッセージは迷惑メールとして認識される。メッセージを迷惑メールとしてマークすると、フィルタの統計リストが変更され、送信者のアドレスが「過去の受信者」リスト(あれば)から取り除かれる。

反対に、Mailは通常のメールを迷惑メールと間違ってマークする場合もある。(いわば正解の不正解。)結局のところ統計フィルタが判断するのは確率だけである。もし例えばスパマーのよく使うような言葉について議論した記事をだれかがあなたに送った場合は、フィルタの針が振り切れるかもしれない。(「やりすぎ」のスパムフィルタに関するこの問題はTidBITSとTidBITS Talkのメーリングリストで果てしない問題を起こしている。)したがってそのようなメッセージは必ず「迷惑メールではない」としてマークして、Mailにそれは通常のメールであることを伝えなければならない。

驚いたことに、メッセージを「迷惑メールでない」とマークした場合も送信者が過去の受信者リストに加えられる。(それが良いことかどうかは別として。)これで以後、その送信者からのメールはスパムとして認識されないことが(デフォルト設定では)保証される。これは過去の受信者リストの機構に関して私が驚いた事の一つにすぎない。

Take Control of Span with Apple Mail -- Mailの迷惑メールフィルタのしくみの基本はここで説明したつもりだ。私の59ページの“Take Control of Span with Apple Mail”という電子ブックでは、Mailユーザがスパムを駆除し、誤認識を防ぎ、フィルタの問題を解決するためのもっと詳しい実際のステップを述べる。この電子ブックはさらに多くの背景となる情報や、追加フィルタの突っ込んだ話題、その他Mailの内蔵のスパム防止機構の範囲を超えたテクニックを含んでいる。Mailでスパムに苦しんでいる人は、私のアドバイスがストレスを減らして、迷惑メールに山のように時間を取られるのを防ぐのに役立つはずだと思う。“Take Control of Spam with Apple Mail”の価格は5ドルで、他のTake Control電子ブックと同様に、購入者は無料でマイナーアップデートを受けられる。

<http://www.tidbits.com/takecontrol/spam-Apple-Mail.html>

[Joe Kissellはサンフランシスコに拠点を置くライター、コンサルタント、Macデベロッパで、Take Controlシリーズの第一巻でベストセラーの“Take Control of Upgrading to Panther”の著者である。彼の「今日の面白い事」というWebサイトは、2004年6月1日から日刊連載を再開する。]

<http://www.tidbits.com/takecontrol/panther/upgrading.html>(日本語)Take Control of Upgrading to Panther 日本語版 - Panther へのアップグレード
<http://itotd.com/>


EnvisionでビジュアルにWebを見る

文: Adam C. Engst <[email protected]>
訳: 古川敬章 <tac@mac.com>

1年くらい前、液晶モニタの値段が十分安くなってきた頃、私は液晶モニタを壁にかけて写真やデジタルアートを表示するのに使えると思った。そう考えたのは私だけではなくて、Open Door Networksのアラン・オッペンハイマーもほとんど同じ事をやりたがっていた。アランはAppleにいた頃AppleTalkの開発にたずさわっていて、Appleを去った後Open DoorはShareWay IP(ファイル共有をAppleTalkだけでなくIP上で行うもの)、DoorStop(のちにSymantecに買収されNorton Personal Firewallとなったファイアーウォールソフト)、ファイアーウォールへのアクセス試行をより理解し対策するためのユーティリティ、いくつかのサーバ用ログ解析プログラムなど、各種のネットワーク関連プログラムをリリースしてきた。

上記のことに触れたのは、Open Doorの最新のプログラムであるEnvision(現在、無料の公開ベータ版)が、根暗なネットワーク/セキュリティ系のソフトとは少し違ったものだからだ。Envisionは基本的にはインターネットベースのスライドショーソフトで、アランと彼のチームが古いiBookで「今日の天文写真」(Astronomy Picture of the Day)を表示するために作り始めたものだ。ユーザが画像を公開しているWebサイトにEnvisionを導くと、プログラムは画像のURLを沢山見つけて、ユーザが設定するサイズ、名前などの条件に合うものをダウンロードする。(Envisionにはあらかじめ選ばれた博物館や通貨動向、漫画などがプリセットされている。)マッチする画像がダウンロードされると、ユーザが決める速さで流れるシンプルなスライドショーとして表示される。

<http://www.opendoor.com/envision/>
<http://antwrp.gsfc.nasa.gov/apod/astropix.html>

EnvisionはクリックばかりしなくてもWebを見て回ることのできる面白いソフトだ。Open DoorはEnvisionの機能の焦点にすべき点や改善の必要な点など、ユーザからのフィードバックに非常に興味を示しているので、ベータ版ながら取り上げることにした。現時点でのEnvisionの機能はいくらか限られている(いくつかは意図的に)。最初にアクセスするサイト以外のサイトはトップページよりも先へは画像を取りに行かないし、変なリダイレクトやJavaScriptのポップアップウィンドウなどの技でユーザがあまり速く画像を見て回れないようにしてあるようなサイトでも動かない。写真の表示はMac OS Xの、パニングやズーム効果のあるフォトスクリーンセーバの方が好きだ。さいわい、Mac OS Xのスクリーンセーバで使いたければ、Envisionのサムネール表示からドラッグ&ドロップでディスクに保存できる。

Envisionは賛否両論の製品になることは間違いないだろう。アダルト画像をダウンロードしたり表示するのに使う人も出てくるだろうが、もちろんそれは通常のWebブラウザでも同じように可能な事だ。バナー広告が他の画像といっしょに表示されないことに腹を立てるサイト管理者もいるかもしれないが、同じように、バナー広告を読み込むのを阻止するWebブラウザや他のユーティリティが存在する。デザイナーやサイト作成者は、画像が文脈なしで、付随するテキスト抜きで表示されるのをおそらく嫌がるだろう。それでも、写真をダブルクリックすればすぐに元のWebページに飛べるし、Envisionにはそれぞれの画像のURL、元のサイトへのリンク、キャプションをInfoペインに表示するオプションがある。(ALTタグから取られるキャプションは画像の上に表示することもできる。)ひょっとすると、Web管理者たちはデジタル写真立てであるEnvisionでより簡単にサイトが表示されるように、コードを少し書き換えたりするようになるかもしれない。

<http://www.opendoor.com/envision/envisionWebmaster.html>

Envisionはまだいくらか大ざっぱな出来だが、安い液晶モニタを求めてdealnewsの投稿を追っているところだ。私が取った何千のデジタル写真だけでなくEnvisionの画像を表示するために、そのモニタをどこにどうやって掛けようかと思う。まずはNASAからのすばらしい宇宙の写真を見る事から始めたい。

<http://www.dealnews.com/>


URL に基づいた Mac OS X の脆弱性出現

文: Adam C. Engst <[email protected]>
訳: 亀岡孝仁 <takkameoka@earthlink.net>

最近明らかになったセキュリティ脆弱性はトロイの木馬ではないが、真に関心を払うに値するもののように見える。これが働くには Apple がある種の URLスキーム (URL の 最初にある http, ftp, 或いは mailto の様な部分) について許している不安全な動作に頼り、かつユーザーが何が起こっているか気付かないように悪質なコードを送付しそして知られることなく実行されなければならない。

この問題は、最初は次の二つの URL スキームに関してだけのものと思われていた:disk と help である。ダウンロードとディスクイメージ (そこには悪質な AppleScript スクリプトを仕込むことが出来る) を自動的にマウントすることと、Help Viewer を使ってその AppleScript を走らせること (既知の場所にあるので) が出来れば、悪事のレシピを手に入れたようなものである。General 設定画面にある Safari の Open “Safe” Files After Downloadingオプションをオフにするだけでは十分な防護とは言えない (そして他の Webブラウザを使っていてもこの脆弱性が出現する場合もある)。

<http://secunia.com/advisories/11622/>

Apple は数日のうちに Security Update 2004-05-24 を出して対応した。Apple からの説明はいつもの様に短いが、察する所、このセキュリティアップデートは Help Viewer の新しいバージョンをインストールして、このプログラムの help URL 経由で送られた AppleScript を実行する機能を削除しているように見える。(このセキュリティアップデートには Mac OS X 10.2 Jaguarのユーザーのための Terminal 内の URL プロセシングに対する修正も含まれている; ここでも Apple はいかなる詳細も提供していない。)

(日本語)アップル - サポート - ダウンロード - Security Update 2004-05-24 (10.3.3)
(日本語)アップル - サポート - ダウンロード - Security Update 2004-05-24 (10.2.8)

関係する誰にとっても残念なことに、Apple のこの対策は、本当はもっともっと複雑で根の深い問題のように思えることに対する単なるバンドエイド対策である。この問題の詳細については Matt Neuburg にこの号の別の所で解説して貰う。Help Viewer に関係した問題はもっと大きな脆弱性の一つの特別なケースに過ぎないと言っても過言ではない。この脆弱性は、ある特定の URL スキームに登録された悪意のアプリケーションを含むディスクイメージをアタッカーが投稿できることから発生している。ユーザーがあるリンクをクリックすると (勿論これは他のものの様に見えるよう覆い隠されている)、ディスクイメージがダウンロードされ、マウントされ、そしてその特定の URL スキームは Mac OS X に登録される。その URL を提供しているサーバーは少し待ってから (ディスクイメージがマウントされそして URL スキームが登録されるまで) このユーザーを今登録されたばかりのスキームを使う他の URL へと自動的に行き先を変更してしまう。そしてこの二番目の URL は Mac OS X にその悪意のアプリケーションを起動するよう命令する。Maurice Sendak の言葉を借りると “'さあ、' Max は叫ぶ '狂気の騒ぎの始まりだ!'”なお、このプロセスについて論理一貫した説明をしてくれた TidBITS Talk の読者である Sander Tekelenburg に感謝したい。

<http://secunia.com/advisories/11689/>
<http://www.euronet.nl/~tekelenb/playground/security/URLschemes/>
<http://db.tidbits.com/getbits.acgi?tlkthrd=2233>

この脆弱性の重要性を少しでも損なうことがあってはいけないが、いくつかのことを明確にしておくことも大事である。これはトロイの木馬ではないし、ウィルスでもない、そして数人がこのコンセプトを立証する例を投稿しているが、実際にこのテクニックを使った悪意のソフトウェアに遭遇したと言う報告にも出会っていない。

これの対策を打ち出すために Apple は猛烈な努力をしているに違いない;対策が出るまでは、一般ユーザーへの最善のアドバイスは (良いバックアップを取ること以外に!)、Unsanity が開発した無料のユーティリティであるParanoid Android をダウンロードしインストールすることのように思える。Paranoid Android はいったんインストールされると、見知らぬ URL スキームを見張っていて警告のダイアログを表示し、あなたの Mac がやられてしまう前にキャンセルすることを可能にしてくれる。Unsanity と Jason Harrisは、Paranoid Android を開発しそれを無料でリリースしてくれたことに対して大きな賞賛を受けるに値する。Paranoid Android がどの様に働くのかについて少しでも知りたいと思う方は下の二番目のリンクにある Jason のホワイトペーパーを読まれたい。

<http://www.unsanity.com/haxies/pa/>
<http://www.unsanity.com/haxies/pa/whitepaper/>

それでも Paranoid Android (Unsanity のもう一つの Haxies の様に) が使うテクニックを気にする人もいる;私の考えは、Paranoid Android を必要としなくなるための John Gruber 自身の Daring Fireball に関するアドバイスに従うか、Apple から対策が出されるまでの暫定策と割り切るかである。Johnは、危険な可能性を持つデフォルト URL ハンドラを不能にする Rubicode のRCDefaultApp ユーティリティの使用を推薦している。他には、有害そうなネットワークの振舞いを警告してくれる Objective Development の Little Snitch の使用を勧める人もいる。

<http://daringfireball.net/2004/05/help_viewer_security_update/>
<http://www.rubicode.com/Software/RCDefaultApp/>
<http://www.obdev.at/products/littlesnitch/>

ここで気をつけなければいけない事は、あなたのコンピュータに対してあなたが取るどの様な行動も不安全の可能性を秘めていることである;全くまともなプログラムの中の一つのバグが悪意のソフトウェアと同じ程度の大問題を引き起こすことだってあり得る。だからと言って何も被害妄想に陥る必要は全くなく、ダウンロードするファイル元やクリックするリンク先を見定める時常識的な注意を払うようお奨めする。最も大事で覚えておいて欲しいのは、変更されたファイルの複数のバージョンを保持する定常的なバックアップがあれば殆どいかなる危機からも最小限の努力で回復できるという事である。

最後に、Apple はこの事態の重大性を間違いなく認識しているであろうが、これも実際の経験の一つなのである。多少波乱のスタートを切った後、Apple のセキュリティグループはこれまでに比較的マイナーな弱点攻撃、その多くはMac OS X にバンドルされた Unix ツールに関する、を扱うのはうまくやってきた様に見える。しかしながら、これは新しいものであり、Mac OS X 特有の脆弱性でしかも Apple の設計判断のゆえに出来たものなのである。多少気がかりなのは、この問題は Apple 内部で発見され、誰もが知る前に修正されたのでは無いということである。察するに、Apple のセキュリティグループは事前対策型と言うより事後反応型であるという事か;セキュリティチームの職責の一部には少なくとも Mac OS X と Apple のバンドルアプリケーションについて脆弱性の可能性を求めて常に色々な試しを行うと言うのがあったと思いたい。


URL ベースの Mac OS X 脆弱性について説明する

文: Matt Neuburg <[email protected]>
訳: Mark Nagata <nagata@kurims.kyoto-u.ac.jp>

今話題になっているセキュリティの脆弱性というのは、いったい Mac OS X のどの部分に問題があるというのだろうか? この状況にはちょっと錯綜したところもあって、また私自身細かい点で勘違いをしているところもあるかもしれないが、ともあれ現時点で私の理解する範囲で状況を解説してみよう。

ご存じのように、書類を Finder でダブルクリックすれば、その書類を「所有する」アプリケーションが起動されてその書類を開く。例えば Word 書類をダブルクリックすれば Word が動き出す。この仕組みが動くためには、あなたのコンピュータが「書類のタイプ」というものを認識していなければならない。それがあるからこそ、どの書類を開くのにどのアプリケーションを動かせばよいのかという所有関係の対応が付けられるのだ。Mac OS X よりも前の時代には、この対応は4文字からなるクリエータコードによって付けられており、そのコードはファイルのための隠れたメタ情報(「デスクトップ・データベース」)という形で保持されていた。ところが Mac OS X においてはそれが新しい方法でおこなわれるようになった。これは Launch Services と呼ばれシステムの一部分として働いている。Apple はこの辺の状況を Launch Services についての開発者向け情報として文書化している。

<http://developer.apple.com/documentation/Carbon/Conceptual/LaunchServicesConcepts/LSCConcepts/chapter_2_section_4.html>

そのウェブページに書いてあることで注目すべきところを要約してみよう。従来のシステムで使っていた4文字のコードに加えて、Apple はクロス・プラットフォームの互換性を向上させようという意図の下に、ファイル名拡張子、つまりすべてのファイル名の末尾に数文字のコードを付け加えることでそのファイルがそのような種類の書類かの手掛かりとなるようにする、という概念をも混ぜ込んで追加した。それと同時に、Apple はさらにもう一つ、つまり「書類」のタイプを差し示すための第三の方法として、URL スキームによるものも導入した。どんなアプリケーションでも、それが特定のスキームに呼応するものだということを指定できる。すると、その後はそのスキームに遭遇する度にシステムがそのアプリケーションにメッセージを送るようになる。

どうして Apple がこのような決断をしたのか、私にはよくわからない。たぶんその理由の一つとして、そもそもファイルの指定の一般的方法をどうするのか、Apple 自身決めかねているように思えるところが大きいようだ。例えば Cocoa では、ファイルをパス名でも URL でも指定できる。全般的に言って、Mac OS X はファイルと URL 全般との間の区別を無くそうという方向に向かっているようにも見える。ある意味ではこれは良いことだろう。なぜならプログラマーにとってみれば http 経由で遠隔ファイルを開くためのコマンドが自分の目の前のマシン上のテキストファイルを開くためのコマンドと同じ、ということを意味しているからだ。けれども、いずれにしてもここで忘れてはならないのは Mac OS X の下で URL がパス名と同じ地位を持つファイル指定子となったことだ。

システムがアプリケーションを認識し、そしてそのアプリケーションがあるスキームに呼応できるという事実を認識できるための方法にはいろいろある。先程の文書の第1段落に記されている通り、この認識のためにそのアプリケーションを起動させる必要は _ない_。単にそのファイルをあなたのハードディスクにコピーするだけで十分なのだ。これは、設計上の選択としては分別あるものと言えるだろう。なぜなら、もしもあなたが新しいアプリケーションを(例えば Microsoft Word を)初めて受け取った時、まずはあなたが自分で Word 自身を開いてやらないとそのインストールに付属するさまざまの .doc ファイルをどうすればよいのかがオペレーティングシステムにはわからない、などという厄介な規則など、結局誰も喜ばないのが当然だろうからだ。たとえそれまでに一度も Word がそのマシンで走ったことが無かったとしても、ユーザーが Finder で .doc ファイルをダブルクリックするだけで Word がそれを開いてくれる、という風になっている方がずっと良いだろう。

そこまでは、それで良い。けれども以上のことをすべて念頭に置いた上で、ちょっと次のことを考えてみてほしい。あなたが Safari でウェブをブラウズしていたとして、あなたがリンクをクリックすれば何が起こるのか、と。例えばウェブページであなたが mailto の URL をクリックすれば、何かが起こる必要がある。だからこそ、mailto の URL スキームをあなたのデフォルトの電子メールクライアントに対応付けしてくれる何かが必要になる。昔々の不便な時代には、Apple はこの問題に対する解答を何も持っていなかった。けれどもある時、Internet Config と呼ばれるサードパーティの解決法が登場して、その後 Apple もそれを採用して Mac OS の中に内蔵させたのだった。

<http://db.tidbits.com/getbits.acgi?tbart=01718>

けれども思い出して頂きたいが、ついさっき私は、今ではどんなアプリケーションでも特定の書類のタイプを「所有」すると宣言できるのと全く同様にして特定の URL スキームを「所有」すると宣言できるようになった、と述べた。このことは、Apple の開発者向け情報ページを見ても再確認できる。

<http://developer.apple.com/documentation/Carbon/Conceptual/LaunchServicesConcepts/LSCIntro/chapter_1_section_1.html>

別の言葉で言えば、Apple は Mac OS X の Launch Services の中に、classic Mac OS 以来存在していた二つの非常に相異なったメカニズムを折り込ませた。一つは Desktop Manager(書類とアプリケーションとを結び付ける)で、もう一つは Internet Config(URL スキームとアプリケーションとを結び付ける)だ。これらはすべて道理に叶ったことに見えるかもしれない。なぜならどちらの場合にも私たちは何かのもの(書類か、または URL スキームか)を使ってアプリケーションを起動させているのだから。でも、これらの二つの概念は必ずしも平行してはいない。そもそも、URL スキームの種類をどこまでも増やしてゆくのは望ましいことではない。mailto リンクである電子メールアドレスをクリックすれば Mail が開くのは良いだろう。また、別のリンクをクリックして Help Viewer が開いたり、Script Editor が開いたりすることもある。でも、あなたが聞いたこともないような隠されたアプリケーションが開いて、ディスクイメージをダウンロードしてマウントしてしまったりすることもあり得るのだ。

つまるところ、もしも私が邪悪な人間で、私が何らかの方法であなたに私の邪悪なアプリケーションをダウンロードさせてそれを Mac OS X に認識させることができたとしたら、そうすればそれだけで私はあなたに悪の手を伸ばして、単なるウェブページなどを使い、そのアプリケーションへメッセージを送って起動させ、邪悪な行動を起こさせることができるようになってしまう訳だ。私の作った悪意あるアプリケーションは、システムに対してそれが“evil://”という URL スキームに呼応すると宣言する。すると、私が何らかの方法であなたに“evil://”リンクをクリックさせられれば、それで私のアプリケーションが起動されることになる。それだけではなく、今週号の別の記事で Adam が説明しているように、本当の恐ろしさは、私がうまく仕組めばあなたに全く気付かれることなくワン・ツー・パンチを繰り出すこともできるかもしれないというところだ。リダイレクト、あるいは単なるフレームを使ったページによってさえも、私はあなたのブラウザに二つの URL を順次開くようにさせることができる。最初の URL は、例えば disk の URL スキームのようなテクニックによって、あなたのハードディスクにアプリケーションをダウンロードさせ、オペレーティングシステムにそれを認識させる。それから、次の URL が私の“evil://”プロトコルを使い、Mac OS X にそのアプリケーションを起動させる。

以上述べてきたような指摘がもしもすべて正しいのならば、私たちはかなり根深い問題に直面していることになる。もちろん、URL スキーム(例えば disk)があなたの知らないうちに何かアプリケーションをあなたのマシンに据え付けてしまうということも問題の一部だが、それとは別に、ウェブブラウザの中の単なる URL だけでそのアプリケーションが起動されてしまうというのも問題だ。だからこそ、単に個々のスキームに対して対抗策を立てるだけでは、この種の攻撃に対する防御にはならない。なぜなら、さまざまのスキームの可能性は無限にあるからだ。ここに、Unsanity の Paranoid Android が有効な対策である理由がある。これは、悪意あるアプリケーションによって登録されたかもしれない未知のスキームすべてについてユーザーに警告を発してくれるからだ。既知のスキームのみに焦点を絞ることはしないのだ。それでも、問題の根源が Launch Services の中に Internet Config の機能を折り込ませたことにあるとする私の意見がもしも正しいのならば、このセキュリティ・ホールを完全に塞ぐためには、Apple は Mac OS X のアーキテクチャそのものを、しかもその本当の根幹部分を修正しなければならず、そのためには、私たちがこれまで慣れ親しんできたいくつかの機能を犠牲にすることも伴わざるを得ないかもしれない。

<http://www.unsanity.com/haxies/pa/>


TidBITS Talk/24-May-04 のホットな話題

文: TidBITS Staff <[email protected]>
訳: Mark Nagata <nagata@kurims.kyoto-u.ac.jp>

以下に挙げた各項の URL の2つ目のものは、私たちの Web Crossing サーバに繋がるようになっている。こちらの方がずっと高速だが、ただこちらはまだ望ましいデザインに改良される所までは達していない。

<http://emperor.tidbits.com/TidBITS/Talk/>

Mac ブラウザのセキュリティ・ホール -- 最近報告のあった Mac OS X におけるセキュリティ・ホールの現実度について、またそれにどう対処すべきかについて、読者たちが議論する。(メッセージ数 4)

<http://db.tidbits.com/getbits.acgi?tlkthrd=2233>
<http://emperor.tidbits.com/TidBITS/Talk/99/>

新手の AppleScript トロイの木馬 -- 悪いのはトロイの木馬を書く人物なのか、それともこの事実を公開の場にぶちまけることで他の連中にも同じことをする動機を与えているかのような情報源の方だろうか? (メッセージ数 8)

<http://db.tidbits.com/getbits.acgi?tlkthrd=2236>
<http://emperor.tidbits.com/TidBITS/Talk/98/>

WriteRight についての考察 -- 理想の Mac 用ワードプロセッサについて、読者たちがいろいろなアイデアや意見などを述べる。(メッセージ数 31)

<http://db.tidbits.com/getbits.acgi?tlkthrd=2235>
<http://emperor.tidbits.com/TidBITS/Talk/101/>

Mellel について -- このワードプロセッサを作っている会社の CEO と Adam とが、Mellel について会話を繰り広げているので、どうぞご注目あれ。(メッセージ数 5)

<http://db.tidbits.com/getbits.acgi?tlkthrd=2237>
<http://emperor.tidbits.com/TidBITS/Talk/102/>

ディスクのラベルについての問題点 -- disclabel 2.0 のリリースについてお伝えしたのを受けて、ある読者から CD や DVD にディスクラベルを貼ることについて問題点の指摘が届いた。(メッセージ数 4)

<http://db.tidbits.com/getbits.acgi?tlkthrd=2234>
<http://emperor.tidbits.com/TidBITS/Talk/100/>


tb_badge_trans-jp2

非営利、非商用の出版物およびウェブサイトは、フルクレジットを明記すれば記事を転載またはウェブページにリンクすることが できます。それ以外の場合はお問い合わせ下さい。記事が正確であることの保証はありませ ん。書名、製品名および会社名は、それぞれ該当する権利者の登録商標または権利です。TidBITS ISSN 1090-7017

Valid XHTML 1.0! , Let iCab smile , Another HTML-lint gateway 日本語版最終更新:2005年 12月 26日 月曜日, S. HOSOKAWA