2012年9月25日火曜日

WebKitのセキュリティホールにやられたorz

YahooメールのspamをiPadの「メール」から削除しようとしたら、プレビューが表示されて、以後3分ぐらいに一度、「Macのメールウイルス対策には...comへ」の日本語アラートが数分おきに現れるようになった。iOS4まで標準だったアラートなので、[OK]を押すまで他のことは何もできない。とりあえずこのアラートは、「設定」の「通知」で空白アイコン、無名のエントリを「オフ」設定にすることで出なくすることはできたが、たいへん気分が悪い。

おそらくプレビューで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で対策されたようだ。僕は早速アップデートした。事情があって上げられない人とかいるかもしれないが、乗っ取られるのとどっちをとるかよく考えたほうがいいと思う)

原文はこちら:
----

iPhone 5出荷開始、iOS 6でも生きているexploitへの旅についてハッカーが語る

threatpost - Apple
Michael mimoso
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に開示されると明示されている。
----

2012年9月7日金曜日

イオシスがまたやってくれた

昨日は久々の東京出張だったので、秋葉原を散策。本当は、分解して取り出した古いVAIOの液晶ディスプレイを再利用したかったので、Aitendoさんの店舗で相談するつもりだったのだが、ピンポイントで木曜定休にはまり、シャッター越しに暗い店内を覗きこむような形になった。残念。めったに東京出張できる身分でないので、通販で相談するしかないか。

しかし、末広町駅西側があんなことになっているとは思いもよらなかった。公には書けないが、要するに中国のテクノロジーやそういった2ch的なもろもろが微妙な感じで、あっさりいえば商売になっているということ。世の中がなんでもクリーンならばよいとは全く思わないので、とりあえず見逃してもらえていることはよいことだと思う。また、価格的にもネットの裏商売のようなひどいものではなく、適正な利益水準と感じられたので、当局の方々におかれましては、今後ともお目こぼしいただきたいと願う次第。

そんなこんなで魔境を延々と彷徨っていたため、いつもの共立・秋月の通りに到着するまでかなり時間がかかったのだが、秋月の隣にあるイオシスは例によって一応みておくことにした。

ioBook Airについては以前にも書いたが、場所を微妙に裏側に変更して販売継続中のようだ。しかし、10月26日のWindows 8販売開始以後、あの価格で勝負ができるとは思えないのでそれまでになんとか売り切ったほうがいいような気がした。

今回目にしたのは、キーボード。ひとつはApple Bluetooth Keyboardのなんちゃって版と、驚いたことにHappy Hacking Keyboard風のなにか、であった。

前者は、ioBook Airよりはましだが五十歩百歩な感じの品物だ。アルミ素材も似ている。金型の精度も似たり寄ったりな感じだ。1,980円だったように思うのだが、その程度のものということ。特に、チルト用の脚はあまりにもひどいので、Apple製品と較べてはいけない。それなら、末広町魔境にある別の同価格のものを検討すべきと思われる。

で、Happy Hacking Keyboard風のなにか、であるが、これも大変に残念なものと思われる。キータッチは普通のメンブレンで、まぁどうということはない。配列は一応USなのだが、なぜか106キーボードの風情が漂う。スペースキーが短いのだ。で、英数キーのところはMacのコマンドキーのマーク、かなキーのところはイオシスのロゴが入っている。

1000円台でコンパクトなUS配列のキーボードはなかなか入手困難なので、そんな要望にはひとつの解決になるかもしれないが、スペースキーが日本語キーボード並に短いのは耐えられない人が多いと思う。これは各自、実物を触って確かめてもらいたい。

ついでなので中華Padもいくつかの店舗に並んでいるのを見たのだが、中華Padもちゃんとしたものが主流となりつつあるようで、1万円台ではせいぜいAndroidも3.0程度、ICSやJerry Beanを動かすなら2万、3万といったところで、それならNexus 7買っちゃえばと感じられた。Nexus 7を初めて触ったのだが、Androidマシンの無駄にハイスペックなSoCとJerry Beanになってようやくまともになったなめらかな表示で、正直、驚愕してしまった。これなら使ってみたいと、Androidなのに初めて思った。予算が余るなら、買ってしまうかもしれない。安いし。ええ、間違っても自腹では買いません。Androidなんで。

SONY DCR-TRV900 mini DVカメラをiMovieで認識させる

Mini DVで持っていたテープの内容を発掘するために、手持ちのSONY DCR-TRV900をMac mini mid 2011に「Thunderbolt to Firewire Adapter」に接続してみた。

ところが、この機種は昔VAIOでもうまく認識されず、ケーブルを選ぶところがあった。案の定、Macはカメラを認識してくれない。こういうときは検索ということで、Appleのサポートフォーラムがひっかかったが、理由はよくわからないがうまくいったりいかなかったりするようだ。

困ったなと思い、接続したままカメラの電源を入れたり、VTR側に切り替えたり(テープを再生したいのだから、VTR側が正しい)するのだが、どうもうまくいかなかった。

システムの詳細をみても、カメラは見あたらない。

そこで思い立って、VTRでオンにしたままi-Link端子のケーブルを抜いて挿しなおしてみたところ、いきなりiMovieにDVカメラのウインドウが開いた。要するに成功したということ。

何にせよ、理由がわからないのは確か。お困りの方のご参考になればとここに記しておく。

なお、iMovieでの「自動」取り込みは、無録画からはじまるテープではうまくいかないようだ。僕はテープの先頭部分は信用していなかったので、少し送ってから使うようにしていた。この場合は、「手動」で録画されているところの頭まで巻き戻してから、おもむろに「取り込む...」を押すとよいようだ。

2012年9月3日月曜日

Emacs 24.2をMac用にコンパイルする

いままで使ってきたEmacs23、ふと思うところがあり、思い切ってGit Headをもってくることにした。きょうのバージョンは24.2.50だった。

そのまま./automake.sh && ./configure --with-ns && make bootstrap installでもよいのだが、おなじみinlineパッチLion Full Screenパッチをあてることにした。

どちらもEmacs24ではあるが、inlineパッチは24.50、Full Screenパッチは24.1を対象にしたもの。結論からいうと、あまり問題にはならなかった。

先にFull Screenパッチをあてるといいと思う。こちらは行が若干前後するだけで、パッチはきれいにあたる。一方、inlineパッチは、最初がconfigure.inに対するパッチで、これはGit Headには存在しないので、./automake.shしてconfigureを生成してからpatchコマンドを実行することになる。すると最初にファイル名を問われるので、そこで「configure」を入れてやればよい。1つだけrejectが出るが、inlineパッチで追加したmacim.mのオブジェクトを追加するところ。rejファイルを見て、その前にある"nsfont.o"を検索して、そのあとにmacim.oを追記してやればよい。

なお、sourceforgeに置かれているinlineパッチは、インストール時のOSのLocaleを見ているので、英語設定でインストールして、システム環境設定で言語を日本語に切り替えた場合、ことえりなど日本語IMEを見つけてくれない。MacEmacs JPメーリングリストの記事にある、現在選択されているLocaleが日本語なら日本語IMEを探すようにしておくほうがいいかもしれない。

make installまでやると、nextstepディレクトリの下にEmacs.appとして一式揃っているので、/Applicationにでもmvしてやればよいと思う。というか、そうした。

最後にいちばん苦労したのは、.emacsが結構違うということだった。さまざまな議論があちこちにあるけれども、Mac Wikiの説明がいちばん有用だと思う。あまり詳しいコメントはついていないが、Emacs Lispを少々かじっていれば何をやっているかはわかるはず。個人的にはSection 6の、文字の拡大縮小(\C-+,-,0)に対応したフォントの設定がたいへんありがたかった。いままで12ptで、さすがにThunderbolt Displayの27inchには文字が小さかったので、14ptになって助かっている。また、ここのブログエントリでも苦労が明かされているが、「(setq default-input-method "MacOSX")」の行は、画面の各種設定をやった後に置かないとinlineパッチで期待される動き(toggle-input-methodがIMEのオンオフと連動する)をしないようだ。ここはEmacs23までとは大きく違う、おそらくパッチで何らかの手立てが必要と思われる部分と思われるところなので、当面注意しておくことをおすすめする。

(2012年9月7日追記:Emacs23以後はUnicodeのIVSに対応しているような話があったが、どうもこれはLinux上での話のようだ。つまり、--with-nsでCocoaを使った場合とは違うようだ。そこで--with-Xをつけてコンパイルしようとするが、libotfを組み込んでくれない。理由はpkg-infoでまずlibXftを調べ、そのあとpkg-infoでfreetype2の存在を調べてからpkg-infoでlibotfを調べるからのようだった。作ろうとしたのがHomebrewを使っているMacだったので、Xquartzに入っているものは普通にはインストールしない。強引に作るにはconfigureを書き換えることになるが、面倒なのでやめた。)