それは脆弱性じゃないと思います、せんせー。

当初僕はmt-xmlrpc.cgi、mt-atom.cgiの実行権剥奪＆mt.cgiのリネームによる対処をポストし、かつ「これで問題ないもんねー」とタカをくくってました。が、naoyaさんのMovable Type の脆弱性の件 : NDO::Weblogやishinaoさんのtdiary.ishinao.net - MTの認証Cookieに関する脆弱性とされているものについて (02:38)などを読んで「ちょっと待てよ」と思いました。

多くの関連サイトを読み進めて自分なりに咀嚼していくうちに、これはアプリケーション(Movable Type)固有の問題に起因した話ではなく、サーバの運営指針としてセキュアにしとくのに越したことはないというレベルの話であり、Movable Typeに新たな脆弱性が発見されたわけではない、と結論することとしました。

Cookieを取得し、かつCGIスクリプトへのパスを知っていれば不正アクセスが可能になるというのは、（ログイン状態を保持する機能を有するなどの）他のウェブアプリケーションにおいても共通のこと。言われてみれば確かにそうです。そしてこれを脆弱性と言ってしまったら、httpsが必須ではない他のウェブアプリケーション全てに同様の脆弱性が存在することになります。

今回「脆弱性」として公開された件に対する対処法としてMovable Type Technotes: 盗聴によるパスワードやCookieの漏洩からの不正アクセスを防止する(1)が参照されていますが、「mt.cgiのパスを変える」対策だけではCookie盗聴を防ぐことは不可能なので、根本的に解決したいならばhttpsを必須にしたり、IPでアクセス制限をしたりといった対応をしなければなりません。

つまりこれは根本的にウェブサーバの設定(=サーバの運営ポリシー)で回避するべき問題であり、Movable Type側の設定(=Movable Typeの脆弱性)云々で回避できるレベルの問題ではない、と。こう考えるに至り、先のように結論づけるに至ったというわけです。

セキュリティに関する様々な議論を目にするいい機会になったのと同時に、(ニュースソース如何によらず)情報は決して鵜呑みにせず、真意を理解した上でアクションを起こすのが大事であることを痛感しました。

いやはや、勉強させていただきました。

＜おまけ＞
それじゃ僕の対策は徒労だったのかというと、まんざらそうでもないんじゃないかと思っています。

Cookie盗聴に関するリスクは相変わらず残っているわけですが、mt-xmlrpc.cgi、mt-atom.cgiの実行権剥奪については「使わないスクリプトは実行権限を与えない」のがウェブサーバ運営の鉄則だと思いますし、mt.cgiのリネームについては「イタズラ目的でのアクセスをある程度防ぐことができる」と考えるからです。

mt.cgiのリネームの目的は、いわゆるソーシャルハッキングの防止です。ブログを見れば「投稿者:ishii」などとログインユーザ名がわかるわけですから、後はmt.cgiにアクセスして、その人が使いそうなパスワードをどんどん入れ続けていけば…その対象が身近な人であればあるほど、あっさりログインできちゃうかもしれません。

そういった「結構低レベルだけど実は最も嫌なトラブル」の防止策にはなると思います。