セキュリティ

Android APIを追い掛けていて困るのは、どのAPIでどのPermissionが必要かわかりにくいことだ。マニュアルに明記してあることもあるが、大体は「エラーが出たらManifestに」といった場当たり的な対処が推奨されてしまっている。

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

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

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

最近、興味が出てAndroidのpermissionまわりに手を出しているのだけれど、どの関数がどの権限を要求しているのかがさっぱりわからない。

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

両方共に頂きもの。

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

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

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

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

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

(中略)

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

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

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

終日参加。

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

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

JVN#50227837: 東方緋想天におけるサービス運用妨害 (DoS) の脆弱性

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

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

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

はてなの脱「自作サーバー」宣言から「さくらのクラウド」の未来まで　はてな×さくら座談会2011夏 – はてなブックマークニュース

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

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

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

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

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

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

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

夕方から雷雨なので外出できず、Instapaperで溜めているものを消化する。

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

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

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

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

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

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

ドクターT(仮名)他の先生方と、仕事で歓談。業績はある程度追っていたのだけれども、この話を受けるまで、古巣に戻ってきているとは知りませんでした。というのはさておいて。

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

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

【海の向こうの“セキュリティ”】 第57回：脆弱性情報の標準記述形式「CVRF」バージョン1.0公開 -INTERNET Watch

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

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

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

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

たまには流行のネタにのってみる。

モテる女子力を磨くための4つの心得「オムライスを食べられない女をアピールせよ」等 – Be Wise Be Happy Pouch［ポーチ］

Continue reading

PlayStation®NetworkおよびQriocity™（キュリオシティ）への不正アクセスに関する現状と今後の対応について

早速換算した会社がいたようで。意外と安いと見るべきか、思ったよりも高いというべきか。

TRPGゲーマーとしてはルーマニア/モルドバの運転免許や身分証明書、イスラエルのパスポートの値段を見て、「プレイに使えるな」と考えてしまうのが性か。

JVN55714408 IPの実装におけるサービス運用妨害(DoS)の脆弱性について

外部から攻撃してDoS可能な脆弱性か。CVSSも良い値がついている。

で、手持ちのRTはファームウェアが更新されないんですけど、どうしませう。

fladdict » ０円の広域負荷分散システムCloudFlareが素晴らしい件

CloudFlareというサービスが良い値段の分散サービスらしい。稼働率からして安値でも採算があるということらしいが、実際はどうなのか。セキュリティも強調しているので気になるところだ。

実際、クラウドサービスのセキュリティというものは色々面倒なもので、社内でも何人も調べて講座にしていたりする。上物は同じなんだけれども仮想化レイヤが絡んでくるのでそこをどこまで「制度化」するのかというのがキモな気がする。ESXiとかVMMに徹しているものはまだわかるが、Vyattaとかからむと内部でさらに複雑なネットワークとなるのでネットワーク方面のセキュリティまで必要となる。

NISTのSP800-125があるので、一般的にはこのあたりでポリシーレベルを決めれば良いのかな。日本の省庁で出しはじめれば基準になると思う。

2011年版 10大脅威 進化する攻撃．．．その対策で十分ですか？

なんだかんだといいつつも、今年もレビューとして関わったので。

今年はマイナーだった技術がメジャー化するにつれて顕在化してきた脅威が多いかなー、などと言ったりしていました。スマートフォン系の携帯端末の問題も、そしておそらく今年・来年あたりきそうなIPv6の問題も、量が出ないと表にならない問題って結構ありますよね。ちらと触れられている図書館問題なんかもそのきわのところかと。

そういうわけで、普通の人も2011年度のネットワークセキュリティまとめとして見ておくと良いと思います。