おそらくプレビューでWebKitが呼び出されて、WebKitのセキュリティホールを使って何らかのトロイの木馬が仕込まれたのだと思う。メールを開いたつもりもなく、「編集」で削除しようとしただけでプレビューが出たように記憶するのだが、もしかしたらタップして踏んでしまったのかもしれない。
iOSは5.1.1。6には事情があってまだしていない。
きょうのthreatpostの投稿に、iOS 6にも存在するWebKitのexploitの説明があったので、例によって超訳することで鬱憤を晴らすことにする。なお、WebKitなのでAndroidのChromeでも踏めるらしい。もしかしたら、少し前にMac OSのSafariがアップデートされたがそれに関係があるかもしれない（アラートの文面からしても、Mac OS X Mountain Lionの「通知」でこれを表示させたほうが効果的な気がする）。
（2012年11月12日追記：このexploitとPOCはApple側で認識され、iOS 6.0.1で対策されたようだ。僕は早速アップデートした。事情があって上げられない人とかいるかもしれないが、乗っ取られるのとどっちをとるかよく考えたほうがいいと思う）
（2012年11月12日追記：このexploitとPOCはApple側で認識され、iOS 6.0.1で対策されたようだ。僕は早速アップデートした。事情があって上げられない人とかいるかもしれないが、乗っ取られるのとどっちをとるかよく考えたほうがいいと思う）
原文はこちら：
----
iPhone 5出荷開始、iOS 6でも生きているexploitへの旅についてハッカーが語る
threatpost - Apple
Michael mimoso
2012年9月21日
2012年9月21日
AppleのiPhone 5を待ちわびて今日まで行列を作って泊まりこんだ数万人と同じ時間、ハッカーたちはすでにそのコアであるiOS 6オペレーティングシステムを配下に置いていた。2人のオランダ人ハッカーたちはAppleの頑丈な防壁をうまくやりすごし、今週アムステルダムで行われたEUSecWest会議で「iPhone 4Sにパッチを当てるハック」に最初に成功したことをプレゼンした。このexploitは、いままさに登場する新しいデバイスについても有効なものだ。
Joost PolとDaan Keuperは数多くの賞賛と、$30,000を、このmobile Pwn2Ownコンテスト（注：Pwnはオンラインゲームでの勝利、Wonをチャットでミスタイプしたことから広まったもの。ここでの勝利はクラック成功を意味していて、Pwn2Ownとは、クラック成功者に商品授与するイベントを指す）勝者にその努力を報うものとして授与された。この2人は、オランダのセキュリティ会社Certified Secure社の研究員で、WebKit、つまりAppleのSafariブラウザの下敷きになっているブラウザエンジンの脆弱性を利用した。3週間の価値ある労働を経て、このペアは携帯からデータを盗み出すことのできる、生きているexploitを見つけ出した。本ブログはPolとKeuperに、どうやって彼らがiPhoneを首尾よくクラックしたのか尋ねてみた。
Threatpost: iPhone 4S（とiOS 6）をターゲットにした動機は？
Pol and Keuper: iPhoneには考えられる最善のセキュリティ機能（例えばASLR - アプリのメモリ割り当て空間をランダムにする, DEP, サンドボックス、コード署名など）を備えていて、なにより僕たちにとって最も興味深いターゲットだったから。iOS 6のリリースについては、WebKitの新しいバージョンが使われていて、以前の脆弱性やexploit経路はふさがれていると思っていたから、おまけでついてきた関心といったところ。
Threatpost: 君たちが発見した「WebKit脆弱性」（注：今年8月末の同ブログ記事で、WebKit脆弱性を嘆くコラム）はどの程度深刻で、それをどうやって見つけたのか説明してくれないか。
Pol and Keuper: 脆弱性を発見したのは、WebKitのコードの検査をする過程からだった。脆弱性の程度は極めて深刻で、（若干の罠を仕掛けておけば）任意のコード実行が（Safariのサンドボックス内で）可能だ。僕たちがPwn2Ownで実演したように。これを活用すれば、（例えば）誰かの個人的な写真やアドレス帳やブラウザの履歴に直接アクセスすることができてしまう。
Threatpost: 「WebKitのセキュリティ」（注：今年2月にRSAカンファレンスで講演されたAndroid携帯のWebKitが持つゼロデイ脆弱性の悪夢についての記事）の話について、君たちはどんな意見を持っている？
Pol and Keuper: 不完全だと思う。現時点で、僕たちが見つけた脆弱性の詳細について話すことはよいことではないと思うし、WebKitのセキュリティ全般（そして競技のルール全体やその他すべて）についてもそう思う。でも、僕たちがexploitできる脆弱性を3週間以内に見つけられたという点で、この「不完全な」話は極めて強い意味を持つことになったと思う。
Threatpost: 脆弱性を発見してから、君たちはいくばくかのコードを継ぎ合わせて、生きているexploitに仕上げてしまった。それはどんなもので、なぜそんなことをしなければならなかったのか話してくれないか。
Pol and Keuper: 脆弱性があったからといって、それが「直接」コード実行に結びつくことは極めてまれだ。ほとんどのexploitは、コード実行を可能にするために、あなたが言う「追加の作業」がある程度必要なんだ。僕たちのケースでは、iOSの機能であるコード署名（Appleが付与する署名なしではいかなるコードも実行できない機能）に対するワークアラウンドも必要だった。
Threatpost: Appleのコード署名に対して、どんな細工をしたのかな？ 難しかった？
Pol and Keuper: 普通、iOSではコード空間のあるページに対して、実行可能か書き込み可能かのどちらかしか許可していない。両方の権限がつくことはありえない。また、対象となるページは実メモリにロードされる前に署名されている必要もある。これはとても厳密な規則で、（注：セキュリティにとって）非常によい働きをする。iOS 4.3以後、Appleはこのポリシーを導入した。
iOS 4.3以後、Appleがそれを決めたのは、Mobile Safariブラウザのパフォーマンス向上のためにJust In Time (JIT)コンパイラを導入したからだった。だから、いまではMobile SafariはページにRWX（注：読み書き実行）をマップできる。この例外はMobile Safariだけのために与えられた（つまり特権を持っている）。僕たちのexploitでは、JITページのロケーションを見つけ出して自作のシェルコードを上書きし、そこへジャンプする。
もしJITページがなかったら、ROP [return-oriented programming]を使って全く同じ結果（つまりコード実行）が得られるようにしてやる。けれど、ROPのペイロードを作るのは実にまったくしんどい作業だ。
どちらも既知のテクニックで、以前にも利用されたことがあるものだ。
Threatpost: そのexploitを働かせるためには、利用者をうまく釣って携帯から悪意あるサイトを観るように仕掛けるの必要があると思うんだけれども、それはどうやるの？
Pol and Keuper: exploitはバックグラウンドで動いて、ひそかに利用者の個人データ（アドレス帳、カメラで撮った写真、ブラウザ履歴など）を携帯から外部のサーバに、攻撃者の指示で送信することになるだろう。
Threatpost: 君たちの仕事では、iPhoneからemailやSMSメッセージを取り出すことはできなかったようだけれど、それはどうして？
Pol and Keuper: Safariのサンドボックス（つまり僕たちのコードが動くところ）からはSMSやemailのデータベースにアクセスできないんだ。
Threatpost: 今回のexploitはiOS 6にもそのまま残っていて、iOS 6でも同じexploitが働くという理解でいいのかな？
Pol and Keuper: 今回の脆弱性はiOS 6にそのまま残っている。exploitに対する一般的なアイディアも同じだ。けれど、iOS 6では少し異なった中間作業が必要になる。
Threatpost: 君たちはexploitを破壊した、ということだけれどそれは本当なの？ どうして？
Pol and Keuper: 本当だ。そんなものは、もはや不要だろう？ 競技のルールのなかに、脆弱性の説明と簡単なPOC（コンセプトを証明する）プログラムをZDI [TippingPoint's Zero Day Initiative program]へ送る必要があった、それだけのこと。
Threatpost: その詳細はAppleと共有している？ やりとりはどんな感じだったの？
Pol and Keuper: 競技の規則の一部に、脆弱性はZDIからAppleに開示されると明示されている。
----
Threatpost: 脆弱性を発見してから、君たちはいくばくかのコードを継ぎ合わせて、生きているexploitに仕上げてしまった。それはどんなもので、なぜそんなことをしなければならなかったのか話してくれないか。
Pol and Keuper: 脆弱性があったからといって、それが「直接」コード実行に結びつくことは極めてまれだ。ほとんどのexploitは、コード実行を可能にするために、あなたが言う「追加の作業」がある程度必要なんだ。僕たちのケースでは、iOSの機能であるコード署名（Appleが付与する署名なしではいかなるコードも実行できない機能）に対するワークアラウンドも必要だった。
Threatpost: Appleのコード署名に対して、どんな細工をしたのかな？ 難しかった？
Pol and Keuper: 普通、iOSではコード空間のあるページに対して、実行可能か書き込み可能かのどちらかしか許可していない。両方の権限がつくことはありえない。また、対象となるページは実メモリにロードされる前に署名されている必要もある。これはとても厳密な規則で、（注：セキュリティにとって）非常によい働きをする。iOS 4.3以後、Appleはこのポリシーを導入した。
iOS 4.3以後、Appleがそれを決めたのは、Mobile Safariブラウザのパフォーマンス向上のためにJust In Time (JIT)コンパイラを導入したからだった。だから、いまではMobile SafariはページにRWX（注：読み書き実行）をマップできる。この例外はMobile Safariだけのために与えられた（つまり特権を持っている）。僕たちのexploitでは、JITページのロケーションを見つけ出して自作のシェルコードを上書きし、そこへジャンプする。
もしJITページがなかったら、ROP [return-oriented programming]を使って全く同じ結果（つまりコード実行）が得られるようにしてやる。けれど、ROPのペイロードを作るのは実にまったくしんどい作業だ。
どちらも既知のテクニックで、以前にも利用されたことがあるものだ。
Threatpost: そのexploitを働かせるためには、利用者をうまく釣って携帯から悪意あるサイトを観るように仕掛けるの必要があると思うんだけれども、それはどうやるの？
Pol and Keuper: exploitはバックグラウンドで動いて、ひそかに利用者の個人データ（アドレス帳、カメラで撮った写真、ブラウザ履歴など）を携帯から外部のサーバに、攻撃者の指示で送信することになるだろう。
Threatpost: 君たちの仕事では、iPhoneからemailやSMSメッセージを取り出すことはできなかったようだけれど、それはどうして？
Pol and Keuper: Safariのサンドボックス（つまり僕たちのコードが動くところ）からはSMSやemailのデータベースにアクセスできないんだ。
Threatpost: 今回のexploitはiOS 6にもそのまま残っていて、iOS 6でも同じexploitが働くという理解でいいのかな？
Pol and Keuper: 今回の脆弱性はiOS 6にそのまま残っている。exploitに対する一般的なアイディアも同じだ。けれど、iOS 6では少し異なった中間作業が必要になる。
Threatpost: 君たちはexploitを破壊した、ということだけれどそれは本当なの？ どうして？
Pol and Keuper: 本当だ。そんなものは、もはや不要だろう？ 競技のルールのなかに、脆弱性の説明と簡単なPOC（コンセプトを証明する）プログラムをZDI [TippingPoint's Zero Day Initiative program]へ送る必要があった、それだけのこと。
Threatpost: その詳細はAppleと共有している？ やりとりはどんな感じだったの？
Pol and Keuper: 競技の規則の一部に、脆弱性はZDIからAppleに開示されると明示されている。
----
