May 13, 2005

Movable Type の脆弱性の件

[ Movable Type ]
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 の中身を見ればそんなものはすぐにでも分かります。そこにアクセスされたら危険というものはアクセスされないように任意の名前で隠せばセキュアという認識が間違っています。(この辺の語りは高木さんの役割かもw)

mt.cfg の中には、ログインに必要なパスワードであるとか、DB に接続するためのパスワード、それから Cookie の値を何らかの方法で知るための値が記述されているわけではないので、見られたからってサイトが不正アクセスの被害を被るわけではないのです。

見られたら危険、というものだったらそれを、一般のアクセスからは物理的に見れない場所におく、例えばウェブサーバがハンドリングしていないディレクトリに置くとか、それが適切な対処ですが、mt.cfg はパッケージの中ではウェブに公開される可能性のある領域にもともと置かれています。開発者側の判断は、特に mt.cfg が見られたからといって脆弱性が発生するわけではないという認識の元でしょう。見られたら気持ち悪いファイルではあるので、隠しておくに越したことはない、程度のものです。

この話に関しても Six Apart Japan の文書が誤解を招きやすい表現になっているという点は否めないですけれども。

Posted by naoya at May 13, 2005 01:43 PM | トラックバック (14)  b_entry.gif
トラックバック [14件]
TrackBack URL: http://mt.bloghackers.net/mt/suck-tbspams.cgi/1555
Movable Type の脆弱性について
Excerpt: Movable Type Publishing Platform: 【重要】 第...
Weblog: MovableTypeで行こう!
Tracked: May 13, 2005 02:50 PM
全バージョンの Movable Type に脆弱性が... 対応パッチは見送り
Excerpt: SixApart 社、ちゃんと対応してください。と思いましたが、問題はその掲示/アナウンスの仕方にあるようです。
Weblog: Clip & Scrap
Tracked: May 13, 2005 04:16 PM
MovableTypeの脆弱性
Excerpt: 【重要】 第三者による不正アクセスを許す危険性の対策について(SixApart) 第三者による不正なアクセスが発生する条件: 1. 第三者が、Cookieの値...
Weblog: the meager
Tracked: May 13, 2005 05:05 PM
Movable typeに新たな脆弱性
Excerpt: Movable typeに新たな脆弱性が確認されたそうです。これは、第三者がCookieの値を取得し、なおかつmt.cgiのパスが分かれば、第三者による不正なア...
Weblog: Studio md
Tracked: May 13, 2005 05:45 PM
Movable Type の CSRF による脆弱性が公表
Excerpt: Movable Type 3.16 リリースからしばらく経ち、例の CSRF が公表されました。
Weblog: drry+@->Weblog
Tracked: May 14, 2005 01:23 AM
[MT][セキュリティ][脆弱性] MTの認証Cookieに関する脆弱性とされているものについて (02:38)
Excerpt: 「【重要】 第三者による不正アクセスを許す危険性の対策について」で発表された内容について、「Movable Type の脆弱性の件 : NDO::Weblog」...
Weblog: tdiary.ishinao.net
Tracked: May 14, 2005 02:49 AM
Movable Ty
Excerpt: Movable Type の脆弱性の件 を読んで
Weblog: Don'tStopMusic
Tracked: May 14, 2005 04:43 AM
MovableType脆弱性の話
Excerpt: なんかMovableTypeに脆弱性があるとかで盛り上がってるみたい。 遅ればせ...
Weblog: ここギコ!
Tracked: May 14, 2005 09:55 AM
Movable Typeの脆弱性は本当に脆弱性なのか
Excerpt: 先日発表のあったMovable Typeの脆弱性の問題について。 この件について書かれている技術に詳しい方々の記事をみていて、「今回の「第三者による不正アクセス...
Weblog: blog nothing unusual
Tracked: May 14, 2005 01:02 PM
MT脆弱性云々の話
Excerpt: Movable Type Publishing Platform: 【重要】 第...
Weblog: yextlog
Tracked: May 14, 2005 03:56 PM
いっぱい叩かれてしまった訳ですが
Excerpt: トラックバック頂いて気付きましたが、naoyaさんとかishinaoさんといった大御所の皆さんに先日の記事内容について、かなーり叩かれているみたいです。 nao...
Weblog: 「旅行びと日記」日記
Tracked: May 14, 2005 04:02 PM
Movable Typeの脆弱性 発覚!
Excerpt: とうとう出ちゃいましたよ:14: 【重要】 第三者による不正アクセスを許す危険性...
Weblog: 新妻blog(もう新妻じゃないけど)
Tracked: May 14, 2005 07:10 PM
それは脆弱性じゃないと思います、せんせー。
Excerpt: 5月12日にシックス・アパート株式会社から公開されたMovable Typeの脆...
Weblog: spanstyle::monolog
Tracked: May 14, 2005 08:33 PM
脆弱性とセキュリティホール
Excerpt:  Movable Typeの「【重要】 第三者による不正アクセスを許す危険性の
Weblog: Marklet BLOG
Tracked: May 15, 2005 01:29 AM
コメント [14件]

というかこれは、movabletype.jpの発表の仕方がわかりにくいのではないでしょうか?

認証Cookieが漏洩したらまずいのはすべてのWebアプリケーションに共通する問題でしょうし、movabletypeに特に認証Cookieが漏れる原因となる脆弱性があったわけでもないみたいですし、なんでこういう発表をしたんだろう?と謎に思いました。

おそらく、Web管理ツールの認証CookieがそのままAtom APIの認証用にも使える点を重視して「脆弱性」として発表したのかなーと想像していますけど、いまいち釈然としません。

[1] Posted by: ishinao at May 13, 2005 02:48 PM [返信]

どこぞのお偉方からご指摘というお圧力があったのではないでしょうかね

[2] Posted by: naoya at May 13, 2005 02:54 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

[8] Posted by: tociyuki at May 13, 2005 06:51 PM [返信]

mt.cfgを隠さなくちゃという件、僕も自分のブログに書いたのですが、naoyaさんの言うとおり、このファイルが見えても困ることってそんなに多くはないと思います。
ただ、このファイルが見られてしまう可能性があるということに気付かず、例えば、EmailVerificationSecretに普段使っているパスワードをそのまま書いちゃってたりすると、困っちゃうよなーと思いました。ま、これは、そうすべきではない、と言う話しもありますが……。

それより、問題かなーと思うのは、バークレイDBを使っているときのdbディレクトリの制御かなぁ、と思ったりはします。

[9] Posted by: CHEEBOW at May 13, 2005 07:45 PM [返信]

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

[14] Posted by: ryu at May 14, 2005 02:13 AM [返信]
コメントする









名前、アドレスを登録しますか?