CVE-2014-0554)について書きます。Sandboxとはローカルで動くFlashのセキュリティ制限のタイプの1つです。Sandboxで動くFlashは、ローカルに保存したデータにはアクセスできるけど、ネットワーク通信はできないという制限で動きます。これにより、ローカルのデータを処理しながら、外部にはそのデータを送信されないような制限で安全にアプリを動かすことができるという話みたいです。詳しくは、Adobeのドキュメント(http://help.adobe.com/ja_JP/ActionScript/3.0_ProgrammingAS3/WS5b3ccc516d4fbf351e63e3d118a9b90204-7e3f.html)を参照。(ちなみに、ブラウザによってははじめからローカルのhtmlを開いたときにこの制限以上のことができるものもあります。いうブラウザははじめから問題にならないと考えていいでしょう。)今回はこのFlashが意図している制限を超えて、ネットワーク上にローカルファイルのデータを渡すことがバイパスのミッションです。)以下のような方法で、ローカルファイルを外部へ送信できていました。細工したSWFファイルをローカルで開く。パスが既知のローカルファイルのデータをURLLoader()で取得。navigateToURL()の第1引数にローカルに持たせたHTMLのファイル、第2引数に取得したデータを渡す。リダイレクト後のローカルのHTMLから攻撃者のサイトにとばしてwindow.nameを取得すればデータの取得完了。----------------------------------------単純ですが、これでできていました。Sandboxの下では、直接httpなURLにナビゲーションできないので、一度ローカルに保存させた細工したHTMLに飛ばしています。修正後は、名前付きのウインドウはFlash側がランダムにつけた別の名前に上書きされるようになりました。ちなみに、ローカルファイルのURLの部分に「?」や「#」つけてデータ渡せば?っていう発想もあると思うんですが、リダイレクト時に「?」や「#」以降の文字列を削除しているようで、これは無理でした。開くと、そこから「../secret/secret.txt」の位置にあるテキストデータを取得しようとします。)これは、ローカルファイルを取得する話ではないのですが、バグを使ってローカルファイルから任意のネットワーク上のデータを取得して、それを【方法1】で紹介したようにwindow.nameを経由して攻撃者のサイトへ送信するというものです。Sandboxの下では制限されていますが、Firefoxだけは、Windowsの「.url」形式のショートカットファイルに対して、URLLoader()を使うと、ショートカットファイルが指すネットワーク上のデータを取得できていました。ショートカットファイルが「https://www.google.com/」を指していれば、Googleのレスポンスbodyが取得できていました。ここで取得したデータを【方法1】と同じようにwindow.nameで渡せばゲット完了です。開くと、Googleのトップページのレスポンスbodyを取得し、外部に送信しようとします。)これもローカルファイルからネットワーク上のデータをゲットする話です。Firefoxだけ、ローカルファイルから以下のようなURLに対しURLLoader()を使うと、ネットワーク上のデータを取得できていました。pcast:をつけたURLに対してsendToURL()等を使い、http:なURLへの通信制限をバイパスすることで送信します。スキームでバイパスできたという話もありましたが、今でもブラックリスト的に制限していたのですね。PoCはこちら:http://l0.cm/file/localsandbox_bypass_with_feed_and_pcast.zip(SWFを開くと、Googleのトップページのレスポンスbodyを取得し、外部に送信しようとします。氏が発見した以下の方法を参考にして発見しました。HackerOnehttps://hackerone.com/reports/2140彼の手法はこういうことだと思います。パスが既知のローカルファイルのデータをURLLoader()で取得し、そのデータを2進数変換。%5Cのようにして重ね、罠HTMLのファイルにnavigateToURL()する。以下のようなかんじにするということです。URLとして問題なくアクセス可能です。リダイレクト後にパスに含まれた「%2F」「%5C」を変換してテキストを取り出す。%2F%5C%5C%5C%5C%5C%5C%2F↓10000001↓A----------------------------------------めっちゃおもしろいですね。【方法1】で言ったように、URLの「?」や「#」以降に文字を渡せないので、それをバイパスするためにこんなことをしている訳です。修正後はリダイレクト後のURLを正規化して、余分な「%2F」「%5C」を取り除くことで対策したようです。この手法を見て、他にも似た方法がありそうだな、と思って考えていたところ、思いついたのが以下のような手法です。file:///C:/path/PoC.html.%20%20%20%20%20%20.Windowsではファイル名のあとに「.」と「スペース」を重ねることが許されるようなので、これを同じように、.%20%20%20%20%20%20.↓10000001↓Aというようにして取得するというものです。みたいに変換してリダイレクトするというのもできました。file:///C:/path/aAAAAAAa.htmlaAAAAAAa↓10000001↓Aこの問題に気が付いた後に、もっと根本的な問題に気が付いたので、これに対してだけの修正がリリースされることはありませんでした。)ここにきて、別のローカルファイルへのリダイレクトを許しているのが、根本的に危険な動作なんじゃないのかということに気が付きました。リダイレクトさえできれば以下のようなことができてしまいます。パスが既知のローカルファイルのデータをURLLoader()で取得し、データから1バイト取得。取得したバイトデータにあわせて、以下のように準備した、細工したHTMLへリダイレクトする。(「A」なら「41.html」にリダイレクトする。localStorageなどにリダイレクトを受けたHTMLの名前を保存しておき、次のバイトを見る。最後のバイトまで1~3の手順を繰り返す。全部取得できたら攻撃者のサイトにリダイレクトしてデータを飛ばす。----------------------------------------ローカルのファイルが存在すればリダイレクトに成功するので、URLに細かくデータを含めたりしなくてもどこにリダイレクトしたかでデータを判定すればいいじゃないかということです。開くと、そこから「../secret/secret.txt」の位置にあるテキストデータを取得しようとします。)どうやって対策するんだろう、と思っていましたが、ここまできてAdobeもローカルファイルへのリダイレクト自体が危険だということに気が付いたのか、ついにリダイレクト時に以下のような警告を出すようになりました。これにより、自分から警告より先に行かなければローカルファイルを開いただけで別のローカルファイルが漏れることはなくなりました。はい、こんなかんじでした。僕もAdobeも根本的な問題に気が付くのがちょっと遅かったですね。FlashがWebの制限と共存するために、どういうバランスの保ち方をしているのかを見てみると、意外な方法でやっているのが見えてきたりして楽しいですね。それはうまくいっていないか、かなり危なっかしいです。