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

2. 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?

3. 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

4. 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]

5. 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

6. 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

7. 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

8. 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

9. 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

10. 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.

11. 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.

12. Thanks for listening