Binder Attack Surface in Android Compsci 702 – Mobile Security Article by Huan Feng and Kang G. Shin 3/May/2017 Seung Ho Lee

Motivation Android dominates the global market. Share of more than 82% Over 1.4 billion android devices and 1.6 million mobile apps in Google Play in 2015 The applications are not always safe. Inexperienced Careless Malicious Multiple reports on Common Vulnerabilities and Exposures(CVE). Exploiting the Binder interface Isolation between apps and the system. Improves: Robustness Security

Background Android communication mechanism for system services. Inter-Process Communication (IPC) mechanism Binder as cornerstone Binder. Client-server architecture An attack gateway (entry point) 137 vulnerabilities were identified and 115 of them were analysed. Less security checks after client side API call Misconception on the security boundary in Android system service.

Research Question System developers overlook the security principles of client-server, why does this happen and what can be done to improve this problem?

Problems Root Cause Analysis Binder Driver Binder Interface System Services X-Manager X-Manager.Stub.Proxy AIDL Attacker1 Attacker2 Severe sanity checks Sporadic sanity checks RPC(Input parameters) Serialized Bytes Write to Parcel Injecting faulty transaction Calling public APIs Root Cause Analysis Hidden (private) RPC methods are never exposed to public APIs. Bypassing sanity checks around the public APIs. Malicious inputs are de-serialized in the server side.

Solutions Precautionary Testing Framework. BinderCracker. Runtime Diagnostics and Defences. System layer diagnostic tool.

BinderCracker Context-aware fuzzing framework Recording component -> collects detailed information of transactions, e.g., parameter types, structure and dependencies. Fuzzing component -> replays and manipulates the schema that is gathered from the recording component. Taget.handle – the serivce, obtained by replaying. Code – RPC method to fuzz Data – serialized bytes of the list of parameters Face Recognition Camera Explicit Input: A picture with face Implicit Input: Camera (byte)

OS level runtime diagnostic support Can be implemented by using the recording component in BinderCracker. The sender of a transaction => Binder.getCallingUid() The package name of the sender => querying PackageManagerService with the id If an incoming transaction fails: Records the sender’s detail Content, schema and parsing status are dumped into a report The user can review it and block the same transaction in the future Warns the user with visual prompt

Results BinderCracker OS level runtime diagnostic support 89 vulnerabilities are detected in Android 5.1 and Android 6.0 that is 7x more vulnerabilities than a simple black-box fuzzing approach OS level runtime diagnostic support User receives a visual prompt when a transaction fails and can block the same transaction in future.

Summary System developers overlooked the security of system services Security principle is disobeyed Attacks on Binder interface Precautionary testing framework & Runtime diagnosis Better performance on the vulnerability discovery & protection

Issues BinderCracker Runtime Diagnostic Support The effectiveness depends on the coverage and quality of the transactions Doesn’t solve the problem Runtime Diagnostic Support Still fails at the first time

System transaction storage Improvements System call Runtime Simulator/VM System transaction storage First time BinderCracker Unsafe, notify the user Safe to be called Proven to be safe from previous transactions System Service UI Unsafe, notify the user