Content Provider and path permissions

Android apps can share data stored in them via a component called Content Provider. The Content Provider can be designed to expose subsets of data to different clients through path permissions. A path permission is a string identifier defined as a permission by the app or a pre-defined permission by Android and used to control access to a particular path exposed by a content provider. A client with access to a content provider that exposes data in that path will further need to request permission to successfully access the data in that path. For example, a content provider C allows clients to read data from a path /user but requires clients to request additional read permission R to read data from the path /user/ssn. Thus, a client with access to C but without permission R will be able to read data from the path /user but not from /user/ssn.

How does path permission work?

When a client attempts to access data protected by a path permission R in a content provider, Android checks if the client has been granted permission R required to access the data. If permission R has not been granted then Android refuses access. A client can request permission R from the user or Android depending on the type of permission required.

What is the vulnerability?

Android uses checkPermission API to verify if a client has the required path permission, and checkPermission API does not correctly check the permissions held by a calling client as described in System/CheckPermission-PrivilegeEscalation-Lean. Therefore, a client without the required permission can access the data protected by a path permission.

How can a malicious app launch an Unauthorized Access attack?

A malicious app can create a client to access a content provider that uses path permissions to protect its data. It can then access the data via the content provider without having the required permissions.

Test Results

We created a Benign app with an exported content provider. The content provider uses path permissions to prevent unauthorized reads from files whose paths start with /user. We created a Malicious app to successfully access the files whose paths start with /user by calling the content provider without requesting for any read permission. We tested the vulnerability against Android API Levels 22, 22, 23, 24, 25, 26 and 27 on an emulator. The vulnerability was successfully exploited on all the tested API levels. To reproduce the exploit refer to the Ghera benchmark InadequatePathPermission.

Contributors

1. Joydeep Mitra
2. Venkatesh-Prasad Ranganath