Understanding and Defending Binder Attack Surface in Android By Wen-Kai Chen

Motivation Android as the most popular smartphone OS Developers not trust worthy Inter-process communication (IPC) Different attack methods (DoS, Information Leakage, Crash System…etc.) Where are the security boundaries in Android? What are the vulnerabilities in Android? Solutions? Prevent attack? Diagnose Attack?

Background: Communication [Part 1] Client side Server side IPC (Inter Process Communication) Binder Specific IPC Communication between 2 processes ioctl with Binder Library syscall with kernel level driver Transaction marshalled into parcel object Client/Server architecture

Background: Communication [Part 2] AIDL (Android Interface Definition Language) Relieves tasks on developer Hide details on binder and RPC (Remote Procedural Call) Stubs and Proxy created Remote Procedural Call (RPC) Initiated by client Sends message to remote server Message contains parameter including data types – packed by stubs (aka marshalling) Within Binder Transaction [1] https://developer.android.com/reference/android/os/Binder.html

Problems Analyzed 115 Android Source Codes Sanity check client-side public API RPC parameters unchecked and deserialization process unprotected. Fuzzing - Binder transaction with non-primitive data types Uncaught exception & Erroneous Input (Crash + Reboot) Null parameters also causes crash Manipulate RPC parameters Inputs an important factor of security Injection on client-side

Ideas/Solutions for Security [Part 1] Root cause analysis (Suggestion) Server double checks on input parameters Precautionary Testing (Suggestion) Before ROM release Static code analysis tool (aka “lint”). Inspection/Add metadata E.g @NonNull “lint” on RPC input Introduction of BinderCracker software (Implmented) Testing Binder-Based RPC Used before each product release Identify vulnerabilities report to AOSP (Android Open Source Project) Manage dependencies across transactions Recording component Fuzzing component

Ideas/Solutions for Security [Part 2] BinderCracker Matching input/output of adjacent transaction, construction of dependency graph Record seed transactions and dependencies, then fuzz system service Monitor input/output Replay transaction before fuzzing Runtime Diagnostic Tool Maintains sender, schema, content, passing information for each transaction in case of failure. Provide detailed report of transaction. Warn user with visual prompt Diagnose instead of preventing problems

What’s Wrong? [Part 1] BinderCracker Only identifies vulnerabilities in Binder based RPC Insufficient solutions Effectiveness of reporting to AOSP Actual solution? 18 Fixes out of 137 Vulnerabilities found

What’s Wrong? [Part 2] Data types within RPC Hard to sanitize Root cause analysis, precautionary analysis and runtime diagnostic tool as suggestion Clear boundaries/rules not identified Not being able to identify who causes the crash and why it crashed DoS Attack is not fixed by BinderCracker

Improvements Implementation of ”lint” to RPC should be carried out and used with BinderCracker Collaborate diagnostic tool with BinderCracker Report + Vulnerabilities BinderCracker itself does not fix the problem identified, rather it only act as vulnerability identifier.

My Opinion Article is mainly about identifying vulnerabilities Developer should be careful with IPC Sanity check is important in both client and server side Not only attack in Binder, other attacks on cryptography is important too.

Thanks for listening