Movable Type(ムーバブル・タイプ)の脆弱性により、第三者による不正なアクセスが可能であることが確認されました。Movable Typeのセッション管理で使われるCookieの値に、ハッシュ化されたユーザーアカウント情報が含まれており、以下の条件を全て満たした場合に、第三者による不正なアクセスが可能になります。
というアナウンスが出ていてるのですが、これに関してメディアとか巷の blog で過剰に反応しているものが散見されます。
が、アナウンスで赤字で強調し指摘れてるところを良く読んでからも分かるとおり、これは Movable Type そのものの脆弱性ではないですし、そもそも脆弱性なのかどうかも怪しいという話です。
第三者が、Cookieの値を取得する。
Cookie の値を取得されたら、Movable Type に限らず大概のどんなブログ、どんなツールでも不正アクセスが可能です。(AtomAPIとログインパスワードが..とありますが、実際には Cookie を抜かれたらその Cookie を仕込んで mt.cgi そのものにログインが可能です。)
近頃の一般的なウェブアプリケーションでは Cookie によるログインのセッション保持というのをやるので、Cookie の値そのものがパスワードと同等の役割を持っています。それゆえ、(アプリケーションの欠陥で)Cookie が漏れるような事態は脆弱性と言えるでしょうが、今回の件は Movable Type に Cookie 漏洩の脆弱性が見つかったわけではないです。
Cookie を抜かれないために http から https にするとか、それはもう Movable Type の問題ではなくそのシステムを個人としてどうするかという問題ですね。
技術について詳しくない個人の方はともかくとして、メディアの人はもう少し考察してから記事を書くなりなんなりした方がよいんじゃないでしょうか。
追記
mt.cfg を隠さないとやばい、見たいな話にもなっています。確かに人に見せるような代物ではないので見えないように対処を行っておいたほうが良いとは思いますが、これも見えたからといってじゃあそのサイトが何か問題を突かれて云々かというとそういうものではないです。
mt.cgi のパスが知れてしまうと問題、という認識は間違いです。mt.cgi は普通コメントとかトラックバックとかの cgi と同じパスに置かれているのだし、HTML や rsd.xml の中身を見ればそんなものはすぐにでも分かります。そこにアクセスされたら危険というものはアクセスされないように任意の名前で隠せばセキュアという認識が間違っています。(この辺の語りは高木さんの役割かもｗ)
mt.cfg の中には、ログインに必要なパスワードであるとか、DB に接続するためのパスワード、それから Cookie の値を何らかの方法で知るための値が記述されているわけではないので、見られたからってサイトが不正アクセスの被害を被るわけではないのです。
見られたら危険、というものだったらそれを、一般のアクセスからは物理的に見れない場所におく、例えばウェブサーバがハンドリングしていないディレクトリに置くとか、それが適切な対処ですが、mt.cfg はパッケージの中ではウェブに公開される可能性のある領域にもともと置かれています。開発者側の判断は、特に mt.cfg が見られたからといって脆弱性が発生するわけではないという認識の元でしょう。見られたら気持ち悪いファイルではあるので、隠しておくに越したことはない、程度のものです。
この話に関しても Six Apart Japan の文書が誤解を招きやすい表現になっているという点は否めないですけれども。
というかこれは、movabletype.jpの発表の仕方がわかりにくいのではないでしょうか？
認証Cookieが漏洩したらまずいのはすべてのWebアプリケーションに共通する問題でしょうし、movabletypeに特に認証Cookieが漏れる原因となる脆弱性があったわけでもないみたいですし、なんでこういう発表をしたんだろう？と謎に思いました。
おそらく、Web管理ツールの認証CookieがそのままAtom APIの認証用にも使える点を重視して「脆弱性」として発表したのかなーと想像していますけど、いまいち釈然としません。
[1] Posted by: ishinao at May 13, 2005 02:48 PM [返信]「発表の仕方が悪い」に一票です。
mixx の件など前例も出ていることから事前に問題意識を促したということかもしれませんが
公式にアナウンスするなら、誤解のないようにもう少し分かりやすく掲載すべきだったと思います。
私はあの掲示を読み、「まずい、対応しなければ」と思い、色々調べてしまいました。
お陰で全然別の問題を発見できたので助かりましたけど...
# mt.cfg が裸で見えるようになってました。
# Options ExecCGI とかしているホスティングでMT使っている人いるでしょうから
# 潜在的にこの問題を抱えたサイトって結構ありそう...
話がそれました。
事前に情報を発信したことは評価できますが
コミュニケーションという意味では誤解が生じやすい文面だと思います。
naoya さんの指摘で内心ほっとしています。
ありがとうございます。
オンラインのニュースサイトや、個人のサイトからは「MT 危険」とかし読み取れませんから。
[3] Posted by: やまざき at May 13, 2005 04:04 PM [返信]脆弱性がほげほげという見出しは誤解を招きやすいですね。
その一方で、システムの知識が多少なりともある人であれば脆弱性の内容を見て、それがどの程度のものかは理解できると思うので、具体的にどういう脆弱性なのかというのを考えてみたら、そんなに大騒ぎするほどのものでもないというのはすぐに分かるはず。
こういう話題は、その手の知識がある人が情報を広げていきそうでない人に届くというものなので、メディアなり自分の blog に掲載する本人はある程度その辺りを自覚するべきではないかと思いますよ。
文章の内容が悪い元記事が悪いというのと、その内容を検証することなしに見出しだけで脆弱性だ！脆弱性だ! と大騒ぎするのは、同じようなものです。
[4] Posted by: naoya at May 13, 2005 04:35 PM [返信]MTには詳しくないのですが、ITMediaの記事には
＞ このCookieの値は、Atom APIによるログイン時のパスワードとしても利用されている
とかかれています。
だとすれば、普通のセッション処理ではなく、ユーザー毎に毎回決められたcookie値しかセットしてないということでしょうか？
(通常はログアウトするとセッションリセットしますよね)
もしそうなら脆弱性といわれてもしょうがないと思いますけどねー。
記事の書き方に問題があるというのは同意ですが。。
[5] Posted by: typester at May 13, 2005 05:12 PM [返信]> システムの知識が多少なりともある人であれば脆弱性の内容を見て、それがどの程度のものかは理解できると思う
というのは結構微妙な気がします。あの内容を「脆弱性」と発表されることで、私は文面から読み取れない（具体的に書けない）潜在的な「脆弱性」が存在する可能性を疑っていました（というか今でも疑ってます）。
「漏れてはまずいから漏れないようにしている情報が、もしも万が一漏れたら危険なことになりますよ」ってのはふつう脆弱性情報じゃないと思いますし、それを脆弱性と言うのだから他にも何かあるのかなー、と。
[6] Posted by: ishinao at May 13, 2005 05:39 PM [返信]なるほど、深読みは確かにあるかもしれないですね。セキュリティ関連の話の場合は、既存のサイトに影響ないように exploit を示さずに微妙に分かりにくく説明することも多いですしね。そう考えるとそうかも。
ちょっとコード見てみたけど Cookie の値は固定かもですね。ま、そこが問題だとしたら、それはそれでまた別の問題ないんじゃないかとおも思います。
[7] Posted by: naoya at May 13, 2005 05:43 PM [返信]> それはそれでまた別の問題ないんじゃないかとおも思います。
その通りだと思います。
author.dbのpasswordフィールド(crypt関数によるDESハッシュ)の内容を
クッキーにまんまでいれていることの方が問題だと思います。
http://d.hatena.ne.jp/tociyuki/20050513/1115961428
mt.cfgを隠さなくちゃという件、僕も自分のブログに書いたのですが、naoyaさんの言うとおり、このファイルが見えても困ることってそんなに多くはないと思います。
ただ、このファイルが見られてしまう可能性があるということに気付かず、例えば、EmailVerificationSecretに普段使っているパスワードをそのまま書いちゃってたりすると、困っちゃうよなーと思いました。ま、これは、そうすべきではない、と言う話しもありますが……。
それより、問題かなーと思うのは、バークレイDBを使っているときのdbディレクトリの制御かなぁ、と思ったりはします。
mt.cfg の話題を見たときに、スパム対策で mt-comments.cgi や mt-tb.cgi を
リネームしている場合に簡単にばれちゃうな、と思いました。
HTMLをパースするよりは簡単、という程度ですが。
逆に、もし mt.cfg を見てスパム打ってくるツールがあったら、だませるかも知れませんね(^^
[10] Posted by: ooba at May 13, 2005 08:29 PM [返信]どうやら
http://tdiary.seesaa.net/article/3600409.html
が発端らしいですね。
ただこの問題だけだとしたら、これは「脆弱性」というよりは、「セキュリティ的に望ましくない設計」程度のもののような気がします。改善するべき問題ですけど、これを脆弱性というと、secure Cookieを使った認証維持以外の方法すべてが脆弱性になってしまいそう。
[11] Posted by: ishinao at May 14, 2005 01:06 AM [返信]なんだか盛り上がってますが。
1. アプリケーションに欠陥があり脆弱性があるということ
2. アプリケーションとは別の点で、脆弱性になりえる点があるということ
3. アプリケーションとは別の点で、使用者の不注意によっては脆弱性が発生するということ
4. 脆弱性とは異なる話題
というのを分けて考えた方が良さそうですね。で、今回の件に関しては mt.cfg の件は 3 もしくは 4 に当たり、Cookie の中身の件は、実はどれにも当たりませんね。
Cookie の値が固定であるとか、crypt されたパスワードが収まっているとかいうのは、Cookie が漏れたときに表明化する問題であって、それを言うなら POP のメールとかその他、パスワードやセッションIDを平文で流すすべてのアプリケーションは脆弱だ! という話になってしまいます。
ishinao さんの指摘にある通りだと思います。
[12] Posted by: naoya at May 14, 2005 01:15 AM [返信]ishinao さんのコメントにあるURLの文書読んでみましたけど、なんでしょうね、挙句には Perl が悪いみたいな話にまで飛躍してますし。
なんてこったい。
[13] Posted by: naoya at May 14, 2005 01:35 AM [返信]「脆弱性」って微妙な言葉ですよね。。
mixiのCSRFも「え、これ脆弱性なんだ・・・」
って感想が正直なところでした。でも、
実害も出ているし、インパクトも大きいので
脆弱なんでしょう。という観点からいうと、
今回の件は、脆弱というのはオーバーのような
気がします。指摘した人のオナニーのようなw
perlうんぬんいってるしw