STOWAWAYには、Android 2.2のPermissoon Mapがある^[1]。これは、どのAPIを呼び出せばどのパーミッションが必要かわかるマップだが、いかんせん情報量が多くてわかりにくい。また、基本は同じとはいえAPI levelにより多少変化もしている。

そこで、整理のために論文”Android Permissions Demystified”(PDF)を元にして、おおまかな区別を抜き出してメモとする。

まず最初に触れておきたいのは、結局統一したPermissionのポリシーなど無い、ということだ。以下に説明するようにあちこちで権限が持ちだされ、チェックされ、あるいは無視されている。中には無駄にチェックするAPIもあるらしい。よって、現状のAPI Levelでは食い違っている箇所がでることを前提とする。

最初に、Permissionは3種類の脅威レベルに分けられる。

1. Normal Permission: 壁紙の変更など、APIへのアクセスを制限するもの。
2. Dangerous Permission: SMS送信など、API呼び出しにより潜在的に危険をもたらすもの。
3. Signature/System Permission: 署名されたアプリケーションでだけ使えるもの。バックアップやアプリケーションのインストールなど、特に危険なもの。
4. (他、各アプリケーションが独自に定めるPermission)

Android API frameworkの構造は「APIライブラリ」「システムプロセス中のAPI実装」の二つのパートに分割できる。「APIライブラリ」は各アプリケーションの仮想マシンで動作するもの。当然、アプリケーションと同様の制限を受ける。それに対し「システムプロセス中のAPI実装」に制限はない。ライブラリが構文糖としてユーザからのリクエストを代理で受け、裏でシステム側で実行する、といった感じになる。

APIの呼び出しは三ステップで行われる。まず、アプリケーションはライブラリのAPIをinvokeする。次に、ライブラリはライブラリ中のprivate interfaceをinvokeする。このprivate interfaceはRPC stubになっていて、最後にRPCリクエストがシステムプロセスとして、システムサービスに誰が処理してくれるか尋ねる。この仕組みはJavaのreflectionが使われている。

例えば、ClipboardManager.getText()は、IClipboard$Stub$Proxyに引き渡され、システムのClipboardServiceが呼ばれる。

さて、肝心のPermissionのチェックだが、統一ポリシーなどは存在せず、実に色々な箇所で行われる。システムプロセス中のAPI実装でチェックするものもあれば、ライブラリ中で随時チェックするものもある。極一部の権限(INTERNET, WRITE_EXTERNAL_STORAGE, BLUETOOTHなど)は、Unix groupで制御されている。この場合、API側は何もチェックせず、ただinvokeするだけである。

Android NDKで開発できるNative Codeでは、直接にはシステムのPermissionを制御できない。、ソケットやファイルにアクセスする場合、Java wrapperを用意して行うことになる。

Content Providerは、単独のアプリケーションとしてインストールされて他のシステムプロセスやAPIライブラリからは切り離され、抱える情報の保護のために静的/動的なPermissionチェックを行う。アクセス先は、read/writeといった定義と、”content://a/b”のようなpathにより指定される^[2]。

Intentは、全てシステムサービスのActibityManagerServiceを通じて送信される。二つのテクニックによりIntentの送信は制限されている。一つは、Permissionを持っているアプリケーションにだけ送信する仕組みである。もう一つは、システムのIntentはUIDがマッチするプロセスにしか送信しない仕組みである。受信の場合もだいたいはPermissionが必要であり、OSが送信するIntentの受取先を制限している。

(論文では、この後もテストコードを暮ろうとしたらAndroid側が色々アレで大変でしたという話や、APIの分析結果が続きますが、省略。)

1. 一応、本命はapkをアップロードして余分な権限を宣言していないか解析を行えるStowawayの方、のはず。
2. 余談だが、BlackHatなどで発表されたMercuryという「うっかりContent ProviderやServiceに権限をつけ忘れて、publicになっていないか」というチェックを行うためのツールが存在し、最新のAndroguardと組み合わせて使うこともできるらしい(AREには未収録)。

• [BOOK] Application Security for the Android Platform: Processes, Permissions, and Other Safeguards

最近手を出すことが多くなったので、きちんと一冊読んでおこうと確保。薄い本なので英語でも大丈夫。

だらだら公式サイトを見てもいいけど、ウェブだとなんとなく把握しにくいんですよね。適度にまとまった本は本当に助かります。

公式サイトからは辿れなかったのだけれども、どこかにまとまった表は無いものだろうか。

両方共に頂きもの。

「サイバー戦争の真実」については大体ふまえている内容だったので省略。少々新書系な煽りがきついですが、最近のネットワークセキュリティの話題を知りたいなら良い本ではないでしょうか。

「第五の戦場」の方は、元陸自のシステム防護隊初代隊長の方なので、脅威と対応する視点が明確で、思考の良い整理になりました。

おおざっぱには、世界で何が起きているか、どうすれば日本を防衛できるか、何を準備すればいいのか、他国はどう対応しているのか。個々の事例はさほど目新しいものではないけれども、そこにナショナルセキュリティという横糸を通すことで脅威としての位置付けを明確にしています。

サイバー戦は一度見た攻撃は次からは防がれる、だから繰り返しての利用が難しいし、効果がどれほど上がるか予測するのも困難。つまり、鍛えられた聖闘士がその回ごとに新しい必殺技を打ちあっている状態なわけです。おまけにこの聖闘士はウイングマンよろしく「誰でもなれる」。

十分なサイバースキルがあれば、個人であっても国家に戦いを挑める時代がやってきたのだ。

(中略)

しかし、こうした民間人の行動に対する戦争法規は何も規程されていない。

とあるように、攻撃は民間も行えるが防御は民間ではできません。通常の戦争なら民間人への攻撃は避けるべきこととされているが、それすら国家間の合意はとれていません。歴史的には匈奴とかフン族とかの状態なのかな。この後どう秩序だっていくのか、歴史的には…はてさて。

日本の場合、色々な法規があり、例えば自衛隊が原発施設へのネットワーク攻撃を護る…ということはできない。その間にも中国やロシアはどんどんと人材を育成してゆく。そんな色々の状況まで含めて知りたいのならば、使える一冊です。

明日の別イベントとあわせて、話題は矢張り標的型攻撃。人が防ぐというには限界がある(というか、限界になるまで試してくる)ので、あとは人の介在なく防ぐか、発見するか悪影響を防衛するか。そこに色々な考えかたが出てくる。

うちの会社は…まあ部署ごとに微妙にカバー範囲に応じて結論は違うんだろうな。

JVNに似合わない名前をみつけた。ベンダ補足ではなく、珍しくJPCERT/CCからの補足情報があるということは、ハンドリングしている人もしっかりどのような製品かを認識していたのだろうか。

よく考えれば、パートナーシップにおける製品の脆弱性関連情報の取り扱いは、フリーソフトウェアだろうが、旧来のOLS/FSW/PDSだろうが関係はない。そして、ネットワーク越しに攻撃可能ならば、なるほどゲームでも含まれる。ならば、それが同人ゲームであろうとも、サイトをかまえ、パッチを配布でき、製作者が明確ならば何の問題もない。

というものの、普通の製品が並ぶ中で東方の名前を見ることになろうとは…。東方シリーズは二次創作のガイドラインがあるから良いが、市販データ流用とか違法性がありそうな製品の届出がきたら、関係諸氏が延々困るんだろうなあ、きっと。

自作サーバの自主運用で有名だったはてなが、さくらのクラウドでの業務委託に切り替えたとの事。安価に入手できる、用途にあわせつつ適応で組める、といった自作のメリットがクラウドで享受できるようになってきたからなのだろう。サーバ機器のおもりをするにしても、昨今は節電もあれば人件費も相対的に高くなるし、結局のところ運用費用がかかるということだ。

個人ではどうかと言うと、私は以下の点をクリアできれば自宅サーバをクラウドに移しても良いと考えている。なお、価格優位性とか保守体制とか会社の信頼度とか安定度とか、あたりまえの話は省略。

まずは可用性ということで「データが引き揚げられること」。データをベンダロックインされるのではなく、適当な単位で手元にバックアップしておきたい。Amazonなど世界各国で分散すれば1箇所落ちても大丈夫、などというのもあるが、古い人間なのでデータは手元に届くようにしておきたいし、手元が壊れてもリモートがあるという状態にしておきたい。

つぎにいささか職業病的だが「機密性が約款で担保されていること」。元々通信事業者には縛りがかかっているが、クラウドサービスの場合どこまで適用されるのかがいまいちわかりにくい。そのため、オペレータが中身を覗けません、安いからといってマーケティングに利用されません、という保証が欲しい。その分、いざとなったら約款の壁でデータが取りだせませんよとなってもＯＫ。そのための可用性条項だ。

最後に、できれば身元確認を取るサービスであること。クラウドによるサービスの利点は支払いさえあればすぐに取れるような利便性にあることは承知しているが、住所を同定する必要があるISPサービスとの連携、あるいはクレジットカードでも良いので身元や信用の確認を行った上で利用可能なサービスである方が、Pinboardのように◯◯な方々避けとしては望ましい。

実際に移すとしたら、まずはウェブとDNSまわりで様子見して、最後にやっとメールサーバという事になるだろう。IPv6が自宅までなかなかきちんと届かないので、クラウドで試せるならば色々やってはみたい。Vyatta等も気になる。

そして、ここまで書いてやっと気がついたが、どっちみち家庭内でファイルサーバとか動かすと大して消費電力がかわないのではないだろうか。せいぜいISPを移動しやすくなる程度? …まあ気にしない気にしない。

長いので後まわしにしていた日本文化チャンネル桜のインタビュー。そういうチャンネルで、警察庁の標的型攻撃のニュースとあわせて見るとなかなか興味深い。

【伊東寛】サイバー戦に関わる最近の動向・国がなすべきこと[桜H23/7/26]

いくつかの視点が参考になった。警察行動は、相手の脅威に応じた対応しかできない。戦争は、相手の脅威に依らずどこまでも行使できる。これが、日本の話なのかそれとも比較的普遍的な話なのか、どちらなのだろう。

戦争に関わる対象は歴史ごとに増えている。つい前までは軍隊だけでなく爆撃などで後方の民間人も巻き込まれるようになった。それが、ロシアのグルジア進行のように民間が勝手に参加(サイバー攻撃)するようになった。というのは納得。

一昔前は愛国者有志(?)の類が「んじゃ、ちょっと敵国いって勝手に戦ってくるわ」とはできなかったが、今はできるということなのだろう。流石にまだ交戦のきっかけにはならないだろうけれど、Stuxnet等を見ていると必ずしもできないわけではない、と思う。

そう考えると、Windowsのゼロデイ脆弱性一つで色々できるので、政治的にはともかく方法的には攻めるのが有利な時代なのかもしれない。

10年も経つと色々あるものですが、基本的に人はかわっていないわけで、研究内容の紹介の時にはあらかじめ何も言うなと釘をさされたりしてしまいました。見慣れた資料もあるので色々と余談を話し続けられたり、そもそもお互い院生の時代の話までしか知りませんから、エピソードはそれなりにあるわけですし…。

という妙な警戒がありつつも、他の方々を含めて色々と情報交換できて実に有意義な時間でした。

ベンダが「うちの製品にこんな脆弱性があるよ」と公表するための標準形式が公開された。

もちろん独自にいくらでも情報を公開するのは良いけど、標準記述にしておくと他の情報との連携もとれるし、「標準PCに標準のソフトウェアを入れて標準形式で管理、アップデートの情報も標準形式で入手して、影響範囲の算出とかバージョン管理も標準」的なツールまかせの自動化ができると、お役所世界で助かる。

実際、セキュリティ設計の標準化と自動化のための仕組み(SCAP)がアメリカ政府関連で進められており、国内でもIPAがCVE, CCE, CPE, CVSS, XCCDF, OVALなどを展開している。当然、今回のCVRFもそれらの情報と連携することが期待されている。

とはいえ、記事の中にあるように近い情報のOVALですらまだ完全に連携はできず、今後の展開待ちでしょうか。ML、Twitter, Facebookなど数々の情報源からはこういう礼儀の良いデータはでできそうにないですし。CVSSのTMとの連携も気になるところです。