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

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

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

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.

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.

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

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 as @NonNull, indicating that it cannot be Null, or marking it as @IntRange(from=0,to=255)

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

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

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

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

Questions?