いわゆるXcodeGhostについて

iPad AirをiOS 9にアップデートしようと久しぶりに電源を入れたら，iCloudやiMessageへのログインを繰り返し要求される事態が発生し，うんざりしておりました。公開初日だったのでAppleがとんでもなく混雑しているのは，iOS 9のダウンロード前の認証に10分ぐらいかかった時点で覚悟したわけですが，iCloudやiMessageの認証失敗もその関係かなと思っていたわけです。

日中のダウンロードを諦めて帰宅後，深夜に自宅で割と（それでもゆっくりと）ダウンロードが進むのを見ているうちに寝落ちしたので，目覚めてからは混雑解消したのか，すっきりとインストール以後は進みました。

インストールの間にもAppleの認証ステップがありますから，通信が混雑しているとインストール途中でプログレスバーがいつまでも動かない，ということが生じますが，それはなかった，ということです。

で，現象が解消して忘れていたのですがそこへXcodeGhostのニュース。各ニュースサイトで話題になっているのでご存知かと思いますが，細かいところまでよくまとまっているのが以下の記事かと思います。

• 新たなマルウェア「XCodeGhost」全てのiPhoneユーザは要チェック!! (iBitzEdgeさん）

それ以前に一般のニュースで，iCloudのパスワードを入れさせられる場合もある的な記述があり，「ゑ？」と思ったわけです。

ということで，Pangu作のチェッカを入れて確認しました。このへんは脱獄ニュースのTools4Hackさんが詳しい。Panguは脱獄ツールを作成，配布しているところですから当然でして，この界隈の修羅の様相を踏まえて，確からしい内容を選んで丁寧に解説されているのがこのサイトであります。

• [iOS] AppStoreからも感染するウイルス「XcodeGhost」の検知アプリをPanguが公開 (Tools4Hackさん）

個人的には脱獄環境でMobile Safariの穴からiOS乗っ取られた過去があるので脱獄はめんどくさいと思ってやめましたが，iOSのセキュリティについては脱獄コミュニティがいちばん詳しく知っていて，Twitterなどでかれらが漏らす話が重要だったりするので，それをうまく掬って記事にしてくださるニュースサイトは見ております。

というわけで，上記記事の手順で，Mobile Safariからアプリをインストールして，開発者証明書プロファイルを「設定」アプリから「信頼」してあげれば動きます。エンタープライズ向け，企業などで社内業務用に開発されたものなど，一般公開されないアプリをインストールして動かす手順を踏む形。

開発者証明書はAppleに申請して，Appleの署名つきのものを取得しないとアプリが動かず，証明書の偽造はまだ確認されていない，できないことになっている，のだったと思うので，このアプリを動かす間だけ「信用」すればよいし，この画面で「信用」すると赤文字で「Appを削除」にかわるわけですが，実行後，ここをタップすれば証明書とアプリの両方が消えます。

結論ですが，わたくしのところでは，コメント欄で話題になっているCamScannerは手持ちはCamScanner+だったおかげか，感染しておりませんでした。というわけで問題なし。AppStore側も感染アプリのBAN（ストアからの削除）を積極的に進めているようなので，今後インストールするアプリに同じ不正コードが含まれている可能性は少ないのかなと思っています。（AppStoreからBANされていても，いまデバイスにインストールされているアプリまで消えるわけではないので，いま動いているiOSデバイスで確認することが大事です）

それで，XcodeGhostの該当コード部分がGitHubに上がって，めきめきスターの数が上がっております。スターは，いわゆる「お気に入り」機能です。ブックマークといってもいい。

• XcodeGhostSource/XcodeGhost (GitHub)

たしかに，各種情報をとりまとめ，暗号化して情報収集サイトに送信する様子が見えます。README.mdが中国語なので読みにくいですが，英語に翻訳すればわかりやすい。文法が近いためか中国語から英語への翻訳精度は高いと思います。

Google翻訳の結果：

"XcodeGhost" Source clarification on the so-called "XcodeGhost" of

First of all, I XcodeGhost event to bring confusion apologize. XcodeGhost from my own experiments, without any threatening behavior, as detailed in the source code: https: //github.com/XcodeGhostSource/XcodeGhost

The so-called XcodeGhost is actually hard to force an unexpected iOS developers find: Modify Xcode compiler configuration text file specified code can be loaded, so I wrote the code above annex to try and upload it to your network disk.

All data in the code actually acquired basic app information: application name, application version number, system version number, language, country name, symbol developer, app installation time, device name, device type. In addition, you do not get any other data. Solemn note is required: for selfish reasons, I joined the advertising features in the code, hope can promote their applications (off the source code can be compared to the Annex do check). But in fact, from the beginning to the final shut down the server, I have not used the advertising function. And in 10 days ago, I have taken the initiative off the server and remove all data, but will not have any effect on anyone.
Willing rumors would stop the truth, the so-called "XcodeGhost", used to be a wrong experiment, after just completely dead code only.

It is emphasized that, XcodeGhost App will not affect any use, but does not obtain private data, only a dead piece of code.

Again sincerely apologize, wish you a pleasant weekend

tt-rssとReeder

Google Reader終了後、いろんな他サービスに移行した人は多いと思うのだけれど、僕のみたところ、どこも広告リンクを踏ませて収益を得ようとするとか、行動ターゲティング広告を狙ったようなアクセス解析に使うことを目的としたのが露骨に現れたサービスが目立ち、全く使う気になれなかった。

そんな折、自前サーバでフィードのアグリゲーションができるサーバとしてtt-rssの存在を知った。僕はさくらのVPSを借りていて、FreeBSDを入れていたのだけれど、portsにtt-rssも入っていて、簡単に使えたのでおすすめしたい。なにより第三者にどんなフィードを読んでいるかを知られることもなければ不要な広告リンクを踏まされる必要もない。あえていうならば、feedlyが人気らしいが、あそこはすべての記事が広告リンク経由になっているから、莫大な収益が得られているはずだ。ワンクリック0.1円だとしても、1万人が平均1日100アーティクル読むだけで10万円、世界的に利用者がいるはずなので、その1000倍は稼いでいるはずだ。その意味では、Flipboardのような、マガジン形式にするサービスも同様にアクセス解析等で収益を得ているはず。RSSフィードを活用している人は、自分がどれだけ相手の事業に貢献しているのか、儲けさせすぎていないか考えてよいのではないだろうか。

一方で、tt-rssのモバイルアプリとしてAndroid用があるが、これも決してよいUIではなく、改善が求められると思っている。それ以外はモバイルWebに対応させる手段しかなく、ttrss-mobileは簡単だが素朴にすぎ、g2ttrss-mobileは僕のところでは動かなかった。

しかし、iPhone限定ながら、Google Reader用RSSリーダとして非常に洗練されたアプリであるReederから、tt-rssにアクセスできるプラグインがあることを検索で知った。

tt-rssのフォーラムで公開されている、Feverプラグインがそれだ。Feverという、なにやら閲覧履歴からおすすめを温度で提示してくれるらしきフィードアグリゲーションサービスがあるようだけれど、そのAPIを模したプラグインがtt-rss用として提供されている。現在のバージョンは1.2。スレッドトップの記事のattachmentのところにリンクされているので、zipファイルを展開し、自分のtt-rss/pluginsの下に展開し、Webの設定からプラグインを有効にしてやればよい。Reeder側からはFeverの設定として、自前のtt-rssサーバのFeverプラグインのURIを指定し、tt-rssの自分のユーザと、プラグインで設定したパスワード（tt-rssのユーザパスワードとは独立）を設定すればよい。メールアドレス入力をするようReederから指示されるが、そこは無視してユーザ名を入れればよい。

iPadの場合、タブレット向けUIを犠牲にしてiPhone用アプリをそのまま使うか、4種類のアプリがApp Storeにあるので、それを使うことになる。ひと通り見てみたが、いずれもtt-rssのWebインタフェースを超えるものではなかったので、無料の「Tiny Reader」で十分ではないかと思う。300円のTTReaderはスクリーンショットでは一見よさそうに見えるが、特にこれといった機能があるわけではなく、シェア機能に「Pocketに入れる」がある程度だったりする。Reederの利点であるMobilizerを通すものはひとつもないので、Mobilizer必須ならば、ReederのiPhone版一択だが、個人的感想ではそれほど悪くないと思っている。

（追記：「tt-rss Reederテーマ」を試してみた。PC上のChromeでは素晴らしい表示。機能もかなり近づけられていてたいへんよいが、iPadのSafariではやや遅めの印象。iPad Airなど最近の機種ではどうかわからないが、iPad 3では厳しかった。）

iPhone 5sまつりに参加してきた

この夏のアメリカ長期出張で、アメリカのサービスの悪さはITで補われていること、そこに特にiPhoneの存在が大きいことを強く印象づけられた。

Androidでは、たいていだめ。Google Mapsはとても便利なんだけれど、iPhoneのAppleマップもとても改善されていて、十分使い物になる。

車社会のアメリカでは、西海岸の大都市を除いて公共交通機関の案内はひどく悪い。そもそも飛行機でさえ、UA（ユナイテッド）はチェックインした客が搭乗しようがしまいが、なんのコールもしない。それ以前に、搭乗開始のアナウンスさえマイクを使わないから、ITなしでは搭乗カウンター前に1時間前から陣取って、いつ整列の指示をするのか見張っていなければならなかった。UAのアプリを入れていれば自動で通知があるから、その辺歩いたり食べたりしていても大丈夫なんだが。さらに、プライオリティパスさえあれば列に並ばなくていいから、スマホの呼び出しでぶらりと行けば乗れる。僕はとにかく格安チケットで最低ランクのエコノミーばかりだったから、何便も寝過ごしたとかスマホの画面見て下向いている間に飛行機が飛んでしまったとか、余分な出費と無駄な時間をずいぶんと過ごした。

飛行機もそうだけれど、鉄道路線の案内も決してよいものではない。そもそもどこに駅があるか、観光都市ならインフォメーションで地図をもらえばいいけれど、そうでなければ地図サービスのお世話になるしかない。バスはもっとひどくて、西海岸は比較的表示が多いのだが、ピッツバーグはバス停は単に「BUS STOP」のカードがついた杭が立っているだけ。それがどの路線でどこ向きで何時にどこへ行くのかなどは全く書かれていない。逆向きの場合、バス停さえなく、降りるときに停車場所をきいておかないと、次のブロックだったりして途方に暮れることもあった。

で、だいたいお決まりは「Webサイトを見よ」。URLだけ書いてあったりする。かといって、バス停を探そうとすると、最初に「正確な住所を入力せよ」と投げ出されて、部分一致検索とかさえなかったりするので、大きなPDFの路線図を小さな画面で拡大して、いまいるらしい場所に近そうなバス停の名前を探したりするのだけれど、「なんとかストリート」がむちゃくちゃ長かったりするので、その「なんとかアベニューの交差点」といわれてもアベニューが見つからなかったりするのであてにならない。

その点、Google MapsもAppleマップも丁寧にバス停の位置を現在地からナビしてくれるし、何時発車の何番バスにどこまで乗ってどこで乗り換えればいいかまで表示してくれるから、画期的なわけです。というか、交通会社がなんだかそのせいでシステムの改良をさぼってるんじゃないかと思う。

それから、食事や買い物に絶対に必要なのがYelp。店の公式サイトはなくてもYelpには掲載されていたりするし、Yelpの☆4つ以上でない店は基本的に信用できない。また、ちょっとしたレストランならTables.comで混雑状況を確認して、即座に予約を入れなければ数時間待ちとかその日は入れないとか平気である。

YelpはたしかiOSしかなかったはず。Web版もあるけどiOSアプリのほうがずっと見やすい。僕はWalmartで買ったT-MobileロックのかかったNokia Lumia 521を$125で買ったものしか現地の携帯は持っていなかったので、Google Mapsでかなり助けられたけど、Yelpの恩恵は、ひとえに同行してくれた方のおかげだった。

というわけで、貧乏人がiPhoneを持つチャンスは、当面のところ、今朝の行列での機種変するしかなかった次第。ただ、日本のキャリアはまだSIMロック解除ができないし本体持ち込みでSIMだけ契約することもできないので、日本のキャリア縛りを買って、海外ではローミングで使うか、現地キャリアのMobile Hotspot（日本で言う、3Gルータ？LTEになってなんて言うんだろうか？）にWi-Fiで接続して使うかのどちらかか両方。

キャリアアンロックやSIM Free版に期待をしている人も多いようだけれど、少なくともドコモはLTEを自社販売のiPhoneでしか使わせない方針だし、他社もiPhoneは特別扱いだからプリペイドSIMが使えるのか、また結局それらは3Gまでなので、LTEには接続できない。そして困ったことに、LTEでは接続できても3Gはさっぱり、という地域がどうも身の回りで増えている状況があるので、観念してドコモの機種変を選びました。

というわけで、「まつりに参加」と書いたのですが、さすがにApple Storeの長大な行列に加わってメディアの取材を見て面白がるほど若くはないので、今回は名古屋市内の金山駅前ドコモショップに並ぶことにした。ひとつは、キャリアの契約にApple Storeの店員が慣れているかどうかの心配のほうが、ドコモの社員がiPhoneの取り扱いに慣れているかの心配を大きく上回ったからという事情もある。

昨夜7時の閉店時刻にたまたま金山駅を通過する用事があったので、ドコモショップのほうを眺めたところ、たったひとり、大学院生風の人がいただけだった。実はこのときはまだ決心は固まっていなくて、しかし各店在庫が10数台との噂から、この時間でこの人数なら大丈夫ではないかとの勇気を得て、職場から防寒用の毛布一枚を持ちだして野宿することにした。

ドコモショップは駅に面しているものの、裏通り側なので道が狭く、車の量も、スピードもたいしたことがないから結構静か。念のため、手持ちのガジェットはすべて満充電にしてKindleで読みかけの洋書も用意して終電での到着に臨んだけれど、その時点ではまだ2人目がいただけだった。結局3番が確定し、それとともに入荷量の掲示があり、安堵することとなった。

iPhone 5sは、シルバーとゴールドは入荷ゼロ。スペースグレイのみ。16GBが12台で32GBが13台で64GBが10台とか、そんな感じだった。5cはイエローは0だけれど、あとは20数台ずつ入っているようだった。

色に関しては、もともとグレイを黒いケースに入れて、iPhone 4みたいな真っ黒にするつもりだったので問題なし。安心して、よそはどうかなとTwitterのTLを眺めたり、あまりたいした情報が流れないので飽きてKindleで読書したりしていたのだけれど、隣が横になって眠りはじめたら、つられて眠くなって、毛布をかぶり、カバンをマクラにして眠り込んでしまった。さすがに深夜早朝は冷え込んだようだが、魔法の毛布のおかげで汗ばむほど、歩道のタイルも心地よく、枕の加減もよくて熟睡できた。

朝5時半ごろ目覚めると、警備の人たちがロープの張替えをしたりしながら他の行列の状況を互いに電話で交換しあったりしていて、やはりApple Storeは200人とか、別のどこかは0人とか、そんな声がきこえてきた。6時前を待って駅前のトイレを使って駅前のコンビニ（すぐそばのファミマはなんとなく気恥ずかしくて避けた）で朝食を買って食べた。この時点でまだ8名ぐらいだったような気がする。また眠りこけて目が覚めると、8時45分とかそのぐらいで、ドコモショップの店員から整理券と注意書きの束を配られた。3日前に、この店で見積もりや説明を受けているので、特に新しい内容はなかった。この時点で、20名ぐらいだったのではないか。

午前9時ちょうどに店が開き、従業員の整列の前を通って（いま思えばApple Storeのようにハイタッチなどしてあげればよかったとは思うが、寝ぼけていたので、日本人らしく「おはようございます」とか言いながら頭を下げて通過した）、カウンターに案内された。

こちらは事前に契約内容も決め手あり、手続きの順番も把握していたので、担当の応援の若手スタッフを暖かな目で見守るような感じで粛々と手続き。貧乏なので一括払いはできず24回払いなので、与信調査にちょっと時間がかかった以外は、いわゆる回線開通の儀式などはこちらのほうがよほどわかっているので、自前のドコモ回線のMobile Hotspotを使い、ドコモのキャリアプロファイルをダウンロード、インストール（署名がなかったんだがどういうことか）もこちらで行い、それからOS起動後の諸手順もこちらで教えてあげたりしたので、なんだか1番や2番の人より早く終わってしまった。といっても、10時半ぐらいにはなったんだけれど。

というところで、長くなったのでこのエントリーはここまで。次のエントリーで盛大にぼやくことにする。

iOS 7でのプライバシー設定（改善、か？）

iOSが行動ターゲティング広告会社にデータを売っている話が、iOS 6の頃にあった。

iOS 7でそれがどうなったのか気になっていたけれど、設定を見つけることがきょうまでできていなかった。ようやく気になるいくつかを見つけたのでこちらでご報告申し上げる次第。

まず、行動ターゲティング広告のIDについては、設定アプリの「プライバシー」の、いちばん下にずばり「広告」というのがあった。内容をみるに、これが以前問題になったものと共通する項目のようだ。明瞭な名前になったのは非常によろしい。

そして、デフォルト設定だが、「追跡型広告を制限」が「オン」になっている状態。以前のことがあるのでどちらの意味か迷ったが、いったんオフにして再びオンに戻すことに気づいた次第。したがって、「デフォルトで行動ターゲティング広告のIDは出さない」。デフォルトのままでよいということになる。これもよろしい。

というわけで、他社への販売業はやめたようだが、iOSには、iAdというアプリ組み込みの広告表示機能がある。iAdのライブラリを使ったアプリが出す広告を 妨げるにはそれこそ脱獄でもして機能を無効にするTweakでもあてるしかないのだが、広告の精度を向上させるには位置情報（GPSのデータ）を使うというのが流行らしく、Twitterアプリは位置情報を要求するときに、「広告の精度を高めます」と告白してくれる。Facebookは黙っているが、まぁ、位置情報をとったらそれを何かに使おうとはしているだろう。広告も含めて。

iAdももちろん、位置情報を利用する。これは例によって深いところに隠れていて、「プライバシー」→「位置情報サービス」→「システムサービス」のなかにある。上から4番目の「位置情報に基づくiAd」がそれだ。「かまわないでくれ」と思う人はこれを「オフ」に設定変更すべきだろう。

ほかにAppleがiOSで仕掛けたものといえば、Wi-FiアクセスポイントのIPアドレスとGPS位置情報との連動で、Androidでもそうだが「位置情報を正確にするためにWi-Fiをオンにします」というのは、屋内でGPSの衛星が使えないときにマップで自分の位置をより妥当な位置に表示するために集めているデータの組み合わせだ。未知の場所、特に海外で勝手がわからないときなどにマップアプリは必須なので、これを嫌うかどうかは趣味の問題になってしまったような気がするところ。こうした「安価な」手段を許さない人が以前からたくさんいれば別のイノベーションが起きただろうが（屋内位置情報に関する研究が、もっと以前から促進されていただろう）、もはや手遅れなのかなと僕は思っている。

この、「システムサービス」内にある「Wi-Fiネットワーキング」と「携帯電話通信網検索」というのは、要するにそういうもの。一見、「使えるWi-Fiスポットを教えてくれるのかな」とか「携帯の電波が届く場所を教えてくれるのかな」とか、サービスを受けるほうで想像してしまいがちだが、実は自分が情報提供者になるという意味なのでお間違えなきよう。マップアプリにエンドユーザーが課金されないのは、エンドユーザーが位置情報という貴重な資金源を無償提供しているからという視点は忘れないほうがいい。「無料サービスの資金源は、あなた自身だ」というネットサービスの格言がある。

それから、以前裁判所だったか司法省だったかからAppleが大目玉を食ったGPSデータ垂れ流しの件だが、それに関係するのは「診断/使用情報」だろう。トップに戻って「情報」のなかに入ると、下のほうにあり、iOS 7のデフォルトでは「送信しない」となっている。

送信しないのだから気にする必要もないのかもしれないが、ここにはデフォルトでGPSなど位置情報が入っている。これを停止したければ、再び「プライバシー」→「位置情報サービス」→「システムサービス」で、「診断/使用状況」をオフにすべきかと思う。

ひとまず気がついたのは、こんなところ。

Androidアプリで「アカウントの取得」させることの危険性

しばらく前に中古のGalaxy Nexsusを購入し、Androidの世界に身を投入しました。

GoogleがAndroidを買収して自己のプラットフォームにしていく過程で、Jobsと同じように「盗んだもの」（僕の感覚では、Sunから盗んだものが多い―実際の裁判では、争点がAPIに限定されて、Sunとは無関係という判決となりましたが）ということで、またマルウェアやガワだけ替えた偽アプリなどストアの品質などにも懸念があり避けていたのですが、Jelly Beanを入れてみると、ICS以後ようやく本気で取り組まれたfluid（表示の滑らかさ）のおかげで、「使える」プラットフォームに育ったということがわかりました。

Nexusプランドを選ぶのは、やはりカスタマイズされていない生のAndroidに触れて評価したかったためでしたが、邪悪そうに見えても自分の目と手で評価しなければわからないことは多いと実感しました。

ただ、懸念されたストアの品質ですが、たしかにiOSのApp Storeと比べれば身元不明な怪しげなアプリが目立つ印象はありましたが、iPhoneを誰もが持つようになって以後のApp Storeとどれだけ違うかというと、それはなんとも言えないように感じられました。

とはいうものの、Google Playはアプリが要求する権限を明示しており、これがアプリ内の設定ファイルから自動生成されているならば嘘ではないと思われるので、クリーンなアプリかそうでないかの判断がしやすいのはApp Storeにないよさと思うようになりました。App StoreではAppleの審査のみが唯一の基準で、ストアに出ているものを信用するしかありません。しかし、Appleは端末固有番号であるUDIDを取得するアプリは審査しないといいつつ何年も放置しています。少し前の表明でも、UDIDを取得するアプリは「新たに審査対象になる場合（バージョンアップを含む）」に審査から落とすということで、現在ストアに出ているアプリで放置されているものは、いつまでもUDID取得機能が残ったままインストールされてしまうという体たらくです。

UDID取得が嫌われるのはもちろん端末が追跡されること、UDIDをキーにして、様々なプライベートなデータを集約できてしまうことにあります。とはいえ、以前の記事にも書いたように、Apple自身が端末追跡IDをOSの機能に載せており、それを広告屋に売っているという共犯関係にあるのですから徹底することは期待できません。また、連絡先などをごっそりもっていくアプリも堂々と審査を通っています。TwitterやFacebookもそうですが、これはあとから同期をオフにできるので、いちいち連絡先を空にしてからインストールし起動するなどしていれば被害は防げるという逃げ道はありそうです。

さて本題。Androidアプリの場合、Google Playに載っているほとんどのアプリが、「アカウント情報へのアクセス」要求をします。好意的に考えるなら、「アプリが固有のアカウントを作成すること」であろう、これはAndroidアプリすべてに共通の仕様であり、Androidの下にあるLinuxのレベルで、アプリごとに違うアカウントで動くようにし、他のアカウントで動作するアプリとはデータ共用できないようにしてセキュリティを保っていることを指しているはずだ、といえるかもしれません。単にそれを言っているだけなら問題はないかもしれません。しかし、アクセスに「読み取り」があった場合、これは端末にどのアプリがインストールされているかをどこかに送信するという意味になります。これはプライベートな情報であり、嫌がる人は多いのではないでしょうか。

Androidアプリの解析結果を確認できるサイトsecroidは、内部で使用されているライブラリやフレームワークについても検証し、危険性のあるライブラリやフレームワークあった場合、どんな理由でそれが危険なのかという情報提供がなされることで、スキルは必要なものの、より深い安全性判断ができます。iOSでは危険かどうかの判断はAppleにすべて委ねられており、ストア利用者はそれを知るすべはありません。

まとめると、Google Playでアプリのインストール時に表示される、「要求される権限」には必ず目を通しておきたい（自己責任ですが）ということ、ただし表示されている内容には、わかりにくいプライバシ侵害が含まれている、ということになります。

ところで、iOSで自由なカスタマイズをしたい、Appleの審査を通らなかったアプリを入れたいという理由で「脱獄」（Jailbreak）をしたがる人は多いのですが、iOSにおいてjailはほぼ唯一の安全弁であり、これを外せば単なるパソコンと同等かそれ以下のセキュリティ状態に置かれるということは覚悟しておくべきです。jailはFreeBSDが最初に導入したかと思われるのですが、Unixに少々古くから含まれていたchroot()機能、すなわち、アプリ側から見えるトップディレクトリを、特定のディレクトリに設定することに加え、プロセス間通信やシステムコールなどを完全に分離し、そこでセキュリティ上の問題が生じてもOS全体には影響が及ばないようにする技術でした。iOSはこれを取り入れ、アプリがアクセスできる範囲全体を「サンドボックス」（お砂場）と呼んでいますが、AndroidとiOSの大きな違いは、iOSアプリが利用するObjective-Cランタイムの驚くほどの柔軟性にあります。オブジェクト指向技術の言葉でいえば、mixinが簡単にできてしまう作りです。たとえそれがOSのオブジェクトであっても、アプリ側から簡単にメソッドの追加や置き換えができてしまう強力な自由度が諸刃の剣となるのです。脱獄後にはいろいろなtweakを組み込むことが楽しくなりますが、これこそが、OSの機能を柔軟に変更している具体例です。

よくあることですが、SafariのエンジンであるWebKitには、いくつもの脆弱性がつねにあります（少ない、といってもゼロにはならない）。したがって、それほどたいした脆弱性でなくても、うまくexploitを作ればSafariをアクセスするだけでSafariが触れる範囲内で何かコトを起こされてしまう可能性はあります。サンドボックスが機能していればSafariだけの問題で済みますが、脱獄していた場合を想定したexploitの場合、OSごと乗っ取られる可能性を考慮しなければなりません。

とはいえ、UDIDや連絡先の保護、またファイアウォール設定や広告ブロックなどをしたい場合には、現状では脱獄が不可欠というジレンマがあります。Androidでrootをとるというのは実はたいしたことはなく、/bin/suという管理者権限に移行するコマンドが削除されているので、それを入れてやるというだけのことです。rootにはパスワードがついていませんから、root権限を使って便利になるよ的な説明で釣ってLinuxを乗っ取るトロイを仕込むということはあるかもしれません。報道によれば中国にはAndroid携帯による巨大なボットネットができているといいます。

iOSについては、脱獄以外の手段での何らかのカスタマイズ手法の開発、Androidを含めるならば、素性の分からない人物の作成したアプリケーションに気をつけ（ストアの評価はステマもどきがほとんどです）、甘言には乗らない心構えが必要かと思います。

iOS 6.1 OTAトラブル

Apple税を払っているので、iOS betaが入手できる。いまのところ特にこれといってアプリの開発を行っているわけではないが、少なくともiOS 6.0はWi-Fiまわりが特にひどかったので、iOS 6.1 betaを入れていた。先日までにbeta 4までOTAして動いていたのだが、しばらく触っていなかったところ、奇妙な現象が起きた。

いままでOTAは、「設定」アプリから「ソフトウェア・アップデート」を開かなければ開始されなかったはずなのだが、なぜか今朝、6.1正式版に上げてみるかと電源を入れてみたところ、いつのまにかOTAが終わっていて、Wi-Fiの選択をする画面が現れたのだ。

Wi-Fiの選択肢の下には、「iTunesでアクティベートする」の選択肢があり、どうやらAppleサーバへのiOS署名の認証を待っているようだった。

ここで、どうせ充電のためにMacに接続していたのだから、iTunesでアクティベートしてみればよかったのかもしれないが、なんとなく複数あるWi-Fi APのひとつを選択して先に進んでみた。すると、「アクティベートに失敗しました」画面となり、「iTunesでアクティベートするか、数分後にもう一度試してみてください」というのだった。下に「再試行」のボタンがあるので、再試行すると、再びWi-Fi APを選択する画面に戻る。しかし、今度は「iTunesでアクティベートする」が消えている。何度も試し、別のAPも試し、最後には携帯回線のルータへ接続してみたのだが、いずれも結果は同じ。

ただひとつ、Wi-FiのAPを別のものにした瞬間、一瞬だけ「iTunesでアクティベートする」の項目が現れるのだ。そこを狙ってタップを連打すると、選択を示す青になって先に進む。iTunesはMac上で起動している。だが、結果は同じだった。

どうにもならないので、Apple Careサポートチームに連絡をとり、状況を説明した。彼らが持っている障害データベースにも該当するものはないらしい。そこで、Xcodeから何かできるかもしれないと思い、Xcodeを起動しながらその旨説明をすると、シニアアドバイザーと交代するという。ちょうどXcodeのバージョンも上がっており、更新しろとXcodeが言うのでアップデートしている間にシニアアドバイザーと話をした。

だが、彼も現象が理解できないらしい。逆にこちらがXcodeでどうするのか期待されてしまった。とはいえ、できることはプロビジョニングの更新ぐらいであった。しかも、どうもそれさえ成功していない。「このバージョンのiOSはサポートしていない」とか、わけのわからない表示になっている。

こうなると、シニアアドバイザーとしても、「復元」を薦めるしかない。だがこちらは先日マルウェア駆除のためいったん大掃除して以来、一度もバックアップしていないのだ。残念ながら、30GB超のバックアップを置いておけるディスク領域を持ち合わせていないためだった。

電話口でぶつぶつ言いながら、諦めて「復元」ボタンを押すと、バックアップをするかときいてくる。dfしてみると、なんとか入りそうなぐらいの空きはあるので「OK」を押すのだが、バックアップすることなく復元の確認に入った。そして「復元する」を押すのだが、エラーとなる。なんだそれ。

というわけで、こりゃDFUに入って完全に新しいiPadとして復元する以外に手はなさそうだと思っているところに、電話の向こうも「復元モードで復元しましょう」と言う。いわゆる、「iTunesに接続する」画面のことだ。

それで、DFUに入る手順で復元モードに入り、iTunesから「復元」を押すと、当然のことだがiOSのダウンロードが始まった。そして、インストールが始まり、Appleの認証を通して購入時と同じ、「ようこそ」画面になった。順に選択を行い、アクティベートのところでは「Wi-Fiを使わずにアクティベートする」という形で進め、なんとか初期状態になったところで電話を切った。

シニアアドバイザーの意見では、iOS 6.1 beta 4から6.1正式版へのOTA固有の不具合ではないかというのだった。たしかに、そんなところかもしれないし、そのあたりで納得しないとやっていられない。なにしろこちらはアイコンの配置も、iCloudに依存しないアプリ固有のデータも、in-app Purchaseで購入したあれこれも全部失っているのだ。

これから、それらをちまちまと作業して、できるところまで戻してやることになる。いちばん困るのはin-app Purchaseしたもので、アプリによっては実際に購入手続きに進んでみないと、すでに購入したかどうかわからないものがある。すでに購入した場合は課金されないだけという、たいへんスリリングなものだ。いったん間違えて、記憶に従って、買っているはずだと思うものを選んで購入手続きを続けていたら、結構な金額を請求されたことがあった。

またそれを繰り返すと思うと気が重くなる。

シニアアドバイザーは電話口で「デベロッパーの方に申し上げるのもナンですが、できるだけこまめにバックアップはとられたほうが」と繰り返していた。ごもっとも。

iOSの行動追跡回避設定について

結構あちこちで語られているので常識ではないかと思っていたのだが、意外と知られていないようなので、念の為に書いておきます。

iOS 6以後、広告配信のための行動追跡機能がデフォルトでオンとなっています。Appleは以前CarrierID問題など、利用者へのわかりやすい説明をしない形での様々な行動追跡問題を起こしてきましたが、今回もそれの繰り返しです。

GoogleやFacebookが様々な形でデバイスやサイトの利用をデータとして集積し、分析して、建前上は「サービス向上のため」となってはいますが直接的には商売（広告屋に売るなど）に使っていることが批判されますが、Appleも同類です。

まず、「設定」アプリを起動します。

「設定」アプリを起動

「一般」を選択します。

「一般」を選択

次からが、何らかの意図を感じるところなわけですが、Appleらしいといえばそのとおりというしかないわけですが、設定変更項目が、「情報」のところにあります。

なぜか設定は「情報」のなかにある

画面をスクロールしていちばん下から3番目に、「アドバタイズ」という不自然な日本語があります。これを選択します。

いちばん下までスクロールしていくと、ようやく「アドバタイズ」の項目が

すると、またもや不思議な日本語「追跡型広告を制限」があります。

なんだか、制限すると悪いことが起きるような印象を受けますが、追跡されたくない人は制限する設定をすべきなので、これを「オン」に切り替えます。

なんとなく抵抗を感じさせる不思議な説明だがかまわず「オン」に

これで行動追跡停止が設定される

ついでなので、その下にある「Advertising Identifire（広告識別子）をリセット」も押しておきましょうか。たぶん、以前追跡されていたときと別のIDが生成されるのだと思います。

ついでなので、追跡用IDも作りなおしておく

設定はこれだけですが、まだ罠があります。例えば、OSのアップデートなど、何らかの設定を引き継がなければならないような変更を加えるときに、この設定は再び、「オフ」に戻ります。（ただし、今回iOS 6.1 beta2からbeta3へのOTAでは解除されなかった）

もしかすると、他にもiTunesと同期する時とかに外れたりするかもしれませんので油断はできません。再起動したときも怪しいかもしれません。とにかく、隙があればこの設定はすぐに「オフ」になるので、たびたび確認して、「オン」が維持される条件を確定するまで安心できませんが、将来的にその条件が維持されるかどうかも保障できないので、何事かあったときにはすぐにここの設定に戻るようにするのが賢明ではないかと思います。

Saurikが集めている情報

Cydiaには、「Manage Account」という機能があり、Cydia経由で購入した有料アプリやTweak等を、あとからGoogleアカウントもしくはFacebookアカウントを使ってCydiaにログインすることでいつでも「購入済み」としてダウンロード&インストールできるようになっている。

この機能はとても便利だ。同じアカウントからならば、複数のiOSデバイスに、どのバージョンのiOSからでも同じ有料アプリやTweaksを追加の費用なく入れることができるからだ。

もちろんこれは、AppleのApp StoreやGoogle Play、Microsoft Storeなどとも同じで、それぞれのアカウントにアプリがひもづけられ、ひとつ購入すれば同じアカウントで使う限りどのマシンやデバイスにもインストールできる。Cydiaがこれらと違うのは、Apple, Google, Microsoftがそれぞれにアカウントを作らせて、それぞれが独自にアカウント情報とアプリ情報を管理しているけれども、CydiaはGoogleアカウントやFacebookアカウントでログインするので、Cydia用のアカウントは不要ということだ。

少しネットの事情に詳しい人なら、他にもWebサイトで独自のアカウントを作らせずにGoogleやTwitter、Facebookのアカウントなどでログインできるように作っているところが結構あることをご存知だろう。そして、Open IDやOAuthなどといったしくみについてもご存知の識者もおられることだろう。

ここから類推するならば、CydiaのバックエンドであるAmazon AWSサービス側にはアカウント管理のしくみはなく、いわゆる（広い意味での）Open IDで利用者管理を行っていると考えるところだろう。つまり、Cydiaは利用者識別情報とそれに関する購入情報の対応を持っているだけで、それ以外の情報は一切持っていないはずだと。

ところが、あるときGoogleアカウントのダッシュボードで、関連付けられているアプリ及びアクセスされる情報を確かめる必要があったとき（2要素認証を設定すれば必ず目にすることになる）、Cydiaが3つのアクセスをかけていることを知ってしまった。ひとつは、個人のプロフィールなどアカウントへのフルアクセス、次に連絡帳、そしてGMailだ。ここに魚拓を貼ろうと思ってダッシュボードを開いてみたが、いったん2要素認証を外して再設定したのち、一度もCydiaを使っていないため、すべてがクリアされており、魚拓がとれなかった。もしこれを読まれた方で、心当たりのある方は、ご自身のダッシュボードを確かめてみていただきたい。「Googleアカウントに許可された項目」、英語なら「Websites authorized to access the account」となる。

Facebookの場合、僕はFacebookには詳しいプロフィールを入れているため警戒してCydiaには使っていないので、どのようになるかはわからないけれども、おそらく同程度の内容にアクセスしている可能性がなくはない。心当たりがおありの方は、FacebookサイトでCydiaが何にアクセスしているか確かめてみていただきたい。

Saurikが集めた情報を何に使っているのかはわからない。また、それを示唆する調査が行われたという話もきいたことがない。けれども、瞬間風速で世界中から同時に莫大なアクセスがかかってもびくともしないCydiaのことだから、おそらくAmazon EC2で無制限にスケールアウトするような契約になっていても不思議ではない。そして、そのために支払っている費用は膨大な金額だろう。CydiaはWebアクセスするほぼすべてのページに広告が入っているけれども、果たしてその広告収入だけでどこまで費用を賄うことができるのか、あるいはそれ以外の資金が投入されているのか、もちろん誰にもわからない。

もうひとつ、Cydiaで購入したアプリやTweaks等はすべてSaurik名義での請求になる。たとえそれが$0.99のものであっても、数$のものであっても、いったんSaurikの口座を経由して作者に支払いがなされているのは間違いない。実際にファイルが置かれているリポジトリは外部にあることが多いけれども、それでもPayPalからの請求書には必ずSaurikIT, LCCと書かれている。これまで疑問には思わなかったけれども、Cydiaで「購入済み」と表示できるようにするためにはCydiaのバックエンドで購入行為を管理するというのはわかるものの、Saurik名義ですべて請求する必要が絶対にあるかどうかには議論の余地があるように思われなくもない。

Cydiaはapt-getをコマンドラインで行わなくてもよく、登録したリポジトリの更新情報も管理してくれる、よくできたアプリだ。そして、Cydiaそのものが死ぬときはCydiaがデプロイされているAmazonクラウドのリージョンが死んだときだけで、瞬間風速で困ったことになるのは、外部のリポジトリが負荷に耐えられなくなって死ぬとかストールしているときに、更新情報が得られなくてCydiaの画面のなかでタイムアウトするだけだ。Saurikはそのためのバックエンドの改良や維持管理の責任を十分に果たしているとは思う。ただ、それと、ログインに使ったアカウントに対するほぼ無制限のアクセスを登録することとは話が少し違うのではないかと思うのだが、勘違いなのだろうか。

iOSデバイスへの無制限のアクセスを可能にする自由への対価として、個人情報をSaurikに渡すことが妥当かどうかは考えてもよいことだろう。早い話、Cydiaでログインに使うアカウントは普段のGoogleアカウントとは別のものを使えばよいのだが、その場合、もしそれまでに購入した有料アプリやTweaksがあったとしても、それらは（必要ならば）買い直しになる。もしくは、無料のものを取得するためだけに使っているならば（CydiaがiOSのなかを探っているのではない限り）懸念することはないだろう。ただし、Cydiaが動いているということは、Sandbox機能が外されているということだから、任意のアプリがiOSのあらゆる場所をアクセスできるということは考慮すべきとは思う。

iOS 6はTwitterのみならずFacebookとの統合が進み、どこからでもツイートやポストができるし、両方を登録したデバイスでツイートすればFacebookにも勝手にポストされる。

自分のFacebookアカウントで確認してみたところ、TwitterアプリはFacebook上のありとあらゆる個人情報にアクセスするような表示が出た。TwitterアプリはFacebookサイトから削除ができたけれども、Facebook公式アプリはサイトに現れないので、どうなっているかは全くわからない。ただ、Facebookのありとあらゆるところ（設定変更など）が触れなければ欠陥アプリとなるおそれが大だから、すべて許可なのだろう。iOSとFacebookの「深い統合（deep integration）」の意味するところについて、そろそろよく検討してみたほうがいいかもしれない。

問題だったWebKitのバグはiOS 6.0.1で修正されたそうだ

先日やられたWebKitのバグは、きちんとAppleに伝えられ、iOS 6.0.1で対策されたようだ。threatpostが伝えている。

Apple Patches Kernel, Passcode Lock and WebKit Flaws in iOS 6.0.1

https://threatpost.com/en_us/blogs/apple-patches-kernel-passcode-lock-and-webkit-flaws-ios-601-110212

そもそもカーネル内部に入り込める脆弱性があったというのは驚き。kext用に用意してあったOSBundleMachOHeadersというキーでカーネル内部のアドレスを取得でき、そこはADSRしてあっても直接アクセスできるから便利という話のようだ。

Passcode LockとPassbookの関係は各地で既報の通り。デザインの問題と思う。

最後のWebKitの問題で、僕がやられたのはおそらく前者のJavaScriptの配列の扱いに関するものだと思われる。どうやらここに何らかの脆弱性があって、細工したJavaScriptを食べさせれば任意のコードが実行可能だったらしい。

後者はSVGに関するコードに、ダングリングポインタを放置しているところがあるらしく、当然戻り先がおかしくなるのでSVGを含むページをうまく細工して任意のコードを実行させるという話。

とりあえず、すでに攻撃コードが配布されている脅威は対策されたということなのだろう。

ただ、iOS 6.0.1もまだWi-Fiに問題があるような気がしている。6.0は問題外だったが、アンテナ立ってるのに通信しないケースが、まだ6.0.1にも残っている感じがする。そこで、Apple税を払っているので6.1 beta 1にしてみたら、結構いい感じ。iOSに関してはいつものことだが、6.0より軽くなっている感じがする。

いい気になってiPod Touch 4GだけでなくiPad 3までiOS 6.1 beta 1にしたのだが、WOWOWのオンデマンドアプリがiOSバージョンチェックで動かなくなってしまったというオチ。いやはや。

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

原文はこちら：

https://threatpost.com/en_us/blogs/iphone-5-launches-hackers-explain-journey-working-exploit-ios-6-092112

----

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