TripleMon : A multi-layer security framework for mediating inter-process communication on Android

2.1.1. Attacks bypassing permissions

A malicious application may perform privilege escalation attacks by abusing ICC. As applications may unintentionally expose private components without proper permission protection, ICC can be abused for unauthorized intent receipt and intent spoofing [5]. For example, a malicious application can sniff, modify and replace messages sent by a benign application. Moreover, public components are also vulnerable to capability leaks. Lineberry et al. shows that a zero-permission application may upload without the INTERNET permission by sending an intent to the Browser application [17]. Recently researchers have identified several similar zero-permission attacks, such as making phone calls [22] and playing an alarm [26].

A coarse-grained permission covers multiple capabilities for accessing resources with different sensitivity levels. For example, READ_PHONE_STATE allows an application to read both phone’s state (e.g., if there is an incoming call) and phone’s unique identities [20]. The former is trivial but the latter indeed introduces potential privacy risks. For applications that utilize the phone’s state only, holding unnecessary capability like reading the phone’s unique identities violates the principle of least privilege. In addition, capabilities granted to applications via Android permission system are irrevocable. In other words, once an application is granted a permission, the user has no way to revoke partial capabilities of the granted permission.

System services may fail to protect their APIs with appropriate permissions, exposing sensitive resources to all applications. For example, the RingerMode setting of AudioService is not protected by any permission, allowing a malicious application to silent the phone without user consent. As addressed in [23], only 6.45% of all API methods in Android are protected by at least one permission.

2.1.2. Attacks bypassing the sandbox

Files that are set globally accessible render DAC-based isolation useless. For example, a vulnerability in Skype exposes the user’s profile information and instant messages due to improper file permission settings [10]. Similarly, the file that stores the list of applications is globally readable in Android and any application can access it without extra permission [28].

A malicious application may also exploit Linux kernel vulnerabilities to break the sandbox [7–9,11–13]. These exploits (also known as “jailbreaks”) allow adversaries to escalate their privilege to root privilege and bypass existing security mechanisms. Recent reports have shown the existence of root-capable malicious applications that download additional malware [41] and replace system binaries [42]. Indeed, the occurrence of such exploits is quite high [50] and almost every popular Android device had a publicly available exploit for at least 74% of the device’s lifetime [24].

2.2.1. MAC implemented in the Android system

The history of SELinux has demonstrated the effectiveness of system-centric MAC implementations. Such MAC implementations require patching and/or recompiling the system. In recent years, plenty of security frameworks [1,3,4,6,38,44,51] follow this approach to (1) add kernel MAC for reinforcing application sandboxes; and/or (2) add middleware MAC to remedy the shortcomings of permissions. The kernel MAC implementations reuse or extend previous Linux MAC frameworks such as SELinux and TOMOYO Linux. The middleware MAC implementations are usually tailored to the problems they attempt to address. In particular, FlaskDroid [4] is the first security extension that attempts to address diverse security requirements with a generic security framework. However, generic MAC implementations come with a cost of relatively large code base and difficulties in maintainability. For example, FlaskDroid includes 12 Userspace Object Managers (USOM). Each USOM must be re-evaluated and patched once new Android versions are released. And it remains a question whether the 12 USOMs can completely cover all the attack vectors. Android Security Framework (ASF) [1] attempts to address the limitations of FlaskDroid with loadable security modules and a comprehensive set of security APIs. Despite that the loadable modules could reduce the work required to instantiate different security models, the security APIs themselves that are scattered in various Android system services still suffer from deployment and maintenance issues.

2.2.2. MAC implemented in applications

To address the deployment issues of system-centric MAC implementations, application-centric approaches [16,33,40,43,47] have been proposed. These security frameworks, which are also known as inlined reference monitors, rewrite applications by instrumenting applications’ byte code or native code and thus do not require any changes to the underlying Android system. Despite their significant improvement in deployment, a recent study [29] shows that application-centric MAC implementations are subtle and they could be bypassed or subverted, because the instrumented code runs within the same process as that of the confined application. Apparently, an application is able to modify itself to remove or suppress the instrumented code.

4.3.1. ICCMon

We propose ICCMon to handle ICC requests that are between applications. We choose ActivityManagerService as the choke point for ICCMon because ActivityManagerService is the single system service responsible for establishing and shutting down ICC channels.

OPEN IN VIEWER

Fig. 3.

ICCMon workflow.

Figure 3 depicts the workflow of ICCMon. Specifically, ICCMon labels application components with the UIDs of their corresponding application processes, and labels intents with their meta-information including action, category, and data URI. To ensure complete mediation, we analyze the call graph of ActivityManagerService and identify 4 functions that can capture all ICC requests, including startActivityLocked(), startServiceLocked(), getContentProvider() and deliverToRegisteredBroadcastReceiversLocked(). From the names of these functions we can notice that they handle ICC channels to activities, services, broadcast receivers, and content providers, respectively. These hooks placed just before ActivityManagerService is about to establish an ICC channel, which is similar to how hooks are placed in Linux Security Modules. Using these hooks, ICCMon enforces security decisions acquired from the decision manager. ICCMon returns control to ActivityManagerService if an ICC request is accepted. Otherwise, ICCMon generates a security exception for the caller application to shut down the ICC channel.

Android APIs are implemented based on Binder IPC. The mappings between Android APIs and Binder IPC transactions are specified in the AIDL1

To identify choke points of Binder IPC, we analyze the entire Binder IPC subsystem and we choose to place the enforcement hooks in LibBinder (/system/lib/libbinder.so), because it is the dynamic library linked to all the system services. As long as LibBinder and the system services are not compromised, BinderMon can intercept all the Binder IPC requests sent to the system services.

BinderMon mediates Binder IPC before the permission framework is consulted. Therefore, it enables dynamic permission revocation without affecting the existing permission framework. Furthermore, BinderMon offers finer granularities at the API level, whereas the granularity of the Android permission framework is a set of permissions where each permission maps to multiple APIs. Moreover, BinderMon protects 1,448 public and private Android APIs implemented by more than 70 system services, while FlaskDroid only protects 136 APIs in 12 system services.

OPEN IN VIEWER

Fig. 4.

BinderMon workflow.

A detailed workflow of BinderMon is shown in Fig. 4. To make an API call, an application sends an Binder IPC request using the proxy of the API’s corresponding remote system service (Step 1). Alternatively, this application can send a request without involving the proxy (Step 1′). BinderMon intercepts both types of requests and queries the decision manager with the caller application’s UID, the callee service’s name, and the command code which indicates the API to be called. If the request is allowed, BinderMon returns control to LibBinder. Otherwise, BinderMon shuts down the IPC channel and returns an error code PERMISSION_DENIED to the caller application.

The default Android application sandbox is flawed. Although Android applications are expected to use Android APIs to access system resources, they still possess capabilities to bypass APIs and access sensitive Linux IPC channels that general Android applications should not necessarily use. However, ICCMon and BinderMon cannot revoke all of these unnecessary capabilities. Therefore, we propose a kernelspace reference monitor, OSMon, to mediate Linux IPC channels and enforce the principle of least privilege for Android applications.

Figure 5 depicts the workflow of OSMon. Similar to SELinux [45] and TOMOYO Linux [30], we identify choke points as the hooks defined by Linux Security Module (LSM) [46]. However, OSMon only use the hooks are specific to the Linux IPC mechanisms. Table 1 shows the implemented 23 hooks which cover objects like inodes, file systems, tasks, local sockets, Unix-domain sockets, and Netlink sockets. These hooks can be enabled or disabled individually in the kernel configuration file. In addition, OSMon plays as the trusted computing base (TCB) of the entire TripleMon framework. It protects all the userspace components of TripleMon, including ICCMon, BinderMon, the decision manager, and the policy database. Moreover, OSMon protects itself against root exploits by depriving untrusted applications’ capabilities to access IPC channels that may subvert OSMon.

OPEN IN VIEWER

Fig. 5.

OSMon workflow.

ICC policies regulate the intent-based IPC between applications. Thus, application group, application, and component comprise the subject and resource of an ICC policy. Actions correspond to the APIs that initiate ICC to four types of components, namely activities, services, broadcast receivers and content providers. Condition is defined as the attributes used in intents. Table 2 illustrates the elements of ICC policy.

For example, an adversary who does not possess the INTERNET permission may still access the Internet by sending an intent with action ACTION_VIEW and the URL to the Browser application. We can mitigate such a privilege escalation attack by specifying and enforcing an ICC policy to prevent the adversary from sending such an intent to the Browser application.

4.4.2. Binder policy

Binder policies specify the behaviors of Binder IPC channels between applications and system services. Thus, application group and application comprise the subject, and system service comprises the resource. Action has only one instance, call. And condition specifies the command code of the command to be executed by the remote services, as shown in Table 2.

For instance, as we discussed previously, the permission READ_PHONE_STATE allows an application to access resources such as the unique device IDs and the phone’s state. We can set a Binder policy to revoke an application’s privilege of accessing the device IDs but keep an access privilege to the phone’s state without reinstalling the application. Compared with the default permission framework which treats the capabilities for a permission as an indivisible block, our approach enables a more fine-grained and revocable access control.

4.4.3. OS policy

OS policies mediate Linux IPC channels. In an OS policy, as illustrated in Table 2, subject consists of application group, application, system and file. Resource consists of file, filesystem, process and Linux IPC channel. Action has four types: inode, filesystem, task, and Linux IPC. These actions correspond to different categories of operations on Linux IPC channels. Condition specifies the name of the exact operation and optional parameters.

As we mentioned earlier, GingerBreak is a root exploit that attacks a system service called Vold by sending forged and malformed Netlink messages. Such an exploit can be easily prevented by defining an OS policy that disables applications from sending Netlink messages. Indeed, Android applications are currently not strictly prohibited from using some operating system features. Malicious applications may take advantage of these features to launch attacks. Thus, we need to define corresponding OS policies to prevent applications from abusing these features.

4.5.1. Communication with reference monitors

As the only policy decision point in TripleMon, the decision manager runs in a dedicated process and communicates with the reference monitors via a local socket interface. The communication follows the policy scheme we defined in Section 4.4. Indeed, this interface needs special attention because it can subvert TripleMon or cause denial of service if exploited. To protect this interface, OSMon enforces a set of top-priority policy rules to only allow the decision manager to write into the interface.

4.5.2. Policy management

The decision manager parses a JSON-like plaintext policy file that follows the policy scheme defined in Section 4.4. The policy file is stored in an internal read-only filesystem. In addition, OSMon enforces rules to disallow access on the policy database from any process except the decision manager.

The decision manager maintains two tracks of security policies, namely slow track and fast track. The slow track is enforced by OSMon only. This track defines the common and least privileges of general installed applications. The fast track is enforced by ICCMon and BinderMon. This track expects more frequent policy updates because ICCMon and BinderMon are required to meet per-application security requirements. Specifically, ICCMon or BinderMon always consults the decision manager to acquire decisions generated based on the latest fast track policy. On the contrary, OSMon caches a copy of the slow track policy in the kernel and makes decisions by itself. It only consults the decision manager to get the latest slow track policy when it initializes itself.

4.5.3. Decision reconciliation

Decision reconciliation is necessary to resolve conflicts when multiple reference monitors are involved to mediate accesses on the same resource. For example, an adversary attempts to access the camera via ICC and Binder IPC, expecting that there would be a capability leak somewhere. Suppose a strategy, deny-overrides, is applied. The decision manager ensures that ICCMon and BinderMon both deny the requests to access the camera if there is any applicable ICC or Binder policy that evaluates to deny. More flexible strategies [34], such as first-applicable and strong-consensus, can be adopted to resolve the decision inconsistencies.

5.3.1. ICCMon vs information stealing malware

To test ICCMon, we selected a malware strain called Gone60 (short for “gone in sixty seconds”). Gone6 accesses the Contact applications via ICC channels and uploads user’s contacts to remote servers. In our experiments, we put the malware samples into an application group designated for testing suspicious applications. Then, we applied the following ICC policies to revoke this application group’s capabilities to access user’s contacts. The experiments on 9 Gone60 samples demonstrated that TripleMon successfully denied the accesses on the contacts.

5.3.2. BinderMon vs coarse-grained permissions

Next, we validated BinderMon by partially revoking the capabilities covered by a permission called READ_PHONE_STATE for privacy purposes. READ_PHONE_STATE is a commonly abused permission because it allows applications to call an API getDeviceID and read the unique device identifier which could facilitate user tracking. However, simply revoking this permission could break applications because this permission also covers APIs other than getDeviceID. To protect user’s privacy, we employed the following Binder policies to revoke an application’s capability to call getDeviceID without affecting the other APIs. In our experiments on 20 randomly selected malware samples that use getDeviceId, BinderMon denied every request to getDeviceID. We further verified the results by inspecting the files and network traces generated by the malware samples. And we discovered that no information related to device ID was leaked.

5.3.3. OSMon vs root exploits

In Table 5, we show a list of known root exploits [50], vulnerabilities, and programs attacked by the exploits. We also show the hooks of TripleMon used to prevent corresponding exploits from gaining root privileges. Denying setuid is a straightforward countermeasure and can prevent all of exploits from escalating their privileges. We also employed alternative hooks to protect the target of exploits. For example, Exploid sends malformed Netlink messages to the kernel via /proc/sys/kernel/hotplug. We can mitigate this exploit by revoking its capabilities to use Netlink, and/or use /proc/sys/kernel. In addition, most exploits attempt to remount system as read-write to retain their root privileges even after the reboot. Thus, the filesystem hooks of TripleMon are helpful to neutralize such attempts.

In our experiments, we tested two exploits, GingerBreak and ZergRush, which have been used by recent malicious applications [11,12]. GingerBreak and ZergRush attack Vold’s Netlink socket and local socket, respectively. We defined the following policies to deprive their capabilities to access Vold.

We tested the exploits using (1) samples of GingerMaster, and (2) the shell of Android Debugging Bridge (ADB). Our experimental results showed that OSMon can successfully intercept and prevent such exploits. Figure 6 depicts that ZergRush failed because OSMon denied its attempt to crash vold.

OPEN IN VIEWER

Fig. 6.

ZergRush fails to exploit Vold.

We further examined a list of known root exploits.2

Next we evaluated how the decision managers helped coordinate the reference monitors. An Android application may read/write the SMS storage with a two-step method: acquiring a handle to the SMS database via ICC, and then accessing the database file.

We defined a policy set to mediate applications’ accesses on SMS. The policy rules in the same policy set protect the same resource (SMS) that corresponds to the objects at multiple layers. As each access involves multiple steps, we define a policy for each step. The decisions made by two policies were aggregated, and the final decision was then made by leveraging the deny-overrides strategy. Our experimental results showed that the access was finally denied because the second policy evaluated to deny which overrode the first policy.