Android のアクセス制御ポリシーで重要な位置を占めるのがパーミッションです。Android端末上の情報にアクセスするためには、アプリケーションは特定のパーミッションを要求し、許可を得なければなりません。しかし、オペレーティングシステム（OS）に定義されたパーミッションを超えるものについては、アプリケーションはカスタムパーミッションを定義することができます。一般的に、これはアプリケーション自身の機能やデータを保護するためのものです。
このようなカスタムパーミッションは通常、保護レベル「signature」もしくは「signatureOrSystem」で定義されます。この 2つの保護レベルは、「Android Open Source Project（AOSP）」で、以下のように定義されています。
| signature | パーミッションを定義したアプリケーションと同じ署名を持つアプリケーションのみに与えられるパーミッションです。署名が一致した場合、ユーザへの告知なしに、もしくはユーザの明確な承認なしに自動的にパーミッションを付与します。 |
| signatureOrSystem | Androidのシステムイメージ内のアプリケーション、もしくはパーミッションを定義したアプリケーションと同じ署名を持つアプリケーションのみに与えられるパーミッションです。signature の保護レベルはほとんどの要求を満たし、またアプリケーションのインストール先に関係なく有効であるため、この保護レベルの使用はお控え下さい。signatureOrSystem は、複数のベンダがシステムイメージを組み込んだアプリケーションを構築する場合や、共同で構築するため特定の機能の共有が必要なときなど、特別の場合のみ使用します。 |
これらの定義により、Android の開発者は、システムアプリケーションもしくはそれと同じ signature を持つアプリケーションだけがこれらのパーミッションにアクセスできると考えています。大抵の場合、同じ signature を持つアプリケーションは、同じ開発者が作成します。そのため、開発者はアクセス制御が追加されるとは考えていません。しかし、例外があります。
Android の OS は、カスタムパーミッションをその名前で追跡します。一度パーミッションが定義されると、他のアプリケーションはそれを変更できません。例えば、有名なアプリケーション「A」が、そのデータを保護するために、「permission-A」というパーミッションを signature の保護レベルで定義したとします。しかしユーザは、A をインストールする前に、不正なアプリケーション「B」をインストールしていました。もし、B が正規のアプリケーション A から情報を収集するよう設計されていたら、A よりも前に、B が permission-A を作成し、B には permission-A の許可が与えられます。アプリケーションA がインストールされると、B はアプリケーションA の保護されたデータを読み込む許可を得ます。
トレンドマイクロでは、この脆弱性の危険にさらされているアプリケーションが約1万個あることを確認しています。どのアプリケーションがすぐに攻撃を受けやすいかは公開しませんが、この脆弱性を持つアプリケーションを簡単に調べたところ、以下のことが判明しています。
- 有名なオンラインストアで、閲覧履歴が漏えいしている
- 有名なチャットアプリで、ユーザのアプリ内での購買履歴が漏えいしている
- 有名なソーシャルネットワークで、アプリ経由で挿入された偽のメッセージを投稿できる
開発者は、Androidコンポーネント「Activities、Receivers、Services、Providers」へのアクセスを要求されるときは、保護レベルだけに頼らないようにして下さい。「getCallingUid」や「getCallingPackage」といった機能が OS から提供されており、これらの機能は上記のコンポーネントを要求してきたアプリケーションを特定し、必要に応じてアクセス制御を行うことができます。
弊社では、この問題に関し、Google の Androidセキュリティチームに報告しています。
※協力執筆者：Veo Zhang
参考記事：
by Weichao Sun (Mobile Threats Analyst)
翻訳：品川 暁子（Core Technology Marketing, TrendLabs）