2007年4月
2007年4月30日(月曜日)
東芝HDD&DVDレコーダーの脆弱性はバリバリ現役
東芝の RD-XS34 ってのは……「JVN#E7DDE712 東芝製HDD&DVDビデオレコーダーへ認証なしでアクセス可能 (jvn.jp)」の該当機種ですね。いや、何故か Google 検索で Proxy な URL がヒットしてしまったので……。いまだに現役で Open Proxy になってしまっている機器があるということですね。
経緯としては、Google で普通に検索したら本家サイトの他になんかよく分からないミラーコピーっぽいものがヒットし、なんだこれと思って URL を削ってみたら RD-XS34 の設定画面だったという流れです。
で、その画面では普通に録画予約されている番組一覧が見えたりしたわけですが、なんか「本体設定」という項目を見るとメールの設定とかいう項目がありまして。そこには POP3 のアカウント名とかパスワードとか並んでいるのですが、そのパスワードが、これ input type="password" なので見えなくて安心……なわけない。orz
こういうのを発見してしまった場合はどうしたら良いのでしょうかね。IPA の方に相談してみますかね。
- 「東芝HDD&DVDレコーダーの脆弱性はバリバリ現役」へのコメント (4件)
関連する話題: 情報セキュリティ早期警戒パートナーシップ / IPA / JPCERT/CC / セキュリティ
2007年4月28日(土曜日)
Amazonの証明書が期限切れ
Amazon アフィリエイトのレポート画面にログインしようとしたら、証明書の警告が。
何をやっているのやら……。まあ、個人的には Amazon アフィリエイトのレポート画面は HTTPS ではないつもりで使っていますので、どうということはないのですが。
2007年4月27日(金曜日)
苺ましまろ5
苺ましまろ5巻 (www.amazon.co.jp)
前巻から 2年ぶり。しかも手に取った瞬間「薄っ!」と思ってしまったわけですが、中身は面白かったです。特に episode49 の美羽はあまりにもシュール。
脆弱性の呼称
「インジェクション系攻撃への防御の鉄則 (itpro.nikkeibp.co.jp)」。最終回ですか。
HTTPヘッダー・インジェクションと非常によく似たぜい弱性パターンとして，「メールの第三者中継（注4）」がある。これは，HTTPレスポンス・ヘッダーではなく，メール・ヘッダーにおいて改行によるメール改変が可能となるものである。
（注4）CrLfインジェクションなどと呼ばれる場合もあるが、「安全なウェブサイトの作り方改定第２版」の表記に従った。
「メールの第三者中継」は結果、「CRLFインジェクション」は手法に注目した呼称で、両者の指すものは必ずしも同じではないと思います。たとえば、送信フォームに以下のような input要素の記述があったりすると……。
<input type="hidden" name="to_mail" value="info@example.com">
見た瞬間にかなり濃厚な第三者中継の気配が漂ってくるわけですが、ここで連想される手法は「CRLF をインジェクションする」というものではないでしょう。脆弱性の呼称はいろいろありますが、原因と手法と結果とを峻別していないのでややこしいのですよね。
※そもそも、「第三者中継」は脆弱性なのかどうかという議論もあるのかもしれません。とある ISP のメールフォームなどは、ポリシーとしてあえて第三者中継を許しているとしか思えませんので……。
関連する話題: セキュリティ / 狙われるWebアプリケーション / ITpro
2007年4月26日(木曜日)
crossdomain.xml の DTD
Flash でデータのクロスドメイン参照をしたい場合、参照先のサーバに crossdomain.xml が置いてあって参照を許可してあれば取れることになっています。「Macromedia Flash Player 7 におけるセキュリティの変更について (www.adobe.com)」を見ると、以下のような文書型宣言をするようです。
<!DOCTYPE cross-domain-policy SYSTEM "http://www.macromedia.com/xml/dtds/cross-domain-policy.dtd">
で、このシステム識別子の URL にはちゃんと DTD が置いてあるのですが、先頭が XML 宣言になっていてびっくり。
まあ、DTD の中に処理命令が出現しても問題なさそうな気もするのですが、ちょっと想定外でした。
2007年4月25日(水曜日)
JVNがリニューアルされた
JVN (jvn.jp)がリニューアルされたようですね。
サイトをリニューアルすれば常連のユーザが戸惑ったりするのはいつものことで、一時的に評価が下がるのは当然のことです。が、今回はそれを差し引いても読みにくい印象があります。「ベンダー一覧 (jvn.jp)」が 2カラムレイアウトにしか見えないのは別に良いのですが (ホントは良くないのでしょうが私は全く使わないページなので気にしない)、肝心の脆弱性の詳細ページが非常に読みづらいのが気になります。見出しのレベルがわかりにくく、どの見出しがどこから何処までにかかっているのかがわかりにくいからだと思います。
たとえば、「JVN#91706484 Trac におけるクロスサイトスクリプティングの脆弱性 (jvn.jp)」のページには「詳細情報」という見出しがあるのですが、どこからどこまでが「詳細情報」の内容なのかが分かりません。……これ、別に無理なこと言ってる訳じゃないと思うのですよね。というのも、同じ脆弱性の情報が「JVNDB-2007-000200 Trac におけるクロスサイトスクリプティングの脆弱性 (jvndb.jvn.jp)」というページにもあり、こちらは普通に読み取れるレベルになっていますので。
そもそも、同じ情報を見せるのに、何故異なるフォーマットで二つのページを用意するのかが理解しがたいわけで。しかも、出ている情報の内容は一部異なるようなので、全ての情報が見たかったら両方見ろ、ということになります。まとまらないものなのでしょうか。
※なお、これは前からなのですが、IPAにもまた別に「JVN#91706484 「Trac」におけるクロスサイト・スクリプティングの脆弱性 (www.ipa.go.jp)」というページがあるので、都合 3ページ読むことになるという……。orz
……というわけで、上流での情報設計やビジュアルデザインがユーザビリティを大きく左右するのだなぁ、ということが再認識できました。
2007年4月24日(火曜日)
しょこたん写真集
会社にて、しょこたんの写真集なるものを見せていただきました……中川翔子×蜷川実花写真集 『しょこれみかんぬ』 (www.amazon.co.jp)
blog 更新頻度が高すぎる人というイメージしかなかったのですが、ちゃんと (?) こういう活動もされているのですね。
関連する話題: 与太話
2007年4月22日(日曜日)
2007年4月21日(土曜日)
届出状況2007Q1
「ソフトウエア等の脆弱性関連情報に関する届出状況[2007年第1四半期（1月～3月）] (www.ipa.go.jp)」。以前は「PDF読め」というだけでしたが、今回は HTML で概要まで読めるようになっていて、読みやすくなりましたね。
※しかし詳細はやっぱり PDF にしかなく、その PDF はあんまり改善されていないですね。Excel が悪いような気もしますが全体的にグラフが読みにくく、特に P11 の積み上げ棒グラフは難易度高すぎです。
また、届出対象のウェブサイト数で見ると、累計578 サイトに対して届出があり、一つのウェブサイトに対して1 件の届出があったものは86%、同一ウェブサイトに2 件～4 件の届出があったものが12%、5 件～9 件が1%、10 件以上が1%ありました（図4）
あー、枝番って件数としてはそれぞれでカウントされていたのですね。
しかし、一つのサイトで 10件以上というのはスゴイです。ふつう、脆弱性を発見したサイトの使用は中止すると思うので、連続で見つけてしまうことはあんまりない……と言いたいところですが、実は良くあるのが届出中の「6) ウェブサイトの連絡窓口」を書くために連絡先を探していたら追加発見してしまうというケースです (特に連絡窓口のフォーム自体が脆弱な事が多い)。そんなわけで、1回の届出で 2件というのはけっこう良くありますが、10件とは……。
……と思ったのですが、よくよく考えたら「1回の届出で10件」という条件ではないので、けっこう普通にあり得るのかも。
※なにをもって「一つのウェブサイト」とするのかも不明ですね。たとえば *.nifty.com と *.cocolog-nifty.com はドメインが違うから別のサイトなのか、どちらもニフティのサイトということで一つのサイトという扱いなのか……。
関連する話題: セキュリティ / IPA / JPCERT/CC / 情報セキュリティ早期警戒パートナーシップ
2007年4月20日(金曜日)
hatomaru.dllの脆弱性を修正
hatmoaru.dll の脆弱性を修正しました (したつもり)。
けっこう根本的なところの処理が変わったので、いろいろ不具合が起きるかもしれません。ちょっと様子を見て安定しているようなら OK ということで、脆弱性の詳細 (といってもショボイ話なのですが……) についても公開しようと思います。
関連する話題: hatomaru.dll / セキュリティ
2007年4月18日(水曜日)
この RSS は脆弱かも
この日記の RSS がおかしくなっているというご報告をいただいたのですが (ありがとうございます)、調べてみたら、なんと RSS 内の link 要素の URL を任意のホストのものに書き換えられてしまう脆弱性が存在することが分かりました。orz
hatomaru.dll 内で絶対 URL を出力するロジックに問題があるのですが、RSS 以外では全て相対参照にしているはずなので、RSS 以外では問題は起きていないと思います。逆に言うと、RSS に出力されている URL は改竄されている可能性があります。できるだけ早く修正しようと思いますが、直るまでの間は脆弱なままで運用しますので、RSS をご利用の方はご注意ください。
※追記 : IIS 側の設定をいじって対症療法を実施したので、とりあえず大きな問題はなくなったと思います。が、副作用として HTTP/1.0 でのアクセスができなくなっているかもしれません。まあ HTTP/1.0 は捨てでも良いかなと……。
関連する話題: hatomaru.dll / セキュリティ
2007年4月17日(火曜日)
Smarty のいろいろなところで任意の PHP コマンド
「【PHP TIPS】 27. Smarty内でPHP関数を使う (itpro.nikkeibp.co.jp)」。Smarty には「PHPタグ」というものがあって、その中で任意の PHP コマンドが使えることは有名です。が、実は PHPタグを使用しなくても任意コマンドが実行できるという話……で良いのですかね。$security_settings (smarty.php.net)を見ると、何を許可するのか細かく設定できるみたいですね。
実体参照と文字参照
「まだまだあるクロスサイト・スクリプティング攻撃法 (itpro.nikkeibp.co.jp)」。第三回ですね。
<P style="{ color: expression('blue') }"> /* 実体参照 */
それも実体参照ではありませんね……。それは文字参照ではありますが、文字実体参照ではなく数値文字参照のほうです。
実体参照というのは実体宣言で定義した実体を参照しているから実体参照と呼ばれるのです。符号化文字集合のコードポイントを直接指定する数値文字参照は、実体参照ではありません。ちゃんと使い分けたいですね。
※XML の場合は & などはいちいち宣言しなくても使えることになっているのですが、それも "Predefined" という扱いですから……。
※仕様の "24 Character entity references in HTML 4 (www.w3.org)" を読むと実体宣言の中に数値文字参照が出現している様などが見られるので、そう間違えたりしなくなると思いますが、Web のプロでない人にそこまで求めるのは酷かな……。
関連する話題: HTML / セキュリティ / 狙われるWebアプリケーション / ITpro
私物PCを調査しようとする会社
「会社が個人PCを調査することに同意しますか? (slashdot.jp)」という話、興味深いですね。
もちろん、裁判所の発行した令状がない限り、同意なしに家宅捜索なんてできませんが……「何で同意しないの? やましいことがあるんじゃないの? 評価下がるよ?」という圧力で、無理矢理同意させられるというパターンはありそうですね。
私の場合、私物 PC を見られると、未公表かつ未修正の脆弱性関連情報がざくざく出てきてしまうのが困りもの。
※逆に、「いやー、経済産業省告示で見せちゃいけないことになってますんで、どうしても調査したいなら経済産業省から許可取ってください」という主張で何とか切り抜けられるかなぁ。
関連する話題: プライバシー / 情報セキュリティ早期警戒パートナーシップ
2007年4月16日(月曜日)
証明書の失効
「IE 7の普及でサーバ証明書失効によるトラブルが表面化する (takagi-hiromitsu.jp)」。
サーバ証明書が失効とされるのはどういう場合になのだろうか。また、どのくらい起きているのだろうか。
とりあえず「当該サイト」の CRL配布ポイントは http://crl.verisign.com/RSASecureServer.crl (crl.verisign.com) なので、それを見てみると現時点でその CA が失効させている証明書の数は分かりますね。
……と思ったら、なんか Windows の UI が駄目駄目で数とか数えられる状態じゃないんですけど。リストのスクロールバーの感じからすると、とってもたくさんあるみたいです。
※CRL配布ポイントは証明書に書いてありますので、証明書を表示すればすぐ参照できるのですが、IE7 のインターフェイスだと証明書を表示することもできないのでしんどいですね。
ちなみに、RFC3280 では、どういう場合に CRL にリストされるのかについて一部例示されています。
3.3 Revocation
(～中略～)
Such circumstances include change of name, change of association between subject and CA (e.g., an employee terminates employment with an organization), and compromise or suspected compromise of the corresponding private key. Under such circumstances, the CA needs to revoke the certificate.
「名前が変わった」などは穏健ですが、秘密鍵が怪しくなった場合も失効の対象になるわけです。まあこれは当然というか、秘密鍵が漏れたことが発覚したら速攻で証明書を止めないといけないわけでして、CRL はそのためにあるようなものでしょう。「秘密鍵が詐欺師に渡った」という理由で失効している可能性もあるわけですから、この警告が出たときはかなり危険だと考えた方が良いと思います。
さらにベリサインの規約の記述を発見。
第5条 失効
利用者が自己の秘密鍵またはその秘密鍵を保護している起動データの危殆化を発見したか、そう判断する理由がある場合、または証明書に記載された情報に誤りがあるか、変更があった場合、もしくは登録した組織名・ドメイン名を変更した場合、利用者は、その旨を日本ベリサインに直ちに通知し証明書の取消しを要請すると同時に、当該証明書に依拠しているか、または当該証明書を利用してサービスを提供し、もしくは当該証明書を参照し検証可能なデジタル署名に依拠していると合理的に予測しうるすべての者にその旨を通知しなければなりません。日本ベリサインは、日本ベリサインが発行する請求書を利用者が受領後45日以内に所定額の支払いをしない場合、その証明書を取消すことができます。さらに、日本ベリサインは、シールをインストールした利用者がベリサインセキュアドシール・ライセンス契約に定める利用者の義務もしくは本規約に定める重大な義務を履行しない場合、または利用者がVTNのセキュリティもしくは完全性を危険にさらしたか、そのおそれがあると日本ベリサインが判断した場合、利用者の証明書を取消すことができます。
※ちなみに「危殆化」は「きたいか」と読みますが、これは compromise の訳語です。暗号方面には疎いもので、最初読めませんでした。orz
西武バスの停留所は喫煙可能になったらしい
健康増進法の施行後、西武バスの停留所は全面禁煙になったものだと思っていました。当初はそういう車内アナウンスも流れていましたし、禁煙マークも貼ってあったりしましたので、まがりなりにも取り組んでいるのだなぁと思っていました。
が、いつの間にか停留所で喫煙して良いことになったようですね。乗務員が停留所で喫煙していたのですから間違いないと思います。
※雨が降っているときは避難するのもしんどいので、非常に厳しいです。
関連する話題: たばこ
2007年4月13日(金曜日)
飲んだり
普段あんまりお酒は飲まないのですが、いわいさん (iwaim.beering.be)に誘われたりしたので、維如星(うぇい・るーしん)さん (luxin.blackcats.jp)と narukamiさん (abelcain.net)と 4人で飲んだりしました。
実は煙草が苦手なので飲み屋は苦手なのですが、今日は参加者に喫煙者がいなかった上に、周囲にも喫煙する人があまりいませんでしたので、なかなか好調でした。美味しかったです。
ところで、なんか酒の勢いで「今週はうっかり脆弱性を発見しすぎて5件くらい届け出てしまった」などという話をしてしまいましたが、帰ってきてからちゃんと見たら……
……ホントは 7件でした。まあ誤差の範囲のような気もしますが、いちおう訂正。
※ちなみに 1日10件ということもありましたので、今週がめちゃくちゃ多いというわけでもありませんが、多めな感じではありますね。もちろん、1週間以上何もない、ということもよくあります。
関連する話題: 与太話 / 情報セキュリティ早期警戒パートナーシップ
IE7 でフォームに値を入れて印刷プレビューすると……
「葉っぱ日記 - 対策遅らせるHTMLエンコーディングの「神話」：ITpro (d.hatena.ne.jp)」のコメント欄ですが、
というか、<input>に「`」だけ入れて印刷プレビューでHTMLが崩れるIEがそもそも間違いだと思います。』
さりげなく書かれていますが、明らかに IE の不具合ですね。IE7 であっさり再現しました。
関連する話題: Internet Explorer
2007年4月11日(水曜日)
地頭
もじぴったんDS (www.amazon.co.jp)
先日の話には続きがあって、別の人がその後「これなんて読むんですか?」と発言したという……。しかもその発言者は詰め込み教育の世代 (自称) でして、この手の単語をひたすら暗記するということをやってきた世代のはずなのですが。
※まあ、ゆとり教育だろうが詰め込み教育だろうが、人によりけりということだと思いますが。
文字参照とエンコードとエスケープ
「対策遅らせるHTMLエンコーディングの「神話」 (itpro.nikkeibp.co.jp)」。……徳丸さんの記事第二弾。
注1）実体参照（entity reference）というのが正式だが，あまり普及していない用語なので，HTMLエンコードという用語を用いる
(～中略～)
HTMLエンコードというのは，例えば「&」「<」「>」「"」といった，HTMLとして特殊な意味を持つ文字（特殊文字またはメタ文字）を，意味を持たない別の文字列に置換することである。
この注釈はいらないでしょう。「メタ文字を、意味を持たない別の文字列に置換すること」を実体参照とは言いません。もちろん HTML の仕様には「HTMLエンコード」などという言葉は出てきませんが、ここではサーバ側での変換処理のことを呼んでいるわけですから、無理に SGML/XML の仕様で使われている用語に置き換えようとする必要は無いはずです。
ただ、「HTMLエンコード」という言い方は、Microsoft 製品に親しみのない人には違和感があるかもしれません。ASP の Server.HtmlEncode() や .NET Framework の System.Web.HttpServerUtility.HtmlEncode() の処理がまさにこれなので、Microsoft 的には「エンコード」なのでしょうが、「エスケープ」とかいう方が一般的なような気がします。
関連する話題: HTML / セキュリティ / 狙われるWebアプリケーション / ITpro
2007年4月10日(火曜日)
今日の心に残った一言
「地頭って何ですか?」
……よつばとひめくり2007 (www.amazon.co.jp)
2007年4月9日(月曜日)
DoS 喰らった
なんか昨日一日サーバが重い感じがしていたのですが、ログを見たら、特定の IP アドレスから休みなしに 106,146 回ほどアクセスされていたようです。うっかり wget で再帰してしまった……というパターンかとも思いましたが、User-Agent が IE6 なのでそれはなさそうですね。もちろん本物の IE6 はこんなアクセスの仕方はしませんので、意図的に IE6 の User-Agent を装ってのアクセスでしょう。何らかのよからぬ意図を持ったアクセスではないかと思います。
そのアクセス元は 125.175.20.28 なのですが、これ OCN ですね。とりあえず abuse に報告してみるかな……。
関連する話題: サーバ
2007年4月8日(日曜日)
ベリサインのシールから連想したこと
高木さんの日記から、「JPCERTも糞、ベリサインも糞、マイクロソフトは糞、トレンドマイクロも糞、フィッシング対策解説は糞ばかり (takagi-hiromitsu.jp)」。
これ書いた人は、「シール」の話と混同してるんじゃないか？ 「ベリサインセキュアドシール」とか言っているが、こんなものはPKIでも何でもない、何ら技術的裏づけのないものだから、偽サイト上にいくらでも表示できる。だから、あれこれ一致しているか目で確認するように注意書きされている。そういうどうでもいい話と混同してるんじゃないの？ そもそもこういう安全に使いこなせないシールなんて、やめてしまうのがPKIのプロたる会社の社会的責任だと思うが。
日本ベリサインのシールといえば、昔は捏造できることで有名だったとか、いろいろありますが……そもそも最近、ベリサインのシールを見かけなくなりました。どうも最近のシールは、スクリプトを無効にしているような用心深い (?) ユーザに対しては非表示になるという配慮がなされているようで、いちいちスルー力を試されることもなくなってだいぶ楽ですね。:-)
ところで、ベリサインの「ベリサインセキュアドシール掲載事例集 (www.verisign.co.jp)」というページにはイー・アクセスの名前が出ています。実は私も一時期イー・アクセス (www.eaccess.net)の ADSL を利用していたことがあるのですが、イー・アクセスのサイトのお問い合わせはなかなか面白いです。「お問い合わせに関する個人情報のお取り扱いについて (www.eaccess.net)」というページで「同意する」を押すと、「お問い合わせ｜イー・アクセス」と題するページに遷移するのですが、そこにはこんなことが書いてあります。
このお問い合わせページのＵＲＬのみが http://www.eaccess.net/○×△/と異なるＵＲＬ
https://fs219.xbit.jp/○×△が表示されていますが、
こちらはイー・アクセス（株）が契約している認証ページですので、安心してご利用下さい。
以上、お問い合わせ｜イー・アクセス より
なんか試されている感じですね。もちろん、フィッシングサイトがこういう表示をしている可能性がありますから、書いてあることを単純に信用してしまってはいけません。
こんなとき、フォームが HTTPS であることが意味を持ってきます。サーバ証明書を見ることで、このサイトがイー・アクセスのものなのかどうかを判断することができるわけです。サーバ証明書が信頼ある機関から発行されていて、発行先の組織がイー・アクセスであれば、まあ信じても良かろうということになります。
証明書が信頼ある機関から発行されているかどうかについては、ブラウザが既に自動的に検証してくれています。結果が NG であれば警告が出ますので、それさえ無視しなければ大丈夫です。しかし、証明書がイー・アクセスに対して発行されたものなのかどうか、ということは確かめる必要があります。フィッシング犯が自分で法人を作るなどして、正規の手順で証明書を取得している可能性もあるからです。
※参考 : “本物”のSSL証明書を持つフィッシング・サイト出現 (itpro.nikkeibp.co.jp)
IE7 であれば、アドレスバー横のアイコンをクリックして「証明書の表示」をして、「詳細」タブの中の「サブジェクト」を見ます。O= という値が Organization すなわち組織を表しますので、そこにイー・アクセスのものらしい名前が出ていれば大丈夫です。
逆に万が一、O= の値がイー・アクセスとは関係ないものだった場合は、それはフィッシングサイトである可能性が高いと判断するべきです。まれに O=fs219.xbit.jp のようにドメイン名が入っていたりするケースがありますが、こんな値では運営者が誰なのかさっぱりわかりません。この場合もフィッシング犯が取得した証明書である可能性が否定できませんので、信用すべきではありません。
……と、こんな風に、初めてアクセスするときには証明書に書かれた運営者の名前を見ることで、そのドメインを信用して良さそうかどうかを判断することができます。安全なWebサイト利用の鉄則 (www.rcis.aist.go.jp)で言うと、サイト運営者のことを知っているけれどもドメイン名を知らない、というパターンですね。
※イー・アクセスの場合は一般に使われるドメインは eaccess.net なのですが、フォームが全く別なドメインにあるからややこしいことになります。
2007年4月7日(土曜日)
今日のボツネタ
講演のネタを仕込んだりしている訳ですが、
- 脆弱性発見って危ないんじゃないの？
- なんで? 危なくないよ
- だって合法なの？
- もちろん合法だよ
- セキュリティの専門家なの?
- 違うよ。全然違うよ
……ここまで書いたところで、自分を見失いそうになったので潔くボツ。
ひたすら Not Found をくらい続ける BaiduSpider
BaiduSpider といえばアグレッシブなサーチロボットという印象でしたが、こんなプレスリリースが出ていたのですね……「日本語サイトのwebページの収集Spider（クローラ）問題についてプレスリリース (www.baidu.jp)」。そういえば bakera.jp にも来ているようなので、2007-04-05 のアクセスログから BaiduSpider のものを抽出してみました……baiduspider.txt。
なんと、ほとんど Not Found です。なんか URL の解釈まわりがバグっているのではないかと思いますが……。アクセス間隔は 2分のようで、間隔自体は特に問題ないのですが、無意味なアクセスを繰り返されるのはちょっと。
関連する話題: セキュリティ / UA / BaiduSpider
2007年4月6日(金曜日)
メモ : メッセージヘッダのインジェクションと SMTPコマンドインジェクション
「はびこる「インジェクション系」のぜい弱性 (itpro.nikkeibp.co.jp)」。……徳丸さんの記事ですね。これも「サニタイズ言うな」という話の流れなのですが、説明がとても分かりやすいと思いました。連載ということなので期待大です。
ただ、非常に細かいのですが一点だけ気になった点が。
表中に「SMTPヘッダー・フィールドの追加」という項目がありますが、「SMTPヘッダー・フィールド」という言い方には違和感があります。SMTP においては、メッセージヘッダは単に DATA コマンドで送られるデータの一部です。これは名前の通りメッセージのヘッダであって、プロトコルの中でヘッダとして扱われているわけではありません。ですので、メッセージヘッダの定義は SMTP の仕様について述べた RFC2821ではなく、メッセージの書式を述べた RFC2822 のほうに入っています。
そもそも sendmail -t に対するインジェクションと SMTP コマンドのインジェクションは少し性質が違いますので、一緒に扱うのは良くないかもしれません。以下はメモですが……。
メッセージヘッダの To: と実際の送信先となるエンベロープ To は必ずしも一致しませんから、たとえ To: がインジェクションできても、それが RCPT TO: コマンドに反映されない限り第三者中継は成立しません。では何故メッセージヘッダのインジェクションで第三者中継が起きるのかというと、多くの場合、メール送信には sendmail -t が (あるいは、それと互換性のある何かが) 使われているためです。sendmail に -t オプションを付けて呼び出すと、sendmail は標準入力の内容 (メールのヘッダと本文) から To: や Cc: などの値を読み取り、それを SMTP の RCPT TO: で宛先に設定します。このため、メッセージヘッダに To: などがインジェクションされると、任意の宛先にメールが送られてしまいます。
逆に sendmail コマンドが -t なしで呼び出されていたり、sendmail -t と互換性のないメール送信方法が使われているような場合は、メッセージヘッダに To: がインジェクションされても送信先には影響ありません。メールに謎のヘッダが増えたりしているので受け取った人は混乱するかもしれませんが、それだけです。
では SMTP に対するインジェクションは起こり得ないのかというと、そんなことはありません。SMTP コマンドのほとんどは <CRLF> で終わりとなりますから、送る値 (たとえば MAIL FORM: や RCPT TO: のメールアドレス) に <CRLF> が含まれていると、やはり任意の SMTP コマンド実行のおそれがあります。では、一律 <CRLF> をはじけば……と思うかもしれませんが、そうはいきません。なぜなら、メールのヘッダや本文には普通に <CRLF> が含まれるからです。メッセージヘッダと本文を送るのは DATA コマンドですが、このコマンドでは <CRLF> を普通に扱うことができるかわりに、ピリオドだけの行 (<CRLF>.<CRLF>というデータ) がデータの終わりを意味します。
あらためてまとめると、こんな感じですね。
- メッセージヘッダ …… sendmail -t に値を渡す場合、<CRLF> を適切に処理しないと問題が起きる。
- SMTPコマンド (DATA) …… SMTP の DATA コマンドで値を送る場合、<CRLF>.<CRLF> を適切に処理しないと問題が起きる。
- SMTPコマンド (その他) …… SMTP の MAIL FROM: や RCPT TO: で値を送る場合、<CRLF> を適切に処理しないと問題が起きる。
もっとも、実際には Web アプリケーションの開発者が SMTP を直接どうこうする場面はほとんど無いでしょう。たいていはデータを MTA に渡すだけでしょうから、メッセージヘッダの <CRLF> に気をつけていれば良いことになります。任意の SMTP コマンドのインジェクションができてしまう MTA があったら、それは MTA の脆弱性でしょうし。
※そんな問題のある MTA は滅多にないと思いますが、「JVN#86092776 BASP21 においてメールの不正送信が可能な脆弱性 (jvn.jp)」というのはその希な例だったのだろうと思います (参考 : [memo:9233] Re: JVN#86092776: BASP21 においてメールの不正送信が可能な脆弱性 (memo.st.ryukoku.ac.jp))。
関連する話題: セキュリティ / MTA / 狙われるWebアプリケーション / サニタイズ言うな / RFC
年度がかわると鍵もかわる
IPA/ISEC の PGP 公開鍵 (www.ipa.go.jp)が更新されています。当然ながら古い鍵は期限切れで使えませんので、新しい鍵に入れ替えないといけないわけですが、これがまた手間でして。
HTTPS 経由で送るようにすればこの点は楽なのですが、それはそれでフォームの UI が厳しすぎるので何とも。UI だけ自作するとか……?
関連する話題: セキュリティ / IPA / 情報セキュリティ早期警戒パートナーシップ
2007年4月4日(水曜日)
JavaScript無効の勝利
「ActiveXを入れない訪問者には何も見えない」ブログ盗用防止技術が登場 (slashdot.jp)だそうで。
JS のソースに書かれている現物の URL にアクセスすれば、普通にコピペできるようになりますが……。こういうのは脆弱性なのですかね。まあ、まだ正式サービスではないようなので、様子見ですか。
関連する話題: セキュリティ
2007年4月3日(火曜日)
あるある大事典検証番組
「発掘! あるある大事典II」の検証番組が放送されました。おおむね委員会の調査報告書 (www.ktv.co.jp)をなぞった内容でしたが、内部のアンケートなどが公開されていましたね。
個人的に興味深いと思ったのは、いったん企画が破綻した後、日本テレビ系列のとある番組がきっかけで方向転換したという話です。調査委員会は他局の番組についてあれこれ言う立場にないのでしょうが、日本テレビはその番組について自主的に検証した方が良いのではないでしょうか……。
※検証番組ではその番組名は出していませんでしたが、調査報告書51ページにはちゃんと名前が出ていますね。
もう一つ興味深いと思ったのは、放送倫理･番組向上機構 (BPO) が、「血液型を扱う番組」に対する要望 (www.bpo.gr.jp)というものを出していたという話。バーナム効果の話などは以前から知っていたのですが、これはちょっと知りませんでした。
2007年4月2日(月曜日)
続・Windowsアニメーションカーソルの脆弱性
Windowsアニメーションカーソルの脆弱性話ですが、えむけいさんによると (情報ありがとうございます)、アニメーションカーソルを favicon としても使うことができてしまうとのこと。Windows XP SP2 + IE7 で試してみましたが、アニメーションこそしないものの、普通にタブやアドレスバーに表示されますね……。
なお、「拡張子ではなく、内容によってファイルを開く」が無効であっても、image/jpeg などの画像っぽい Content-Type になっていれば表示されてしまうようです。
※ちみに「拡張子ではなく、内容によってファイルを開く」が有効の場合、text/plain でさえも表示されます (無効の場合は、さすがに text/plain だと無視される模様)。
回避方法はなさそうなので、ひたすらパッチ待ちですね。マイクロソフト セキュリティ情報の事前通知 (最終更新日: 2007年4月2日) (www.microsoft.com) を見ると、4月4日にリリースされる予定のようです。
関連する話題: セキュリティ
- 前(古い): 2007年3月のえび日記
- 次(新しい): 2007年5月のえび日記
