高木浩光＠自宅の日記

■ APWGに行ってきた

APWGのeCrime'07に行ってきた。

FSTCの「Better Mutual Authenticationプログラム」が言う「mutual authentication」の意味（定義）が気になった。

終了後、とあるお方のご厚意で、とある方にCMUとその周辺をご案内いただいた。（ありがとうございました。）

University of PittsburghのCathedral of Learning。

展望室から見たCMU。左端の工事現場は建設中のゲイツセンター。手前は10年前*1に立ち寄った思い出のあるCarnegie Museum of Natural History。

CyLabのある建物を出たところから見たゲイツセンター建設現場。

なぜかASIMOのようなシルエットが……。http://gatescenter.blog.cs.cmu.edu/というURLが書かれていた。

翌日、次の予定のためSan Franciscoへ移動。

BARTが2003年に空港まで延伸していたというので、電車でダウンタウンへ。

遅い昼飯にとFisherman's Wharfへ行ったら、なんか人がめちゃくちゃいっぱいで。航空ショーをやっていた。これか。毎年やってるのね。

戦闘機よりとにかく飯。クラムチャウダーが美味い。アメリカで食べるクラムチャウダーの味（濃い目な感じ）はどうやって出すんだろう？ ググったらいろいろ出た。今度作ってみよう。

「Phisherman's Wharf」という言葉を思いついたが、まだ誰も使っていないようだ。何かに使えないかな。

宿に戻って仕事。

PlaceEngineで位置検索してみると（やはり）特定できず。

「位置を教える」の機能は使えた。それ以降、住所は出ないものの地図は出せる。

■ 明日帰国

この日付は日本時間。今日で仕事は終わり。明日帰る。

昨日、ホテルの近くに日本人街があるというので、夕飯に行ってきた。中華街にあるような門の日本版らしきものが……。

紀伊国屋書店サンフランシスコ店があった。改装したのか拡張したのか、店が準備途中のままオープンしていた。半分くらいの棚にはまだ本が置かれておらず、何を置く予定かを示す紙のメモが貼られていた。 そして、奥の壁一列には全部本が納められており、のきなみこんな紙が……。

なにか間違っているような……。

今日は、仕事が全部終わった後、夕食にGoogleの桃井さん*1を訪ねた。約束の時間より早く着いたので、待ち時間にPlaceEngineを使ってみると……、

おお！ズバリ5メートルの誤差で位置が特定された。既に誰かが位置を登録していたようだ。

帰り際、桃井さんにMountain View駅まで送って頂いた。このあたりは今ラーメンブームなのだとか。

今ググったら、Mountain View駅の近くに「SHABUWAY」という店があるらしい。評判はよさげ。また訪れるときがあれば行ってみたい。

■ アドレスバー百景 その2 「iPod Touch」的UIの活用を考える

産業音楽の呪縛から逃れて久しかったが、ネットラジオLive365.comのチャンネルのひとつ「arabicmusic.com」の放送を聴いてから、このところすっかり「al-Jeel」というジャンルの音楽の虜になっていた。ネットラジオで表示される曲名で検索して、どこで買えるか探しまくっていた*1。ついにはiPod shuffleを買い、そして先日iPod touchを買った。

今更だが、iPod touchの操作性はすばらしい。特に、自由自在のズーム機能を活かしたSafariの操作性はすばらしく*2、もうEM・ONEでブラウズする気がしなくなった。駅まで歩く間のブラウズのためにlivedoor Wirelessも契約した。

しかし、セキュリティはどうなっているのか。Safariの画面をスクロールさせるとアドレスバーまで一緒に上へ消え去ってしまうことは、9月28日の水無月ばけらのえび日記に書かれていた。

フラグメントIDつきのリンクで来た場合、アドレスバーが表示されないことになるかも……。

「iPod touch の Safari のアドレスバー」, 水無月ばけらのえび日記, 2007年9月28日

たしかにそうなる。ただ、アクセス中はアドレスバーがプログレスバーの役割も果たすため、ロードが終了するまではアドレスバーは上部に居座る。開発側としては「この間にURLのドメインを目視確認しておけ」ということなのかもしれないが、それで十分ということはないだろう。

また、フラグメントID付きのリンク（「#p01」などの指定付きのリンク）のジャンプ先をロードし終えた時点でURLを確認したければ、画面上部のバー（時計が表示されている部分）をタップすれば一番上までササっとスクロールしてくれるので、すぐに確認はできる。しかし元の位置に戻る機能はないようなので、普通の人は、上に戻りたくないと思うようになってしまうだろう。

どうにかならないものか。

ここで気がついたのだが、入力の際にアドレスバーを出現させるようにしてはどうだろうか。

iPod touch版Safariでは、入力欄がタップされると、画面をその部分にズームインして、画面下半分にキーボードを出すようになっている（図3）。

この挙動がスムーズなズームとスクロールで直感的にわかり易く表現されていてすばらしいのだが、ここで、その特長を活かして、アドレスバーもひょっこり現れるようにしてはどうだろうか。画面に余裕もあるようだし。

アドレスバーの確認がどういうタイミングで必要となるかは、安全なWebサイト利用の鉄則にもあるように、重要な情報を入力する直前であるのだから*3、今まさに入力しようとしている図3右の画面で、（偽装不可能な形で）アドレスバーがひょっこり現れれば、確認もしやすいし*4、確認が促されるという効果もあるかもしれない。

これはすぐにも使える現実解なんじゃ？と思ったが、残念ながら、本体を横向きにしているときに無理があるようだ。ズームした画面に余裕がない（図4）。

うーん、どうにかならないものか。

じゃあ、キーボードの上部の余白部分にURL（あるいはホスト名やドメイン名）を表示するとか？ いまいちではある。

ところで、そうすると、このアイデアは携帯電話の現実解にもなるかもしれない。携帯電話にアドレスバーがないことの危険性はこれまでに何度も書いてきたが、開発側に言わせれば、画面が狭くてそれどころじゃないということだった（直接聞いたわけではないが）。しかし、携帯電話のブラウザでも、入力時に特別な動きをするものがある。EZwebのブラウザでは（私の使っている機種では）図5のように、入力欄でボタンを押すと入力専用の画面（右の写真）に移行するようになっている。この（そっけない）画面に、どのURLのページに入力しようとしているのかを表示してもよいのではないか*5。

さらに言えば、PSPについても同じように改良できるかもしれない。7月1日の日記「アドレスバー百景 その1」では、PSPは「△」ボタンを押したときにしかアドレスバーが現れないのがいまいちだと書いたが、入力欄にカーソルを合わせたとき（図6）にもアドレスバーが現れる（偽装不可能な形で*6）ようになっていてもいいのではないか。

日本の開発者には*7「常時表示しておくのは邪魔だ」という主張がどうしても譲れないのだとしても、このように入力の際にだけ表示するのは受容できるはずのデザインではなかろうか。

■ iPod touch版Safariにはサーバ証明書の閲覧機能がない？

サーバ証明書の閲覧機能は、安全なWebサイト利用の鉄則にもあるように、初めてサイトを訪れた利用者にとって欠かせない機能であり、各ブラウザが当然に備えている機能で、たいていは錠前アイコンで示される。

iPod touch版Safariでは、https:// のページにアクセスすると図7のように、アドレスバーの中に錠前アイコンが表示される。これは良い。（Mac OS版Safariが、わかりにくい場所にひっそり表示するものになっているのとは対照的に。）

ところが、この錠前アイコンをタップしても何も起きない。もしかして、サーバ証明書を表示する機能が存在しない？？ もしそうなら英語圏で既に問題にされてそうな話だが……。

■ デイリーポータルZ 記者の家を探しに行く

5月27日の日記「PlaceEngineのプライバシー懸念を考える」では次のように書いた。

つまり、家庭の無線LANアクセスポイントのMACアドレスを誰かに知られることは、住所を知られることに等しい。そのような事態をPlaceEngineサービス（および類似のサービス）が新たに作り出したことになる。

「MACアドレスは個人を特定するものではない」と言えるだろうか？もし、別のネットサービスで、何らかの目的で家庭の無線LANのMACアドレスを登録して使うサービスが始まったとする。そのサービスもまた、「MACアドレスから個人が特定されることはありません」と主張するだろう。このとき、PlaceEngineとこのサービスの両者が存在することによって、わからないはずの住所が特定されてしまう事態が起きてくる。

PlaceEngineなどのサービスが存在する現状、家庭の無線LANのMACアドレスは秘密にしなければならなくなった。

ではどういう状況でMACアドレスを知られ得るのかだが、8月18日の日記ではストーカーから逃れて転居する状況を想定した。他に崎山伸夫氏からはIPv6が普及した状況を想定しての検討をトラックバックで頂いている。IPv6は未来の話だとして、現状でも次のケースがあることにその後気づいた。

iPod touchや携帯ゲーム機器を外で歩きながら使っている人ならお気づきのように、巷の無線LANアクセスポイントのいくつかは、SSIDにMACアドレスっぽい12桁の16進数を割り当てているものがある。これは何のアドレスだろうか。

たとえばBUFFALO製無線LANアクセスポイントのある機種の説明にはこんな記述がある。

WER-AMG54は、本体に設定されているLAN MACアドレス（SSID）が本体底面に記載のSSID初期値と異なります。AOSSを使わずに無線接続する際は、本体底面に記載されているSSID初期値の末尾 ”_G” を除いた12文字のSSIDに接続してください。

製品名・製造番号・MACアドレス・ESSID・設定初期化ボタンを確認する方法, 株式会社バッファロー

また、BUFFALOの「QA番号:BUF3491」には、機種ごとのSSID初期値の一覧表があり、次などの記述がある。

「000740」で始まる12桁のLAN MACアドレスの値
「000D0B」で始まる12桁のLAN MACアドレスの値
11a = 「000D0B」で始まる12桁の値 + 「 _A 」
11g = 「000D0B」で始まる12桁の値 + 「 _G 」
「000740」、「000D0B」で始まる12桁の有線MACアドレスの値
「000740」、「000D0B」で始まる12桁の有線MACアドレス（WiredMAC）の値
「004026」で始まるMACアドレスの下6桁に”GROUP”をつけた値
エアステーションのLAN側の有線MACアドレスの値

「LAN MACアドレス」と「有線MACアドレス」の違いがいまいちわからないが、どうやら、無線側のMACアドレスではなく、有線LAN側のMACアドレスをSSIDの初期設定としたものが多いようだ。PlaceEngineで位置を調べるには、有線LAN側ではなく、無線側のMACアドレスが必要である。

ところが、どうも、有線LAN側MACアドレスと無線側MACアドレスを連番で割り当てている機種が少なくないようなのだ。

図1は、夏休みに東海道新幹線移動中にNetwork Stumblerで検出した数千件のアクセスポイントについて、SSIDで並べ替えて表示した様子である。

Coregaの一部の機種では、無線側MACアドレスと1番違いの値がSSIDとして設定されれていることがわかる。おそらく有線LAN側のMACアドレス（あるいはWAN側のMACアドレス）をSSIDとして使っているのだろう。別のメーカーのものも図2の通りで、全く異なるアドレスを用いているものもあるが、1番違いのアドレスを用いているものがあり、同一アドレスを用いているものも見られる。

また、（これはわりと知られていることかもしれないが）ソニーのLocationFreeベースステーションは、無線側のMACアドレスをそのままSSIDに含めている（図3）。

ここで思い出したのが、2月にデイリーポータルZに掲載されていた以下の記事である。

• フェティッシュの火曜日 無線LANを探しに行く, @nifty デイリーポータルZ, 2007年2月6日

  

この「デイリーポータルZ」というサイトは、誰もやらない実験をすることで人気を博しているサイトなのだが、この回に限っては、いまどき誰でもやったことのあるであろう、無線LANアクセスポイントの収集という平凡な実験をネタにしていた。この記事の著者（および編集者）からすれば、他で見たことのない実験なので、ユニークと思ったのかもしれないが、他の誰もこういうことをしないのは、無線LANアクセスポイントの情報をそのまま公表する行為が電波法59条に抵触する可能性があると心配されているからだろう。

（秘密の保護）

第59条　何人も法律に別段の定めがある場合を除くほか、特定の相手方に対して行われる無線通信（電気通信事業法第４条第１項又は第164条第２項の通信であるものを除く。第109条並びに第109条の２第２項及び第３項において同じ。）を傍受してその存在若しくは内容を漏らし、又はこれを窃用してはならない。

電波法

傍受できてしまうこと自体はしかたないが、傍受して存在を漏らす行為、傍受して内容を漏らす行為、傍受して窃用する行為それぞれが禁じられている。どこの場所にこんなSSIDのアクセスポイントがあるといった情報を公表するのは、存在を漏らす行為にあたるおそれがあるのではないか。

この記事は、以下の引用部のように、能天気にも自分の家の近くで得たアクセスポイントのSSIDをモザイクもかけずにそのまま掲載している。（赤の墨消しは引用時による。）

• フェティッシュの火曜日 無線LANを探しに行く, @nifty デイリーポータルZ, 2007年2月6日

  

  見つかりました。３つです。このうち一つは僕の家の無線LANです。なので、僕の家の周りで無線LANを使ってる人が、僕のほかに二人ということになります。

  さて、家から80mくらい離れてみました。さっき無線LANを検索した場所がまだ視界にあるくらい近いのですが、検索してみるとまた新たに２つの無線LANを見つけました。

5つ示されているSSIDのうち2つは、MACアドレスのようだ。もしこれが、無線側MACアドレスそのものであったり連番であるなら、PlaceEngineを使って著者の家を探し当てることができてしまうだろう。

というわけで、実際にやってみることにした。

まず、無線側のMACアドレスを変更できるアクセスポイントを用意するわけだが、たとえば、次の製品（かなり広く普及していると思われる）では普通にそれが可能になっている。

• ゲーム機専用 無線LAN USBソフトウェアアクセスポイント WLR-U2-KG54, 株式会社バッファロー

図4のように、普通に設定でMACアドレスを変更できるようになっている。

このアクセスポイントデバイスと、これを受信するための別の無線LANクライアントデバイスをPCに接続し、これらをアルミホイルで包んで簡易電波暗室とし（図5）、環境に存在する他のアクセスポイントを受信しないようにした。

手始めに、BroadBand Watchの記事に最近掲載されたこのスライドに映し出されているMACアドレス*1をターゲットにして試した。図6のように、変更した指定のMACアドレスのアクセスポイント1個だけが観測される状態を作り出したところで、PlaceEngineを起動して位置を測定してみると、そのスライドに書かれている通り、たしかに淡路町駅交差点の位置が示された。本当にこの方法で位置を検索できてしまうことが確認された。

というわけで、早速、デイリーポータルZの記事で著者が自宅前だとして公表しているSSIDをアドレスとして用い、また、その前後1番違いのアドレスそれぞれを用いて検索してみた。

結果、掲載されている2つのSSIDのどちらについても、位置は特定できなかった（図7）。どうやら、記者の家の地域はまだPlaceEngineのデータベースに登録されていないようだ。（あるいは、これら2つのSSIDが無線側MACアドレスとは無関係の値である可能性もある。）

そこで次に、同じ記事の後半に記載されている、「アルタがある一角をグルっと一周しただけで12個も見つかりました」と説明された写真に掲載されているSSIDで試してみたところ、図8のように、新宿アルタ前の位置が特定された。

というわけで、自宅を特定されたくない状況では、MACアドレスを秘密にすることが求められるだけでなく、SSIDも同時に秘密にすることに注意を払う必要もあるということになる。あるいは、無線LANアクセスポイントは、SSIDをMACアドレスと無関係の文字列に設定変更して使うのがよい。

近頃はブログ等で、自宅の無線LAN設定の様子を写真で載せている人が少なくない。「SSIDがバレたところで、それで不正アクセス可能になるわけじゃないし」という思考から、SSIDにモザイクをかけずに掲載することがあるかもしれないが、PlaceEngineというサービスが存在する今となっては、各自、SSIDがMACアドレスになっていないかに注意して掲載する必要がある。

特に、LocationFreeを自宅に設置している人は注意が必要だ。たとえば、BoradBand Watchの「外出先からPSPやPCで自宅のテレビが見られる画期的な製品ソニーの新型ロケーションフリー「LF-PK1」」という記事は、LocationFreeベースステーション本体の写真を掲載しているが、この写真には（初期設定の）SSIDが記載されたシールが写っており、誰でも読み取ることができてしまう。

この個体が今どこに設置されているのかは定かでない（インプレス社内にあるのかもしれないし、他人の手に渡っている可能性もある）が、この値をMACアドレスとしてPlaceEngine検索してみたところ、マンションらしき場所が示された（図9）。

さて、今回は、所期の目標であった「デイリーポータルZ 記者の家を探しに行く」を実現できなかったわけだが、今後、PlaceEngineの利用者が増え、登録位置情報が自動的に充実していくにつれ、いつの日か記者の家の地域が検索可能になる可能性がある。

ところで、実は、この記者の個人ブログによると、9月に転居したとのことなので、2月の記事の場所にはもう住んでいないようだ。

だが、逆に、これによって転居先を特定できる可能性もある。記事中で、

見つかりました。３つです。このうち一つは僕の家の無線LANです。なので、僕の家の周りで無線LANを使ってる人が、僕のほかに二人ということになります。

とされている「僕の家の無線LAN」が、もし、上で試したMACアドレスらしきもののことを指しているのなら、今後、転居先の場所が検索可能になる可能性がある。

もっとも、ブログの書きぶりからして、この方はあまり家の場所を隠すつもりがないようなので、いらぬ心配かもしれない。

■ ユビキタス社会の歩き方(3) 無線LANのSSIDを不用意に明かさない

上に書いたとおり、「ユビキタス社会の歩き方」として「無線LANのSSIDを不用意に明かさない」よう留意しなければならい状況が生じ始めている。

あるいは、もしかすると、そうではなく、「PlaceEngineのようなサービスは社会にとって危険であり、存在しないべきである」という世論*2にたどり着く可能性もある。どちらが適切なのか、私にはまだわからない。いずれにせよ、まずこの事実が広く知られなければ、正しく判断されることはないだろう。

■ 自分の無線LANがPlaceEngineに登録されていないか確認する方法

前回の日記に対するリンク元などを見てまわったところ、「PlaceEngineは使いたいが自分のアクセスポイントは登録したくない」といった声があった。さて、「PlaceEngineを使いつつも登録しないでいる」ことは可能なのだろうか。

PlaceEngineには「位置を教える」という機能があるが、このボタン（図1）を押さないようにしていれば登録されずに済むかというと、そうではない。

このボタンは、PlaceEngineの取扱説明書よると、次の場合に使うものとして用意されている。

まだ PlaceEngine サービスエリアに含まれない場所で「現在地を取得」ボタンをクリックすると、現在地取得に失敗します。この場合、地図の下の「位置を教える」ボタンをクリックし、（略）

PlaceEngine MAP サイトで現在地を表示しても、推定された現在地が正しく地図上に表示されない場合は、結果を修正して正しい情報を PlaceEngine サーバーに教えて頂くことが可能です。この場合、地図の下の「位置を教える」ボタンをクリックし、（略）

自分の家で（近くで）このボタンを押せば、もちろん、家のアクセスポイントが登録されてしまうわけだが、このボタンを押さなくても、PlaceEngineで位置情報を得るだけ（「現在地を取得」ボタンを押すだけ）でも、家のアクセスポイントはPlaceEngineサーバに登録されてしまう。このことは、PlaceEngineの論文で次のように説明されている。

• 暦本純一, 塩野崎敦, 末吉隆彦, 味八木崇, PlaceEngine:実世界集合知に基づくWiFi位置情報基盤, インターネットコンファレンス2006, pp.95-104, 2006.

  LaMarca らは、GPS を携行して街中を移動しながら得た大量の無線LAN 電界情報のログから、アクセスポイントの位置制約条件を抽出し、アクセスポイントの位置を推定する方式を提案している[5]。しかしながら、アクセスポイント状況は漸次変化していくので、このようなバッチ式の位置更新だけでは変化に追従しきれない。

  本論文では、バッチ式の位置推定方式に加えて、エンドユーザによる位置アクセスによっても位置情報データベースを更新することを特徴とする無線LAN 位置情報システム, PlaceEngine について報告する。

  （中略）

  • 利用者によるデータベース更新は、利用者が電測情報の測定と同時に明示的に位置を登録する場合に行われるが、利用者が単に位置を検索した場合にも発生する。

  • すなわち、大量の利用者が継続的にシステム対してに検索要求を発生する行為自体がデータベースを更新・増大させるための重要な情報源となる。

  2.4 利用者の位置登録/検索によるデータベースの更新

  利用者が位置を検索する場合

  （中略）

  まず、検索要求に未知のアクセスポイントが含まれる場合が考えられる。位置情報は既知のアクセスポイント情報から得ることができるが、電測情報にデータベースに登録されていなアクセスポイントが含まれていた場合、推定した位置情報を、そのアクセスポイントの初期登録位置として記録する。図7に典型的な位置検索の際のパラメタの例を示す。検索要求に未知のアクセスポイント情報が含まれている。このような場合、既知のアクセスポイント情報に基づき位置を推定し、未知アクセスポイントの初期位置も推定位置として設定する。

このことは、今年9月のイベントの講演でも示されたようで、記事中のこのスライドに例が示されている。

【THE NEW CONTEXT CONFERENCE 2007】FONやPlaceEngine、慶應大学村井教授らが「ネットワーク 2.0」を議論, BroadBand Watch, 2007年9月26日

ユーザーが位置を検索した際、DBには登録されていないがユーザーが実際に検知したアクセスポイント情報などを取得することでDB構築に役立てているとし、「検索サービスも検索キーワードが運営者にとっては重要。我々も検索した人からアクセスポイント情報を教えてもらっている」とした。

したがって、自分の家のアクセスポイントがPlaceEngineに登録されることを嫌う人が、既に登録されてしまっていないか確認しようとするときに、PlaceEngineをそのまま使ってはいけない。確認のために使用する行為が、自ら登録する行為となってしまいかねない。

サーバに影響を与えることなく、その確認をしたければ、次のようにすればよい。

未登録のアクセスポイントが検索時に登録されるのは、そのとき同時に観測される周辺の他のアクセスポイントが既に登録されていて、位置を取得できる場合に限られるのであるから、確認しようとするアクセスポイント1個だけしか観測されない状態で、PlaceEngine検索を行えばよい。

つまり、前回の「デイリーポータルZ 記者の家を探しに行く」で行った実験と同様に、アルミホイルで包むなどして、周辺環境に存在する他のアクセスポイントを観測しないようにしたうえで、確認対象のアクセスポイントのビーコンだけが観測される状態を作り出し、PlaceEngine検索を行う。住所が示されれば既に登録されているということであるし、「位置が特定されません」と表示されれば未登録ということになる。

前回と異なり、MACアドレスの変更が可能なアクセスポイント機器は必要ない。確認対象の（自分の）アクセスポイント機器と、観測する側のPC（PlaceEngineを稼動させるPC）を近くに置いて、それら全体をアルミホイルで包めばよい*1。

このとき、前回の図6（下の図2）のように、Network Stumblerなどを用いて、たしかに1個のアクセスポイントしか観測されない状態であることを十分に確認してから、PlaceEngineを使うよう注意した方がよいだろう。

たしかに1個のアクセスポイントだけで検索を行ったかは、検索後のPlaceEngineの画面で、上段の灰色の縦棒が1本だけかどうかで確認できる。

検索したタイミングではたまたま2本だった……なんてことになれば後の祭りなので、事前に十分に確認したい*2。

ただし、この方法で登録済みかどうか確認できるのは現時点での話だという点に注意したい。もし、今後、PlaceEngineサーバ側が、プライバシー対策として「複数のアクセスポイントが観測されているときにしか位置情報を応答しない」という対策（5月27日の日記の脚注6の対策）をとった際には、上の方法で確認しようとして「位置が特定されません」と表示されても、それは必ずしも未登録ということを意味しない。その状況では、自分のアクセスポイントが登録済みかどうか確認することは難しくなるだろう*3。

もっとも、こうして、自分のアクセスポイントが未登録であることを確認できたとしても、それはあくまで現時点での話である。今後、誰かが（隣人や、通りすがりの人が）家の近くでPlaceEngineを使ってしまえば、そのときに登録されてしまうわけで、それを食い止めるには、司法の力に頼る以外に術がないのではないか。

では、自分の家のアクセスポイントが登録されてしまっているとき、その位置情報を変更することはできるだろうか。たとえば、皇居の中心に変更するとか、沖ノ鳥島に変更してしまえば、誰も本当の位置だと思わなくなると期待できる。

これを故意に行った場合、PlaceEngineサービスに対する業務妨害として責任を問われるおそれがあるかもしれない。ただ、自分のプライベートな情報を無断で勝手に登録されたことに対する対抗措置として、自分の情報についてだけ無効なものに変更するのは、正当な行為であると抗弁できるようにも思える。

もちろん、他人のアクセスポイントに対してまで、位置情報をかく乱させるような変更行為を、故意に継続して大量に行えば、確実に業務妨害行為に当たるだろうし、自分のアクセスポイントの位置情報をかく乱させる行為を組織的に大量の人にさせるよう教唆する行為も、業務妨害行為に当たるおそれがあると思えるので、私はそのような変更行為を推奨しない。

また、技術的観点から言って、そのような変更を行っても無駄である。いずれ、誰か（隣人や通りすがりの人）によって正しい位置に補正されてしまう。このことは、一般向けに書かれた次の記事でも解説されている。

• 立っている無線LAN APは他人のものでも使え！？, 日経IT Pro 記者の眼 安井晴海, 2007年8月1日

  ユーザー参加型のコンテンツの場合，問題となるのが信頼性である。PlaceEngineも，誤操作などによる誤った位置登録や，悪意を持ったユーザーによるニセの位置情報が登録される危険がある。また，無線LAN AP自体が移動する可能性もある。（中略）しかし末吉社長は，「登録件数が増えれば増えるほど，そうした誤った情報は排除されていく」と語る。ソニー本社の“誤登録”も，しばらくたつと解消されたという。

  また位置情報は，ユーザーによる「登録」だけではなく「検索」でも更新されていく。例えば，A，B，CというAPが新宿にあり，これら3つのAP 情報で検索をかけると「新宿」の位置情報をPlaceEngineサーバーが返していたとする。ところが，CのAPを持つ会社が渋谷に移転してX，Y，Z のAPの近くになると，今度は渋谷からX，Y，Z，Cの4つのAPで位置検索がかかるようになる。Cが混ざってはいても，X，Y，Zがある限りは確率的に渋谷の可能性が高いため，位置情報としては「渋谷」を返す。それと同時に，Cの位置が渋谷に移った可能性が高いことをPlaceEngineサーバーが把握するというわけだ。

この記事は、無難なことに、「会社の移転」を題材にしているが、これは個人の家の無線LANアクセスポイントでも同じであることに注意したい。

■ 無線LANのステルス機能ではPlaceEngineに登録されるのを阻止できない

前回の日記に対するリンク元などを見てまわったところ、「ステルス機能でアクセスポイントを隠さなきゃ」といった感想を書いている人がいた。無線LANのいわゆる「ステルス機能」は、SSIDを隠そうとするもの*4であるが、MACアドレスを隠せるものではない。

このことについて、8月に書かれた日経IT Proの記者の眼にも次の記述があった。

• 立っている無線LAN APは他人のものでも使え！？, 日経IT Pro 記者の眼 安井晴海, 2007年8月1日

  PlaceEngineでは，ビーコン信号中のMACアドレスと電界強度を使って位置を割り出す。ただし，ステルス機能を設定しているAPの場合は位置情報の取得には使えない。ステルス機能とは，ESS-IDの存在を隠すためにビーコン信号の送出を制限するセキュリティ機能のことである。

これは事実に反する誤った記述である。

第一に、無線LANのステルス機能とは、ビーコンパケットの送出を止めるものではない。送出されるビーコン中のSSID欄にSSIDを記載しないようにする機能であり、当然ながらMACアドレスは送出される。

第二に、もしかすると、PlaceEngineクライアントが、傍受したビーコンについて、ステルス機能でSSIDが空になっているものについては、MACアドレス情報をPlaceEngineサーバに送信しないよう、配慮された設計になっている可能性もあるが、現時点ではそのようにはなっていない。

実際に、上に書いた「自分の無線LANがPlaceEngineに登録されていないか確認する方法」の方法で、私の家のステルス設定のアクセスポイントについて確認を行ってみたところ、住所が表示された。ステルス設定のアクセスポイントのMACアドレスがPlaceEngineサーバに送信されたためと推定される。

もっとも、今後、プライバシー配慮の第一歩として、ステルス設定のアクセスポイントの傍受情報をPlaceEngineで窃用しないようにする改善が行われる可能性はあるかもしれない。

その場合、必要な人がその設定変更の必要性を認識できるよう、PlaceEngineサービスの運営者は、その仕様の明確な開示と、それが何のための配慮であるかを説明しなければならない。また、それは、PlaceEngineユーザに説明すれば済むというものではなく、すべての無線LANアクセスポイント設置者に対して必要な説明である。

■ ユビキタス社会の歩き方(4) 他人から貰う無線LAN機器に警戒する

モテ頃の女性（など）は、知人男性（など）から無線LANアクセスポイント機器をプレゼント（など）された際には、プレゼント主がMACアドレスをメモするような人物でないか注意した方がよいかもしれない。

貰い物を自宅で使用していると、しばらく経過した後（つまり、誰かが自宅近所でPlaceEngineを使用して、そのMACアドレスがPlaceEngineサーバに登録されるに至った後）には、プレゼント主に自宅の場所を検索されてしまいかねない状態となる。

箱が未開封であること、また、箱にMACアドレスやSSID初期値が書かれていないことを確認した方がよい。

一般にこの種のリスク（譲渡されるIT機器によるストーカー行為のリスク）は、通常、初期化した後に設定を変更して使用することで回避されるものであったが、この問題（PlaceEngineによって新たに生じ始めた問題）においては設定変更で対応できない。なぜなら、たいていの独立型アクセスポイント製品には、無線側MACアドレスの変更機能がないからだ。

同様に、使用済みの無線LANアクセスポイントを他人に渡す場合にも、自宅の場所が知られてかまわない人だけにした方がよいだろう。

類似の話：

• ユビキタス社会の歩き方(1) もらったEdyはam/pmで使わない。am/pmで使ったEdyは渡さない。, 2006年12月24日の日記

■ 一太郎plug-inをIEとFirefoxで無効に 〜 ジャストシステムは本当の脅威を教えてくれない

目次

• ワープロソフトの「脆弱性」とは？
• ゼロデイ攻撃に見舞われ続ける一太郎
• 「危険度：低」って正気で言ってるの？
• パソコン初心者並みの認識のソフト会社
• 「攻撃成立に必要なユーザの関与」は「積極的」か「消極的」か
• 知られざる一太郎ビューアplug-inの存在
• 受動的攻撃がもはや最大級の脅威
• ジャストシステムは回答を拒否
• 製品ベンダーが発表しなければ危険性を周知できない
• 発見者の指摘があっても無視
• メディアはJVN情報を伝えるときどうして発見者に取材しないの？
• plug-inを無効にする方法

ワープロソフトの「脆弱性」とは？

先週、新たな一太郎の脆弱性と修正パッチが公開された。「一太郎の脆弱性」と聞いて、どんなときに危険のある話だと理解されるだろうか。ジャストシステム社の告知文には次のように書かれている。

■現象とその対処方法

一太郎の「セキュリティ更新モジュール」を公開いたします。

悪意のある第三者に不正に改ざんされた一太郎文書を読み込むことで、任意のコードが実行され、パソコンが不正に操作される危険性があります。

モジュールを導入することで、問題のあるファイルを一太郎で開いても、不正な動作は発生しなくなります。

アップデートモジュール導入にかかわらず、身に覚えのない電子メールに添付されている一太郎文書ファイル、並びに、信頼性が保証されていないWebサイトなどにある、出所の不明な一太郎文書ファイルを開かないよう、ご注意ください。

一太郎の脆弱性を悪用した不正なプログラムの実行危険性について, ジャストシステム, 2007年10月25日

ほとんどの人は、「あやしい一太郎ファイルを開かなければ大丈夫」と思うのではないだろうか。

そもそも、ファイルを開く行為はユーザの責任である。メールに添付されたファイルの拡張子が「.exe」なら、それを開く行為は任意コード実行を許すものとなる（結果としてウイルスやボットやスパイウェアの侵入を許す）わけだが、そのことを指して、何かに脆弱性があるとは普通言わない。それなのに、一太郎のファイルを開くことが、ユーザの自己責任でなくて、なぜ「一太郎の脆弱性」なのか。

それは、データファイル（プログラムコードを含まない）として分類される拡張子のファイルは、本来ならばいつ開いても大丈夫であるはずのところ、その期待が裏切られ、（バッファオーバーフローのバグがあることによって）（攻撃者が仕掛けた）プログラムが起動してしまうためだ。データファイルとして設計された一太郎ファイルの信頼性が損なわれるわけだ。

過去に不適切な脆弱性告知をしていたジャストシステム（事例1、事例2）のような会社が、このことを「一太郎の脆弱性」と認めてきたことは、潔いことだと感心していた。今年の7月までは。

ゼロデイ攻撃に見舞われ続ける一太郎

もっとも、相変わらず要領を得ない告知文の書きぶりを見れば、セキュリティ脆弱性のことを理解して「潔い」というよりも、単に、これまで何度かゼロデイ攻撃のターゲットになってきたことから、しかたなくパッチを提供し、わけもわからず「脆弱性」という言葉を使っているだけのようにも見える。

• 一太郎を狙うゼロデイ攻撃, ITmedia, 2006年8月17日
• 一太郎、再びターゲットに――新たな脆弱性狙うゼロデイ攻撃, ITmedia, 2006年9月28日
• 一太郎狙うゼロデイ攻撃が再び発生、パッチは開発中, ITmedia, 2007年4月9日
• 一太郎に新たなゼロデイ攻撃、画面の「閃光」でマルウェアに感染, ITmedia, 2007年8月6日

どんなにセキュリティに無理解なソフトウェアベンダーであっても、現に自社製品がゼロデイ攻撃に侵されていたら、嫌々でも対処をせざるを得ないのだろう。顧客からの突き上げもあると思われる。

「危険度：低」って正気で言ってるの？

そんなふうに思っていたところ、今年8月に出たゼロデイ攻撃に対する告知（図1、図2）を見たときは、「やっぱりこの会社は駄目だ」とはっきり認識した。

わざわざことさらに「危険度判定：低」と書かれていた。

任意コード実行を許す脆弱性なのに危険度が「低」というのは、全くおかしい。

このことについて誤りを指摘しようと、8月6日に、ジャストシステムのサポートセンターに電話したところ、次の展開となった。

---

私: 3日付の重要なお知らせについてお尋ねしたいのですが。

J1: 一太郎の脆弱性についてですね。ただ今アップデートモジュールを開発中でありまして、レベル自体は低レベルと判断しておりまして、添付ファイルを開かないようにご注意いただいているところです。

私: 添付ファイルを開かなければ大丈夫なんですか？

J1: セキュリティソフトメーカーの判定ではございますが、信頼性の保証されていないWebサイトの、出所の不明なファイルを開かないようにご注意ください。

私: それでいいんですかね？

J1: 私では、重要なお知らせに書かれていること以上のことがご案内できませんので、一太郎の選任のサポート担当者に代わります。

（しばらく待つ）

J2: お待たせしました。一太郎専任のサポートの者です。

私: 一太郎ビューアのユーザなのですが、3日付の重要なお知らせが出ている脆弱性ですが、これはどうすればよいのでしょうか？

J2: 今回、脆弱性の対策プログラムを開発中ではございまして、お客さまには、メールの添付ファイルを開かないように、信頼できないWebサイトの出所不明なファイルを開かないようにお願いしているところです。

私: さきほど電話の最初の方は「レベル自体は低レベルと判断しておりまして」とのことでしたが、レベルが低レベルというのはどういう意味ですかね？

J2: 危険度という意味では、パソコンが完全に壊れてしまうということではないということして……。

私: 過去にも脆弱性がありましたが、今までのものと比べるとどうなんでしょうか。

J2: これまでのものも低レベルでした。

私: でも、今回だけ低レベルと書いてあるんですよね。「重要なお知らせ」のページに掲載されている過去の告知には、低レベルとは書かれていないですよね。今回だけ「危険度判定：低」とわざわざ書かれているので、今回は以前と違ってたいしたことないという意味かと？

J2: たしかに重要なお知らせには書かれておりませんが、これまでも低レベルでした。

私: セキュリティソフトメーカーによる判定とのことですが、具体的にどこのことですか？

J2: シマンテック様やマカフィー様です。

私: それって、感染の状況が少ないっていう意味じゃないんですか？

J2: ……。

私: 電話の最初の方は、開口一番「レベル自体は低レベル」とおっしゃいましたが、「危険度が低というのはおかしいんじゃないかと思うんですよね。

J2: 危険度に関してセキュリティソフト側のものとしては、感染力や影響力などによって判断しているようでして、こちらでは詳しくはわかりかねます。今回の脆弱性に関しては、危険度が高かろうが低かろうが、アップデートモジュールをご提供するつもりで開発を進めておりますので、メールなどで送られてきた場合には安易に開かないようにしていただければと。

私: 「危険度：低」の意味がわからないとおっしゃいますが、サポート窓口ではわからないということはいいですよ、しかたがないとして、しかしながら、ジャストシステム社としての見解はどうなんですか？ おたくの告知文の中に「危険度：低」と、意味もわからないままに書いているということはないですよね？

J2: ……。

私: あなたではわからないようなので、「危険度：低」と書いた人に直接伝えたいです。

J2: 担当の者から折り返しお電話いたします。

---

パソコン初心者並みの認識のソフト会社

以前から感じていたことだが、「セキュリティといえばウイルス対策のこと」と勘違いしている会社がけっこうあるようだ。たとえば、モーニングスターWebサイト改竄事件でも同じことが気になった。（これについては日を改めて書く。）

それは無理もない話で、おそらく、次の順序で事態が展開しているために、そのような勘違いが生じているのだろう。

未知の脆弱性を突いたウイルス入りファイルが、標的型攻撃で特定の組織だけに送り付けられる。
　　↓
ウイルスメールを送りつけられた組織のシステム管理者が、アンチウイルスソフト会社に、それを検体として届け出る。
　　↓
アンチウイルスソフト会社が、そのウイルスについての情報を公開する。
　　↓
脆弱性を突かれたソフトのベンダーがそれを知り、告知文を書く。アンチウイルスソフト会社の発表を基にして。

つまり、8月の件でジャストシステムが「危険度：低」と書いてしまったのは、シマンテックの発表（図3）にあった「危険度 1: ほとんど影響なし」の記述を、そのまま書き写したためと思われる。

これは全く馬鹿な話だ。脆弱性の危険度と、1つのウイルスの危険度とでは、尺度が別々のものだ。

ウイルスの危険度は、それがどれだけ広く感染するものかが主要な評価尺度となる。ワームであれば危険度は高いが、他への伝染能力を持たない単なるトロイの木馬であれば、危険度は低いものとされる。図3のように、このときのゼロデイ攻撃では「感染報告数 0-2」となっていた。おそらく、1件の届出があっただけなのだろう。

また、ウイルス対策ソフト会社にとっては、感染の原因が脆弱性を突いたものかどうかはどうでもよいことなのだ。なぜなら、メール添付の「.exe」ファイルを自ら開いて感染してしまうようなユーザを相手にしているので、脆弱性がなくてもワームのように拡散するウイルスは「危険度：高」と評価される。

それに対し、脆弱性を修正する立場にあるソフトウェア製品のベンダーはどうか。ゼロデイ攻撃などというのは例外的な事件であって、攻撃が出る前に脆弱性を修正するのが本来の姿だ。そのときは当然「感染報告数」は 0 なのであって、シマンテックに情報が載ってさえいない段階で、攻撃を未然に防ぐために、その脆弱性がもし今後攻撃されたらどれだけの危険性があるかをユーザに伝えて、対処を促すというのが、常識的な製品ベンダーの行動である。

そして、バッファオーバーフロー脆弱性のような、任意コード実行を許す脆弱性の危険度は、誰もが知っているように、致命的なものだ。実際、8月のゼロデイ攻撃のときは、Secuniaの評価では「Extremely critical」とされていた*2。

ジャストシステムはそんなことさえ理解していない製品ベンダーだ。

ジャストシステムにはまともな技術者がいないのか？ ジャストシステムにだって、社内情報システムがあるだろう。そこには当然にシステム管理者がいて、システム管理者はWindowsやAdobeなど他社製品の脆弱性情報に目を配って、危険度を評価し、重要度に応じて社内システムへの対応を行っているだろう。そのシステム管理者から見て、一太郎のバッファオーバーフローが「危険度：低」というのはおかしいと思わないのか？

部署が違えば他人事なのか？ 自社の信頼のために自発的に社内で行動するという愛社精神はないのか？

「攻撃成立に必要なユーザの関与」は「積極的」か「消極的」か

とはいえ、脆弱性の危険度の評価には、「任意コード実行」のように攻撃で何が可能かという尺度だけでなく、どのくらい容易に攻撃が成功してしまうかという尺度も重要だ。

JVNには、「JPCERT/CCによる脆弱性分析結果」という危険度評価がある。この評価指標のひとつに、「攻撃成立に必要なユーザの関与」という項目がある。ここは、「積極的」、「消極的」、「関与させる必要なし」の3段階で評価されている。これがどういうものかというと、おそらく次のようなものであろう。

「攻撃成立に必要なユーザの関与」が「関与させる必要なし」というのは、たとえば、HTTPサーバの脆弱性のように、被害者が眠っている間にも、攻撃者からの能動的な攻撃によっていつでも被害が出てしまうものを指す。これは危険度が高い。

一方、「攻撃成立に必要なユーザの関与」が「積極的」というのは、被害者が自ら望んで行った操作によって攻撃が発動するというもので、たとえば、メールの添付ファイルを開くとか、怪しいWebサイトに置かれたファイルをダウンロードして保存したものをダブルクリックして開くとか、ファイル交換ソフトで入手したファイルを開くといったものが該当する。

この場合、寝ている間には被害が出ないし、賢明な人であれば、操作に注意することで被害を回避することができる。したがって、これは危険度が低いと評価される。

その中間に位置するのが、「攻撃成立に必要なユーザの関与」が「消極的」というものだ。これは、被害者が望んで行ったわけではない操作によって攻撃が発動するというもので、たとえば、Webブラウザで怪しいサイトを閲覧しただけで脆弱性を突かれて攻撃が発動するといったものが該当する。

この場合、寝ている間には被害が出ないものの、賢明な人であっても、いくら注意していても被害を回避することはできない。「怪しいサイト」を事前に見分けることはできないし、IFRAMEタグやOBJECTタグなどによって、ページを開いただけで攻撃用ファイルもロードさせることができてしまうからだ。特に、Web 2.0時代になり、縦横無尽に張られたハイパーリンクを辿りまくるのが普通となった今では、回避できない。

では、一太郎の脆弱性において「攻撃成立に必要なユーザの関与」は、3つのうちのどれと評価されるだろうか。ジャストシステムの告知文に、

アップデートモジュール導入にかかわらず、身に覚えのない電子メールに添付されている一太郎文書ファイル、並びに、信頼性が保証されていないWebサイトなどにある、出所の不明な一太郎文書ファイルを開かないよう、ご注意ください。

と書かれているということは、「積極的」なユーザの関与がなければ攻撃は成立しないということだと理解される。

私も、8月の時点まではそういうものだと思っていた。

「怪しいファイルを開くような素人ユーザが悪いんだよね」、「俺は怪しいファイルなんか開かないから関係ないね」、「たいして危険じゃないし、パッチなんか適用したら動かなくなるかもしれないし、やめとくわ」……と。

知られざる一太郎ビューアplug-inの存在

しかし、Secuniaの評価が「Extremely critical」だったのが腑に落ちなかった。Secuniaの評価指標の説明によると、

Criticality

Extremely Critical (5 of 5):

Typically used for remotely exploitable vulnerabilities that can lead to system compromise. Successful exploitation does not normally require any interaction and exploits are in the wild.

These vulnerabilities can exist in services like FTP, HTTP, and SMTP or in certain client systems like email programs or browsers.

とある。「もしかして、Internet Explorerとの複合技で何か起きてしまうのかな？」と思い、念のため実験をしてみた。8月5日のことだ。

「test.jtd」というファイルを適当に作って自分のWebサーバに置き、一太郎ビューアをインストールしているPCのInternet Explorerでアクセスしてみた。そしたら、意外な事が起こった（図4）。

なんと、一太郎ビューアがInternet Explorerに組み込まれる形で表示された。

まあ、Acrobat Readerを入れているとPDFファイルにアクセスしたときにそうなるのと同様ではある。だが、そんな機能が一太郎ビューアにあるとは思ってもみなかった。なぜなら、今までどれだけネットサーフィンを続けてきたかわからないが、一度たりとも、一太郎ファイルをWebで開く機会はなかったからだ。

ということは、一太郎にバッファオーバーフロー脆弱性があると、悪意あるサイトを訪れただけで被害に遭うのではないのか？ つまり、「攻撃成立に必要なユーザの関与」は「消極的」で、賢明な人が注意していても被害を回避できないタイプの脆弱性ではないのか？

であれば、Secuniaが言うようにこれは最大級の危険性の脆弱性であって、「危険度：低」どころか「危険度：中」ですらない話だ。

受動的攻撃がもはや最大級の脅威

Secuniaの指標のように*3、今日では、受動的攻撃であっても最大級の危険度として評価されることがある。これは、そのような攻撃が現に流行している事実があるためだろう。たとえば次の記事に、その現実が解説されている。

• 脅威，すべてはWebアクセスから始まる 第1回 普段アクセスしている“おなじみ”サイトに仕掛けられるワナ, 平原伸昭/トレンドマイクロ, 日経IT Pro, 2007年10月15日

  昨今，不正プログラムの脅威はWebアクセスによる侵入へと急激に変化している。2007年6月中旬に数千もの正規Webサイトが改ざんされ，不正プログラムが埋めこまれたイタリアの事例は記憶に新しい（関連記事）。また日本国内においても，ホームページを無料で作成できるサービスを提供しているサイトや投資信託情報を提供するサイトで同様のインシデントが発生し，大きな話題となった。

  （略）

  これらのケースの多くは，不正サイトへアクセスさせるスクリプト・タグが1行埋め込まれ，パソコンに内在するぜい弱性を突いて不正プログラムをダウンロードさせられる*4という仕掛けを施されたものである。

  これらは，普段から多くのユーザーがアクセスしている「正規Webサイト」。にもかかわらず，結果的には，アクセスしてきたユーザーの一部に大きなセキュリティ被害をもたらした。「怪しげなWebサイトに近づかなければ大丈夫」とは，決して言えない。

こういった攻撃が流行っている昨今、Webサイトを閲覧しただけで発動する一太郎の脆弱性の責任は重い。

ジャストシステムは回答を拒否

8月6日に電話した際、「担当の者から折り返しお電話いたします」のその後がどうなったかというと、「『危険度：低』と書いた人」と直接話すことは叶わず、サポートセンターの責任者を通した間接的なコミュニケーションとなった。

まず、次の質問には回答が得られた。

• 一太郎ビューアではなく、一太郎本体をインストールしたときにも、このplug-inはブラウザにインストールされるのか？

回答は「yes」だった。次に、

• この脆弱性は、ブラウザplug-inで開いたときにも任意コード実行となるものか？

という点について尋ねたところ、即答できないので上に報告するとのことだった。その際、私の意見として、

もし脆弱性が発動する可能性があるなら、告知文に書かれている回避策「開かないようご注意ください」は間違っていることになるから、訂正が必要で、plug-inを無効にする設定を回避策として告知するべきだ。

ということ伝えた。しかしこの点について告知文が修正されることはなく、4日後にパッチがリリースされた際に、告知文が改定されたものの、「アップデートモジュール導入にかかわらず」という部分が追加されただけだった。

アップデートモジュール導入にかかわらず、身に覚えのない電子メールに添付されている一太郎文書ファイル、並びに、信頼性が保証されていないWebサイトなどにある、出所の不明な一太郎文書ファイルを開かないよう、ご注意ください。

一太郎の脆弱性を悪用した不正なプログラムの実行危険性について, 2007年8月3日（2007年8月17日改訂版）

そこで、「告知文が訂正されていないが、これは、私が言ったことが伝わっていないのではないか」と尋ねたところ、サポートセンターの責任者は「きちんと伝えている」と言うので、次の3つの可能性のどれかではないか？ と尋ねた。

1. 調査を行ったところ、技術的要因によりこの脆弱性はplug-in経由では発動しないものであることがわかったため、告知を訂正する必要がないと判断している可能性。

2. 調査を行うにあたり、Symantec等から得た当該トロイの木馬の検体を用いてplug-in経由でどうなるか試したところ、トロイは動かなかったため、告知を訂正する必要がないと判断している可能性。

3. 話は聞いたが調査はしていない可能性。

そして、もし 2. であるなら、調査方法が間違っているということを伝えた。ローカルファイルを開いたときに発動するように作られたexploitがplug-in経由で動作しないのはたまたまであって、plug-in経由で動作するよう調整されたexploitが登場する可能性があるということを伝えた。 また、もし 1. であるならそのことを知りたいと問い合わせた。

それに対し、翌週、回答があり、「1. 2. 3. のどれなのかということも含めて、回答しないというのが経営の判断です」という回答だった。

無駄骨だったが、「経営の判断です」というくらいだから、然るべき人に趣旨は伝わっているはずだろう。

製品ベンダーが発表しなければ危険性を周知できない

結局、本当にplug-inで発動するかは不明なままだったので、マスメディアもその危険性を伝えることができなかった。以下のように、報道では「ファイルを開かないように注意すればよい」ということになっていた。ジャストシステムの発表をそのまま流しているだけだからだ。

• 一太郎に新たなゼロデイ攻撃、画面の「閃光」でマルウェアに感染, ITmedia, 2007年8月6日

  現時点でパッチが存在しないため、ジャストシステムでは、身に覚えのない電子メールに添付されている一太郎文書ファイルや、信頼できないWebサイトなどにある出所不明な一太郎文書ファイルを開かないよう、ユーザーに注意を呼び掛けている。

• 一太郎の0-day脆弱性を悪用するマルウェアが再び発生 - 米Symantec, マイコミジャーナル, 2007年8月6日

  同社では身に覚えのない電子メールに添付されている一太郎文書ファイル、並びに信頼性が保証されていないWebサイトなどにある、出所の不明な一太郎文書ファイルを開かないよう、注意を呼びかけている。

これは、JVNでも同じだ。

• JVNVU#343727 一太郎シリーズに任意のコードが実行される脆弱性

  想定される影響

  細工された一太郎文書をユーザが開くことにより、一太郎を実行したユーザの権限で任意のコードが実行される可能性があります。

JPCERT/CCでさえ次のように言っていた。

• JPCERT/CC REPORT 2007-08-08

  2007年8月7日現在、この問題を解決するアップデートモジュールは提供されていません。ジャストシステムでは、アップデートモジュールを開発中と発表しています。アップデートモジュールが提供されるまで不審な一太郎ファイルは開かないようにしてください。

製品ベンダーが脆弱性情報を隠蔽したり、あるいは分析する能力がなくて発表できないでいる場合でも、もしその脆弱性の発見者が善意の発見者であるなら、発見者から正確な危険性の情報が公表されると期待できる。

それに対し、8月のゼロデイ攻撃の脆弱性のように、悪意の発見者によるものである場合には、検体を持っている人にしか分析ができない。

検体は、ウイルス対策ソフト会社が持っているわけだが、ウイルス対策ソフト会社は、ウイルスの挙動は分析するけども、ウイルスが悪用している脆弱性の（脅威の範囲の）分析はしない。なぜなら、会社の利益に関係がないからだ。彼らの目的は（第一には）公共の安全ではなく、ウイルス対策ソフトを売ることである。

報道でも次のように、現象面ばかりが伝えられていた。

• 一太郎に新たなゼロデイ攻撃、画面の「閃光」でマルウェアに感染, ITmedia, 2007年8月6日

  セキュリティソフトメーカーのSymantecは、不正な一太郎文書のサンプルを入手したと報告。この文書を開くと画面に閃光が走るが、これはマルウェアが脆弱性の悪用に成功し、もとの文書をクラッシュさせてしまったことを示す。その後新しい文書が開かれるが、中身は空白だという。

  システムには「Trojan.Tarodrop.D」というドロッパー型トロイの木馬が感染する。ここからさらに別のトロイの木馬「Hacktool.Keylogger」を呼び込み、キーボードの入力情報を記録して、盗んだ情報を外部に送信する。さらに、システムに自らをコピーして、ユーザーが自分のファイルをすべて見られないようにしてしまうほか、ファイアウォールもかいくぐってしまう可能性が高いという。

  （以下略）

• 一太郎の0-day脆弱性を悪用するマルウェアが再び発生 - 米Symantec, マイコミジャーナル, 2007年8月6日

  米Symantecは同社が運営するblog「Symantec Security Response Weblog」において、ジャストシステムの日本語ワープロソフト「一太郎」の0-day脆弱性を悪用するマルウェアが、再び発生したと公表した。

  これによると、今回発見された「Trojan.Tarodrop.D」は、一太郎の0-day脆弱性を悪用することでトロイの木馬を生成するという。その後、このトロイの木馬はキーロガーを生成し、盗み出した情報をcvnxus.8800.orgのTCP443番ポートへ送信するとされる。

  また、今回使用が確認されたキーロガーは、自分自身を「%System%\dg.exe」として複製したうえで、explorer.exeのプロセス空間に注入するのだという。こうすることで、感染PCの利用者からこうしたファイルの存在を隠すことができる。同様の動作は「%System%\ svhosts.exe」によって再起動後も発生し、感染を継続させることができるという。

  （以下略）

ある脆弱性に対してたまたま作成された1個のウイルス作成例について動作内容を説明しているだけで、どういうときに脆弱性が発動するかの脅威の範囲についてSymantecは追いかけていない*5。

そして、検体の提供を受けたであろう製品開発者のジャストシステムは、ウイルス対策ソフト会社の言うことしか見ておらず、「危険度：低」などと発表してしまう有様だ。

発見者の指摘があっても無視

そして、今回、新たな脆弱性が発見され、IPAに届け出られたものが、JVNで公表された。

今回のケースでは、発見者が脅威の範囲を公表している。

• [FFRRA-20071025-1] 一太郎2007 JSTARO4.OCXのリッチテキストファイル処理におけるコピーループのバッファオーバーフロー脆弱性, フォティーンフォティ技術研究所, 2007年10月25日

  フォティーンフォティ技術研究所リサーチチームは、一太郎2007、および一太郎ビューアのリッチテキストファイル処理にバッファオーバーフロー脆弱性を発見しました。細工された文書ファイルをこの文書作成ソフトウエアで開くことで、あるいは、細工された文書ファイルが置かれたwebサイトを Internet ExplorerやFirefox等のwebブラウザで閲覧することで、文書ファイル中に記述された任意のコードを実行させる事ができます。

• [FFRRA-20071025-2] 一太郎2007 JSTARO4.OCXのリッチテキストファイル処理におけるwcscpyバッファオーバーフロー脆弱性, フォティーンフォティ技術研究所, 2007年10月25日
• [FFRRA-20071025-3] 一太郎2007 TJSVDA.DLLのリッチテキストファイル処理におけるinfo-titleバッファオーバーフロー脆弱性, フォティーンフォティ技術研究所, 2007年10月25日

発見者の鵜飼さんにメールで聞いたところ、plug-inで発動することはIPAへの届出にも書いたとのことだった。

それなのに、ジャストシステムが今回公表した告知文は、8月のときと違っていない（図5、図6）。

8月のときと異なり、ブラウザplug-inで脆弱性が発動することが実験で確かめられているにも関わらず、ジャストシステムは知らぬ存ぜぬを通した。何が問題なのかは、8月の電話で既に伝えているわけで、「経営の判断です」と答えるほどのレベルまで耳に届いているはずなのにだ。

そして、まずいことに、10月25日にIPAからプレス発表された注意喚起においても、ファイルを開かないようにしていれば発動しないかのような誤解を与える文章が掲載されてしまった。

• 「一太郎シリーズ」における3つのセキュリティ上の弱点（脆弱性）の注意喚起について, 情報処理推進機構, 2007年10月25日
  

  対策方法

  対策方法は「ベンダが提供する対策済みバージョンに更新する」ことです。

  なお、一般的にこのような被害にあわないために、なるべくウェブサイト上で直接文書ファイルを開いたり、不審な内容のメールに添付されたファイルを開かないようにしてください。

JVNも、煮え切らないぼんやりとした表現しかしていない。

• JVN#29211062 一太郎シリーズにバッファオーバーフローの脆弱性

  詳細情報

  ジャストシステムが提供する一太郎シリーズはワープロソフトです。この一太郎シリーズには、バッファオーバーフローの脆弱性が存在します。細工された jtd ファイルを直接開いたり、ウェブサイトなどを経由して閲覧した場合に、その操作を行ったユーザの権限で任意のコードを実行される可能性があります。

「ウェブサイトなどを経由して閲覧」とはどういう意味なのか？ なぜもっとはっきり書かないのか？

こうなると、マスメディアはこれを右から左へと流すだけだ。

• 「一太郎」に危険な脆弱性が3件、ファイルを開くだけで被害の恐れ, 日経IT Pro, 2007年10月25日

  細工が施された文書ファイル（.jtd）を開くだけで、悪質なプログラム（ウイルスなど）を実行される恐れがある。

• 一太郎シリーズに深刻な脆弱性, ITmedia, 2007年10月26日

  問題を悪用されると攻撃者が細工を施した文書をユーザーに開かせ、任意のコードを実行することが可能になる。（略）

  同社はアップデートモジュール導入にかかわらず、身に覚えのない電子メールの添付ファイルを開いたり、信頼性が保証されていないWebサイトなどにあるファイルを開かないよう、注意を呼びかけている。

「ブラウザで悪意あるWebサイトを訪れただけで」ということを誰も書いてくれない。

メディアはJVN情報を伝えるときどうして発見者に取材しないの？

しかし、今回、@ITの高橋睦美記者*6がすばらしい記事を書いてくださった。

• ブラウザプラグインにも要注意 一太郎の脆弱性、リンクのクリックだけで悪用される可能性も, 高橋睦美, @IT, 2007年10月26日

  脆弱性を発見した同社のCTO、鵜飼裕司氏によると、これらは、過去にゼロデイ攻撃に悪用された一太郎の脆弱性と同程度か、それ以上の脅威レベルだという。

  （中略）

  　「一太郎ファイルは、PDFなどのようにプラグイン経由で、警告なしに自動的に開いてしまう」(鵜飼氏）。つまりユーザーによる動作が介在しなくとも、 Webブラウザで攻撃コードが記述されたファイルへのリンクをクリックするだけで、自動的に攻撃ファイルが開かれ、被害を受ける可能性がある。

  なお、ジャストシステムのアドバイザリには、過去の脆弱性と同様の注意として「身に覚えのない電子メールに添付されている一太郎文書ファイル、並びに、信頼性が保証されていないWebサイトなどにある、出所の不明な一太郎文書ファイルを開かないよう、ご注意ください」と記述されているが、プラグインを介した攻撃の可能性については触れられていない。

  同社によると「特定の操作に限定しない形で注意を喚起したかった」ことがその理由という。

  （中略）

  さまざまなユーザーが利用していることを考えると、脆弱性の公表においては、何が根本的な問題であり、どうすればそれを避けたり、解消できるのかを正確に伝えることが望まれるだろう。この点についてジャストシステムは「今後検討する」としている。

このように、発見者に取材すれば、発見者しか知らない（もしくは発見者にしか言えない）有益な事実が出てくることもあるわけだ。

そして、この影響があってか、IPAの注意喚起文は訂正されている（図8）。

これは以前から書こうと思っていたことだが、JVNの情報が、ネットメディアで扱われるようになったのは喜ばしいことだけども、内容が、JVNに書かれていることそのまま（語順を変える編集程度）という記事があまりにも多すぎる。

速報性を重視して、できるだけ早く記事を出すという考え方も理解できるが、各社横並びで、どこを見ても同じことが書いてあるのでは、報道としての価値があるのか疑問だ。

どうすればいいかは簡単なことで、発見者が公表されているJVNについては、発見者に取材をしてみたらいい。何か、未公表の有益な情報を得ることができる場合もあるだろう。

私もこれまでに何件か、JVNに届け出た脆弱性があるが、一度も取材はなかった。おそらく、他の方々にも取材はいっていないのだろう。

私は、こうして独自に情報発信する術を持っているから、取材されなくてもかまわないが、他の発見者の方々の中には、取材されたら出すような貴重な情報をお持ちの方もあるだろう。

英語圏の脆弱性の報道を見ていると、メディアは必ず発見者の見解を取って紹介している。どうして日本のメディアにはそれができないのか。

plug-inを無効にする方法

顧客がどういう情報を必要としているかに理解が及ばないジャストシステムの製品など、個人的に使いたくないところだが、そうはいっても、役所方面とのお付き合いのある仕事をしていると、一太郎文書が送られてくることもあるので、一太郎ビューアくらいは入れておかざるを得ない。

かといってこのまま使い続けるのは不安だ。ゼロデイ攻撃が4回、事前の発見が2回の、計6回もの任意コード実行の脆弱性が見つかっている。今後も再び発見されそうに思えるところ、ジャストシステムは、plug-inの脅威のことを教えてくれない。実際、私も7月まで、危険な状態におかれていることを知らなかったわけだ。

もっとも、一太郎文書をWeb上に埋め込んで表示する必要性は全くないので、無効にしてしまえばいいのではないか。

以下の方法ですべての脆弱性を回避できるかは確認していないが、Internet Explorerでの無効化手順と、Firefoxでの無効化手順を挙げておく。

Internet Explorerの場合：

1. 「インターネットオプション」で「プログラム」タブを選び、「アドオンの管理」ボタンを押す。
2. 「表示」という見出しのメニューで「Internet Explorerで使用されたアドオン」を選ぶ。
3. 下の枠に表示される項目の中から、「tJsViewx Control」と書かれたActiveXコントロールを選択する（図8）。
   

   図9: 「tJsViewx Control」を「無効」に設定した様子
4. 「設定」欄にある「有効」「無効」の選択肢のところで、「無効」を選び、「OK」ボタンを押す。

Firefox 2.x の場合：

1. アドレスバーに about:plugins と入力してエンターキーを押し、インストール済みplug-inの一覧を表示させる。
2. 「JS文書ビューアプラグイン」の項目のところに書かれているファイル名「Npjsview.dll」を確認する（図10）。
   

   図10: Firefoxのplug-in一覧から「JS文書ビューアプラグイン」を探した様子
3. この名前のファイルをディレクトリ「C:\Program Files\Mozilla Firefox\plugins」の中から探して削除する。
4. Firefoxを再起動する。

追記

高橋記者によるこんなコラムが出ていた。

• Analysis 右から左へ受け流さないで, 高橋睦美, @IT, 2007年10月29日

■ ジャストシステムはどこへ向かっているのか

ジャストシステムが、ユーザの安全確保よりも、何らかの別の目標*1に向かっているらしいことは、次の事例で一目瞭然だろう。

こんな言い回しは他で見たことがない。

脆弱性情報を公表することの目的が、まだ修正版の存在を知らされていないユーザに対してアップデートの必要性を周知することにあるということは、（ユーザの立場で考えれば）誰でもわかるはずだ。それなのに、ジャストシステムは、まず先に、「ご安心ください」と言う。（図1の1つめの矢印部分。）

Kaspersky Internet Security 6.0 および Kaspersky Anti-Virus 6.0のVista対応版プログラム以前の製品（バージョン 6.0.0.306）で5つの脆弱性が発見されています。この問題に対する修正は、3月14日より無償でダウンロード提供しているVista対応版プログラム（バージョン 6.0.2.614）ですでに改修されておりますのでご安心ください。

※Windows XP／2000でお使いの方が対象となります。
※現在ダウンロード、および、店頭で販売している製品は、すでにVista対応のプログラムとなっておりますので、プログラムを入れ替えていただく必要はありません。

すでに改修されているKasperskyの脆弱性について, ジャストシステム, 2007年4月6日

当然、3月14日より前にインストールしてそのままのユーザがいるわけで、「ご安心ください」で済む話ではない。

ジャストシステムは、脆弱性のあるバージョンをまだ使用していると思われるユーザに対して、それに続く後半部分でやっと次のように言っている。（図の2つ目の矢印部分。）

まだVista対応版を入れていただいていない方は、ご面倒をおかけして申し訳ございませんが、速やかにVista対応版に入れ替えてくださいますようお願いいたします。 なお、プログラムの入れ替えが必要かどうかについては、お使いのプログラムのバージョン情報をご確認ください。

すでに改修されているKasperskyの脆弱性について, ジャストシステム, 2007年4月6日

先に言うべきことはこっちだ。

長文を読むのが苦手な一般の人たちが、上から順に目を通して、「ご安心ください」だの、「プログラムを入れ替えていただく必要はありません」という文字を見たら、どういう行動をとるか。

ジャストシステムがガス製品を販売したら死人が出るだろう。

こういった悪い社告の例については、経済産業省の「消費生活用製品のリコールハンドブック」にも書かれている。

良い社告の例が図3にあるように、読者は何をすればいいのか、自分は該当するのかが、すぐに確認できるように書かれているべきだ。

コンピュータソフトウェアのセキュリティ脆弱性のケースでは、これに加えて、どのくらいの危険度があって、回避策はあるかを示すことが重要となる。なぜなら、「危険度が小さければパッチを適用しない」という判断をする人たちがいるからだ。

このことは、IPAの「ソフトウェア製品開発者による脆弱性対策情報の公表マニュアル」に書かれている。

• 「脆弱性情報はこう公表しよう」、IPAがマニュアルを公開, ITmediaエンタープライズ, 2007年5月30日
• 「ソフトウェア製品開発者による脆弱性対策情報の公表マニュアル」などを公開, 情報処理推進機構, 2007年5月30日

ジャストシステムの広報IR室長（NHKニュースで話していた人）はこれらに関心がないのだろう。

ここで気づいたのだが、今回の一太郎の脆弱性のJVNで、「ベンダ情報」の部分が図4のようになっているのが、普通と違う。

普通ならば図5のようになっているはずだ。

外国の会社がジャストシステム（図4）のようになっているのはよく見かけるが、国内の大手企業で、しかも国内からIPAに届出られてJPCERT/CC経由で調整されたものなのだから、ここは図5のようになっていても不思議でない。

この違いはどうしたことだろう？ よくわからない。

それから、「Kaspersky 脆弱性」で検索してみたら、こんな記事が見つかった。上の「すでに改修されている脆弱性」（4月の件）とは別の脆弱性のようだ。

• Kasperskyの無償オンラインスキャナに脆弱性、修正版を公開, INTERNET Watch, 2007年9月11日

  Kaspersky Labでは、すべてのKaspersky Online Scannerのユーザーに対して新バージョンのインストールを求めている。なお、同ツールは、Kaspersky Labs Japanのサイトや、ジャストシステムが開設しているKaspersky製品の情報サイトにおいて日本語版サービスが提供されているが、それらは日本時間の11日夕方時点ではまだ最新バージョンに移行していない模様だ。最新バージョンにするには、いったん英語サイトにアクセスしてアップデートする必要がある。

この件についての告知が、「JUST Kaspersky」のサイトに見当たらない。

なぜ告知しないのだろう？ 告知しなくてもアップデートしてくれると思っているのだろうか？