Movable typeに新たな脆弱性
Movable typeに新たな脆弱性が確認されたそうです。これは、第三者がCookieの値を取得し、なおかつmt.cgiのパスが分かれば、第三者による不正なアクセスが可能になってしまうというもの。
mdもさっそく対策を...と思ったけど、いきなりSSLにもできないしなぁ。
【追記 2005-05-13 16:50】
どうやら、わたしも含めてですが、ちと過剰反応のよう。NDO::WeblogさんのMovable Type の脆弱性の件というエントリーで
近頃の一般的なウェブアプリケーションでは Cookie によるログインのセッション保持というのをやるので、Cookie の値そのものがパスワードと同等の役割を持っています。それゆえ、(アプリケーションの欠陥で)Cookie が漏れるような事態は脆弱性と言えるでしょうが、今回の件は Movable Type に Cookie 漏洩の脆弱性が見つかったわけではないです。
いやはや、落ち着いて考えてみれば確かに。ニュースサイトにまで掲載されたから、余計に焦った。そもそも、Six Apartの発表の仕方もどうかと思うんですが...アレを読んだら、速攻でなんらかの対策をしないといけないような気がします。で、そんなことより、mt.cfgが見えてしまう方がよっぽど問題らしい。
つまるところご自分のmt.cfgがブラウザで開くかどうかをまずチェック。開いてしまうのであれば、方法はいろいろあれどまずは早急にマニュアルを参考にmt.cfgを保護することをおすすめします。
mt.cfgをかくさないと！おかわり！
で、自分のmt.cfgをブラウザから開いたら、バッチリ見えているではないか。早速参考にさせていただき、.htaccessを使って隠しました。
てなわけで、ここからは必要に応じてと言うことで...。
【追記 2005-05-13 14:40】
Six Apartから発表された、Movable Typeの「【重要】 第三者による不正アクセスを許す危険性の対策について」の対策をしなければならない。でも、「AdminCGIPathを追記して....」はやらない方が良いっぽい。で、うちの暫定対処方法の覚え書き(MT3.151)。
.htaccessによるユーザー認証
TBいただいた*mt3::MRU様の「【緊急】【その他の対策】 第三者による不正アクセスを許す危険性の対策について」を参考に、.htaccessによる認証を設定する方法。
さて、ここで公式サイトとは違った穴埋めについてですが、任意のディレクトリに.htaccessを設置でき、ユーザ認証がかけられる場合、mt.cgiのディレクトリに以下のような.htaccessファイルを置くことにより、応急処置とすることができます。
<Files mt.cgi> AuthName "適当な認証名" AuthType Basic require valid-user AuthUserFile /認証ファイルへのパス（公開しているディレクトリ外を強く推奨）/.htpasswd </Files>
.htaccessが使えなければダメですが、基本的な事ですし、応用範囲も広くてイイんじゃないかと。mdはこの手のものが軒並み苦手である。バッチシ参考にさせていただきました。ありがたやありがたや...。ただし、クイックポスト（Bookmarklet)が使えなくなるらしい。他のウィンドウで認証させておけば使えるそうです。mdは使っていないから問題ないですが。
mt.cgiのファイルネームを変える
MTユーザーがそろいも揃って「 mt.cgi 」なわけであるから、これを変えちゃえばいいんである。早速変更してみたら、アッサリ動いた。がしかし、「これだけではダメだ」という人と「このままでも良い」という人といらっしゃるんである。方々調べましたが、どうやらこのままでも良いみたい。
例えば、「 mt.cgi 」を「 rename.cgi 」に変えたとする。コレが第三者にバレなければいいんですが、残念ながらデフォルトだとバレてしまうということらしい。それは、検索用テンプレート「 default.tmpl 」の「 <$MTEntryEditLink$> 」タグに原因があるという意見。
検索用テンプレートの問題？
検索のテンプレート( / MTをインストールしたディレクトリ /search_templates/default.tmpl )とは、MTの管理画面からは編集できないという、よくわからない仕様の検索用テンプレートファイルである。なので、見た目はいじっても、MTタグまではいじっていない人も多い。そんなmdもそうである。で、default.tmplの中に<$MTEntryEditLink$>というMTタグがある。これがくせ者で、せっかく「 mt.cgi 」をリネームしても、ここからリネーム後の「 rename.cgi 」がバレるらしい。
しかし、mdのところでは「 mt.cgi 」を「 rename.cgi 」とリネームしても、default.tmplの<$MTEntryEditLink$>部分は、「 mt.cgi 」のままになっている。ていうか、<$MTEntryEditLink$>って何すか？
<$MTEntryEditLink$>タグとは？
で、買おうか買うまいか散々悩んだけあげくワンクリックしてしまったが、実は全然読んでいなかった「Movable Type公式タグリファレンス
一見便利な<$MTEntryEditLink$>ですが、使っている人がどれだけいるかは疑問。なぜなら...
- 編集したいエントリーを検索から探すことは、まずない（と思う）。
- <$MTEntryEditLink$>がなくても、エントリーを編集できないわけではない。フツーに編集すればいいだけである。
- <$MTEntryEditLink$>がなくても、検索機能は動作する。
- <$MTEntryEditLink$>がなくても、閲覧者にはなんの問題もない。
というわけで、心配な人は<$MTEntryEditLink$>を消せばよい。ていうか、消す必要もない。あなたさえこの機能を使っていないのであれば、「mt.cgi」を「xxxxx.cgi」とリネームしようが、検索ページの[Edit]のリンク先は「mt.cgi」のままである。試しに、mt.cfgの「# AdminScript mt.pl」部分のリマークを外し、「AdminScript mtxxxx.pl」にしてみたら、検索ページの「mt.cgi」部分が「mtxxxx.cgi」に変わる。
結論
暫定的な対処なら、mt.cgiをリネームするだけでいいような気がします。心配なら.htaccessで認証かけちゃうと。
なお、いろいろなサイトを巡回したんですが、中でもspanstyle::monologさんの「MovableTypeに脆弱性が発見されました」というエントリーが参考になりました。感謝！。
ブラウザのクッキー機能をオフにする
一番確実なのはこれかもしれない。試しにやってみた。IEなら、「ツール」→「インターネットオプション...」→「プライバシー」と進み、スライダーを最高（全てのCookieをブロック）にすればいい。
しかしこれでは、MTの管理画面で何かする度にIDとパスワードの入力が発生する。確実だが、かなりうっとうしい。1日1エントリーぐらいだったらいいけど、たくさん書く人には、鋼のような忍耐力が必要である。鋼のような忍耐力など持ち合わせないmdが、あっさり却下したのは言うまでもない（笑）
いちおーバックアップを取っておく
エントリーのバックアップも取っておく。まぁ、たいしたエントリーなんて無いんですが（ぼそ）
以上ここまで
他にもいろいろな方法があるとは思いますが、いずれにせよ、この問題にも対応したMovable Type 3.16日本語版が、6月上旬登場とアナウンスされている事もあり、あんまりいじってもどーかーなーなんて...ええそうです、本当は面倒くさいだけです（笑）。
