_ 支配者心

近所の立て看板に「人の子も我が子と思う親心」という生活標語が書いてあって、それを見かけるたびに「望月の欠けたることもなしと思えば」という下の句をつけてしまうんだけど、たぶんその場合は「支配者」と書いて「親」とルビを振る形になるんだろう。

_ のうむ？

今日乗った昼過ぎの埼京線上り快速は30分くらい遅れた。遅れている理由を説明するアナウンスが流れたときにいまいちちゃんと聞き取れなかったのだけれど、どうやら「濃霧のため」と言っていたようだった。浦和は雲一つくらいしかないとてもいい天気だったんだけど、埼京線って大宮の先は、電車が走れないくらいの霧が出ているくらい、浦和とは気候が違うところまでいくんだっけ？　まさか「GNOMEのため」じゃないよね。「JR本部！　埼京線がGNOMEとORGAに電車が襲われている。救援求む！」とか。いや別にX Window方面に向かってもいいんだけど。

_ また警報機が壊れた (13:51)

車上荒らしにあってから取り付けた車載警報機。買ってすぐに故障して交換してもらい、その後感度があまりにも敏感すぎてトラックが通るたびに鳴るのがうざいんで感度を下げてもらい、それ以来しばらく安定していたんだけど、今朝6時前に突然鳴り始めた。

ここ最近誤動作していなかったんで、本物かと思ったんだけど、特にそれらしい形跡はない。しかも警報機を止めてもしばらくするとまた鳴り始める。様子を見ていると、振動も何も全くないのに突然警報機が鳴り始めるといった状況。

朝の6時からそれかよ。ひどい近所迷惑安眠妨害（何度も何度も鳴るんで、周囲の家から人が出てきたり、マンションの窓から様子を見ている人たちがいた）に耐えかねて、音が鳴らないサイレントモード（警報機としての意味がない）にしてみたんだけど、それでもしばらくすると何もないのに鳴り始める。ってことは、また故障かよ。

しかも、時間とともに発生頻度が下がっていき、最終的には30分くらい待ってようやく1回発生する程度になっていたんで、店に持ち込んでも症状を再現するのがとても難しそうな気配。今朝雨が降っていたみたいだから、どこかがショートでもしたのかな。それだと、その後晴れて乾いていくにつれて発生頻度が下がるってのもわかるんだけど。

今日は俺は抜けられない打ち合わせがあるんで、自ら店に持ち込んでいる余裕がない。けど、こんな微妙な症状のものをオクサンに任せても大丈夫だろうか。けど、発生頻度の下がり具合からして、早めに持ち込まないと症状を再現することが難しそうだしな。というわけでオクサンに頼んでおいたけれども、さてどうなることやら。

と書いたところでオクサンから電話がかかってきた。店の方でチェックしてみたけれども配線等に異常がないし、たぶん感度センサーが敏感だったせいではないかと言われて、それで終わりになりそうな気配だったんで、電話を替わってもらってクレーマーモード。なんか最近こういうのが多いなー。外れ引きまくりか。

朝の段階では、振動が全くない（朝6時前の静かで車もほとんど走っていない）状態で、（見ている俺以外）誰も周囲にいない状態で鳴った。感度がおかしいかと思って警報機をオンにして軽く車体を叩いてみたけど鳴らなかった。ある程度強く叩いたら鳴ったんで、感度調整は正常だ。また、警報音が鳴らないサイレントモードにセットしたのに、それでも警報音が鳴った。

などと説明して、しばらくオクサンともども1時間くらい店で症状が出るのを待ち、それでも症状が出ないようだったら、しばらく店に預けておくという方向で話をつけた。うちの近所はとても閑静な住宅地なんで、あんな騒音が二日連続で続いたら、周りの住民の目が冷たいどころの話じゃなくなりそうだし。

それにしても、あそこの店では今までもいろいろありすぎたんで、もう二度と行かなくてすむと思っていたんだけど、また行かなきゃならない羽目になりましたか。ナビとかオーディオとかのレベルだったら、多少何かあってもあの店とは関わらない方を選んだかもしれないけど、警報機はオートロックシステムとかと連動しているんでさすがに放置しておく訳にもいかないしなー。でも最悪、ほかの店で別の警報機に付け替えてもらうことを本気で考えておこうかな。

_ MTの認証Cookieに関する脆弱性とされているものについて (02:38)

「【重要】 第三者による不正アクセスを許す危険性の対策について」で発表された内容について、「Movable Type の脆弱性の件 : NDO::Weblog」のコメント欄あたりでごちゃごちゃ書いていたことをまとめておこう。

今回の問題は結局、

• movable typeのWeb管理ツールでは、認証Cookieとして「ユーザーID」と「パスワードのハッシュ」を組み合わせた文字列を使っている
• その認証CookieはそのままAtom APIを使った外部ツールからの認証処理でも使われている
• もしも認証Cookieが漏れた場合、Web管理ツールやAtom APIインターフェースを通して、管理機能（の一部）を乗っ取られる可能性がある（追加情報：BlogWrite担当さんのコメント）

ということだと理解した。

もしも他に問題があるならば話は変わるが、今回の発表の元になった脆弱性報告を行った人の「「旅行びと日記」日記: Movable Type 3.151以前のセッションハイジャック脆弱性問題」による解説と、JVNによる発表「JVN#74012178 Movable Type におけるセッション管理の脆弱性」およびIPAによる発表「JVN#74012178：Movable Type におけるセッション管理の脆弱性」をあわせてみると、結局それ以上の問題はないように見える。

これは、「漏れてはまずいから漏れないようにしている認証情報（Cookie）が、もしも万が一漏れたら危険なことになりますよ」という話だ。しかし、具体的に「もしも万が一」を突破する手段がない限りは、別に危険ではない。あらゆる認証情報（たとえばパスワードとか）は、「もしも万が一」漏れたら危険なものだ。しかし「万が一漏れたら」というだけでは、ふつう脆弱性とは言わない。具体的に漏れる方法が見つかった段階で「脆弱性」になる。

「あなたのメールパスワードは、他人に漏れないように注意してくださいね。もしも漏れたら他人にメールを読まれちゃいますよ」というだけで、脆弱性とは言わないだろう。具体的にパスワードが漏れる手段が見つかった段階で、それは脆弱性となる。

確かにmovable typeの、認証Cookieがそのまま「無期限に」「複数の認証に」利用できるという設計は、セキュリティ的に安全性が高いとは言えない。しかしそれは「脆弱性」ではなく、「よりセキュリティ的に安全性が高い設計に変更することが望ましい」程度の問題だろう。

脆弱性報告を行った人は、その根拠となる参考文献として高木浩光氏による「安全なWebアプリ開発 31箇条の鉄則（PDF）」を挙げているようだが、その中の「14.セッションIDを使う」において高木氏は、「ユーザIDだけを引数とする方式」については、「致命的な欠陥、認証なしと同等、ファイル丸見え並の危険性」としているが、今回movable typeが採用していた「ユーザID＋パスワードのハッシュ値を引数とする方式」については、「これでもよいが、セッションを使う方式の方がより安全」としている。つまり、この方法でも問題はないわけだ。

ここからは邪推。

上記のような報告を受け、JPCERT/CCもしくはIPAからシックスアパートに対して勧告が行われた。が、上記のような判断を行うとこれは「脆弱性」とは言えない。しかし、シックスアパートの担当者は、そのことをJPCERT/CCもしくはIPAの担当者に理解してもらうことができなかった。あるいはJPCERT/CCもしくはIPAの担当者はそのことを理解できなかった。公表と対処を迫られたシックスアパートは、納得がいかないままに情報を公開した。しかし、納得できていないので、ひとまずポイントとなるキーワードはちりばめたものの、非常に微妙な表現の文章になってしまった。という経緯なのではなかろうか。

というわけで、私はこの件は脆弱性ではないと思います。ただし、認証Cookieの仕様はもうちょっと安全性の高いものに変えた方がいいとも思います。おしまい。

ちょっと修正

• 「ユーザ＋パスワードのハッシュ値を引数とする方式」→「ユーザID＋パスワードのハッシュ値を引数とする方式」
• 「JNAもしくはIPA」→「JPCERT/CCもしくはIPA」。っつーかJNAってなによ。
• 「Web管理ツールやAtom APIインターフェースを通して、管理機能を乗っ取られる可能性がある」→「Web管理ツールやAtom APIインターフェースを通して、管理機能（の一部）を乗っ取られる可能性がある」

_ Re:「ここギコ！: MovableType脆弱性の話」 (16:49)

個人的には（そこまで重大かどうかは別として。緊急度は「低」だと思う）やっぱりこれは脆弱性といってよいのでは、と思います。

まあそう考える人もいるでしょう。元報告者の方およびその報告を受けて対応した方々はそう考えているんでしょうし（でもシックスアパート自体は「脆弱性」ではなく「危険性」と書いているんですけどね。その辺の言葉の選択もビミョー）。

ただ、Webアプリケーションで認証状態を維持する方法としては、一般的にCookieが利用されるものです。そのCookieにどのような情報が含まれるのであれ、そのCookieが漏れた場合は、ある程度の期間において認証状態が乗っ取られる可能性が発生することになります。

そのCookieによる認証をどの程度の期間有効にするかはWebアプリケーションの設計によりますが、ブラウザセッション（ブラウザを閉じるまで）を越えて有効な認証状態を継続するようなアプリケーション（MTでいうところの「情報を登録する?」オプションがあるもの）では、無期限とまでは言わないまでもかなりの期間、認証が有効な状態が継続するでしょう。

そして現在のところ、WebアプリケーションでHTTPセッション（1回のサーバーへのアクセス）を越えて状態を維持する手段としては、機能性・利便性・安全性のバランスにおいてCookieよりも妥当な方法がありません。より安全なSSL＋secure Cookieを利用する方法や、証明書やハードウェアキーなどを利用した方法は、現時点ではいつでも使える手段とはなっていません（もちろんより安全性が必要な場合は、それらを選択するべきでしょうけど）。

つまり、現在一般的なWebアプリケーションで（特にブラウザセッションを越えて）認証状態を継続しようとした場合は、多かれ少なかれ今回movable typeの認証Cookieが持っていたような危険性を持たざるをえないわけです。で、Webアプリケーション側では、漏れたら危険な認証情報をCookieに持たせる代わりに、Cookieが第三者に漏れないようなアプリケーションの設計にするわけです。Cookieが漏れないようにする（入り口に鍵をかける）ことによって、安全性を確保するわけですね。

もちろんCookieがそれほど安全なものでないことは、XSSやブラウザ自体が持つ脆弱性、盗聴の危険性などから、ある程度知られています。そして、そのような危険性への回避策もいろいろとあります。ただし安全性を高める回避策は基本的にはSSLとの組み合わせとなってしまう（利便性が損なわれすぎる）ため、一般向けのアプリケーションではそれに依存した設計はできません。

というわけで、現在のところ「Cookieにはある程度秘密の情報を保存してもいいが、その代わり第三者にCookieが漏れないような設計にする（漏れた場合はそれは脆弱性である）」というWebアプリケーションの設計方針は、（それほど重要ではない情報・機能を扱うWebアプリケーションにおいては）妥当なものだと考えています。おそらく現在稼働しているWebアプリケーションで、そのような設計方針の下に作成されたものは非常に多いのではないでしょうか。

で、私はmovable typeにおいても、基本的には（扱っている情報・機能とのバランスを考えて）上記のような設計は「あり」だと思います。つまり、「Cookieが漏れるような穴がない限りは、Cookieに秘密情報を保存していること自体は問題にならない」という考えです。ただし、より安全性を重視した設計にするならば、Cookieに保存する情報の内容自体ももっと安全な（漏れたときの影響が小さい）ものにするべきだとも思いますけど。

movable typeのような使われ方をしているWebアプリケーションでは、SSL必須にするわけにはいかないでしょうから、今回の問題を解決する方法としては、おそらくランダム性の高い（少なくともAtom APIでは使えない）認証キーをCookieに保存するようにするのでしょう。それでも「情報を登録する?」オプションが存在する限りは、その認証キーはある程度の期間有効でしょうし、その認証キーが漏れた場合はWeb管理ツールを乗っ取られる危険性があります。Cookieに登録されている情報の内容に関わらず、「Cookieが漏れたら危険である」わけです。つまり重要なのは「Cookieが漏れるかどうか」であって「Cookieに記録されている情報」の方ではない、と考えるわけです。

と、なんか長々書いてきたけど、うまい締めが思いつかないんで、ひとまず「まあそういうことなんですよ」って感じで終わっておく。それにしても俺は別に「MTスキー」でも「セキュリティスキー」でもないのに、なんでこんなに一生懸命説明しているんだろうなー。

_ 「「MT に脆弱性」@水無月ばけらのえび日記」より (21:19)

非 SSL で Basic 認証を使っていれば普通に起きていることなので、大して危険ではないような気もするのですが、危険性の評価は利用状況によるでしょう。MT を利用してるのは個人サイトだけではありませんし。

ってあたりがポイントなのかな。確か、商用サービスとか企業向けサービスとかで、MTをより機密度が高い情報サービスと連携させて動くように組み込んでいる事例とかもあった気がするし、そういうマキシマムの危険性を重視した上で「脆弱性」として扱うというのは、ありといえばありかもしれない。

ただ一般ユーザーレベルで取り扱う情報を管理するツールとしては、これを「脆弱性」扱いするのはなんか違うと思う。たとえば（SSLなしで）BASIC認証で管理機能を保護しているCGIなんかは、すべてこれと同じような危険性をはらんでいる（Cookie系のアタックに弱い点を考えると「同じような」というのは言い過ぎか）ことになるわけだから、これが「脆弱性」ならばそれらも「脆弱性」になっちゃうってことだし。

_ 自転車通勤往路

ほぼ一週間休んでケツの具合もだいぶ良くなったんで、今度はちゃんとレーパンを履いて自転車で出発。しかし、足の筋肉の弱りっぷりはただごとじゃないな。道半ばで早くも足がだるくなり始めた。これはしばらくの間はかなりのんびりとリハビリに努める必要がありそうだなー。

• 今日から交通安全週間なのかな？　白バイ＆警察官がたくさん交差点にいた。
• あと警察官が、民間の指導員に対する指導のレクチャーをやっている風景もあちこちでみかけた。

_ 自転車通勤復路