1. Defending Binder Attack Surfaces in Android
Article by Huan Feng and Kang G. Shin
Presentation by Kartik Patel

2. Motivation of this seminar
Android dominates the percentage of the global market
Share is more than 82%
Over 1.4 billion android devices and 1.6 million mobile apps available in google play store
Application are not always safe
Not all developers are trustworthy
There are inexperienced developers
Careless developers
Malicious developers
This paper identifies different ways that binder surface is attacked in android smartphones
Solutions to help prevent Binder attack surfaces
Android applications are not always safe, This can be due to:
This calls for applications to be sandboxed. (When applications are sandboxed there needs to be a way of communication between other application)
However, during the past year, there have been multiple CVE (Common Vulnerabilities and Exposures) reports discussing attacks exploiting the Binder interface

3. Background: What is Binder?
Communication between applications
Uses a message based communication between 2 processes
Kernel driver which achieves communication
ioctl syscall commands required to talk with the kernel driver
Cornerstone of the Inter-Processing Communication (IPC) mechanism
Extends further than just the IPC
Provides more secure and robust components in Android
Separates client and server
Now this is what binder does, binder is used to ”Perform communication between other application”
so this is a message based communication between 2 processes
The communication channel consists of:
For communication to get across the boundaries it is performed by the kernel driver.
In-order to communicate with the Kernel driver, there is a specific command, which is, ioctl syscall
Last thing to the communication channel is it uses, upper-level abstracts which utilize the Binder library
Binder is a extensible IPC mechanism
IPC is the inter process communication
The client and server will be covered in bit more detail on the next slide

4. Background: Binder [Cont.]
Binder uses a client server architecture
Allows the user to perform RPC
Android Interface Description Language (AIDL)
Define RPC interface for both client and server
Client trying to access some service
Decompose their objects into primitives
OS can understand
Marshall objects across the boundary
Because android is based off linux, and linux used RPC, Binder uses RPC
Client can send a transaction to the remote server via the Binder framework and then retrieves its response.
Remote procedure calls allows the user to request information from somewhere else and feel as they are on a local network gaining access to information
RPC is one of the most common IPC used
The clients parameters which he is requesting is are marshalled into a Parcel object which is a serilizable container.
The parcel then sent through the Binder to the server where it get de-serilized, processes the parameters and sends its response.
Many Remote procedure calls use IDL(interface defined language) which restricts the formats of a remote invocation and so does android.
On Android it uses a,
Android Interface Description Language
This is something which the client and service agree upon in order to communicate with each other using inter-process communication (IPC).
This is shown in the diagram where the client (WifiManager) make a remote procedure call, communicated with the ALDI, at this point the objects will be decomposed down to primitives which the operating system understands which will then be marshaled across the boundaries.
The code to do that marshalling is tedious to write, so Android handles it for you with AIDL. (Shown by the diagram with the code)
ensure that the declared list of parameter ill be properly de-serialized, sent, received and de-serialized.

5. Vulnerabilities: Attack Surface
There were 100+ vulnerabilities found
Android Versions 4.1, 4.2, 4.4, 5.0, 5.1 and 6.0
RPC
Fatal exception
Crashing part
Crashing entire run time
Uncaught exceptions
Direct cause of crash
Extensive checks around client side
Careless checks around server side
These 100+ vulnerabilities were found in the 6 android version and trying to summaries the mistakes made by the developers which turned the binder interface into a tempting attack surface.
Android versions which were attacked were form version 4.1 to 6
RPC used in client and server methods was found to be vulnerable if testing and resulted in fatal exceptions, crashing part or the entire Android run time crashed. This would generate a report which would then be used for:
A typical attack can be uncaught exceptions by developers, this can be NullPointerExceptions which is missed, potential to cause damage.
When there is uncaught exception and crashed, source code needs to be inspected at this point to find the root of the cause.
Sanity checks are most extensive around client-side public APIs, but are sporadic/careless after this line.
This is shown by a figure on the right that is common in binder to inject faulty transactions via the Binder driver, an attacker can bypass the sanity check on public API, and directly challenge the server-side.

6. Further Challenges Non – Primitive data-types
Affected 48% RPC
Difficult to perform fuzzing
Dynamic makes it harder to generate schemas
Interdependence input parameters
37% require input parameters from the output of the previous
Availability / Un-availability of source code
Non-Primitive data types are complicated and affected 48% of RPC making it difficult to Fuzz with the parameter types
The list of parameters in the transaction also are dynamic making it difficult for the schema for binder based transactions
This prevents the visibility of source code when needing to under test

7. Solutions / IDEAS BinderCracker Root cause analysis (RPC)
Record transactions
Matches input and output
Does not require source code
Replay transaction
Root cause analysis (RPC)
Precautionary Testing
Before ROM release, during or end
Uses static code analysis tool (lint)
Automatically scans for violations
Allows meta data tags
Variables
Parameter
Return variables
Binder cracker solves the further challenges identified on the previous slide.
BinderCracker identified 89 vulnerabilities which are detected in Android 5.1 and Android 6.0 which is 7 times more vulnerabilities than black box fuzzing.
Recording method, collects a set of detailed information of different binder transactions then records component to builds and record the schema of each transaction during runtime
works recursively with the (de)-serialization functions, and therefore can understand and record complicated, hierarchical schemas and solves the issue with non-primitive data types
Automatically matches input and outputs of adjacent transactions is which then performs a dependency graphs which can be used to reconstruct each transaction if required
Replays all the transactions it depends on and generate the correct context
Root cause analysis is another solution method to RPC issue, this is where you will:
Identify it on the official ROM
Manually confirm that it can be reproduced
Inspect the source code for the root cause
Precautionary testing is liked to be performed before releasing buggy codes to the end users. This defense can be done early, in the development phase, or later, after the entire ROM gets built.
The static tool lint check for potential bugs and optimizations for correctness, security, performance, usability, accessibility and internationalization, Automatically scans the code and prompts for violations. This also allows for much of the bugs to be eliminated during the development phase.
Meta Data, For example, the developers can mark an input parameter indicating that it cannot be Null, or marking it

8. Solution / ideas Runtime Diagnostics Tool
Sender of the transaction will be recorded
Detailed information of failed transaction will be included in the report
Signature of transaction will be generated
service fails when processing an incoming transaction, the sender of the transaction will be recorded and the user will be warned with a visual prompt
detailed information of the failed transaction, including the content, schema and parsing status will be dumped into a report for future forensics
Signature of the transaction will be generated and the user can review it and choose to block future occurrences of the same transaction

9. Issues Cannot identify who causes the crash or why
Vulnerabilities which remain unfixed
From the 137 vulnerabilities identified, only 115 were analyzed.
Only 18 were fixed
12 vulnerabilities disappeared
22 didn't have access to source codes
And 85 remain unfixed
Issues still exist currently remain unfixed in android smartphones even with binderCraker, and potentially are been zeroed out when found.
corresponding source codes (or API) have been deleted; or 2) new updates in other parts of the source codes accidentally bypass the vulnerable source codes

10. Summary What is Binder in Android
Developers overlook security system services
Attacks performed on the Binder surface
Various solutions which could be used to solve Binder attacks.
Issues which still exist

11. Criticism / Improvements
Article showed a lot of vulnerabilities with very little solution that solved them.
Implementation of lint to RPC should be used
Many vulnerabilities discovered by BinderCracker still remain unfixed.
Developers should be more careful, not just on the client side, but also consider the server side
Cannot identify who caused the crash or why
Only inspected root of the cause in RPC if it could be reconstructed
Should still be inspected even if the crash cannot be reconstructed

12. Questions?