Analyzing Input Validation vulnerabilities in Android System Services NAMJUN PARK (NPAR350)

Background  Input validation: “Correct testing of any input supplied by something else” Input by user Input by application on the environment  Applied in web applications Prevention of SQL injection Bounds checking for buffer overflow  Existing work on input validation don’t apply for Android system services.

What is an Android System Service?  Services provided by the Android system which encapsulate system functionalities Bluetooth Telephone GPS WiFi  Main differentiator between PC and Android system

Sending requests to a system service  Apps use API calls to send requests to system services  Best way (API) to send request – transact(…) 4 arguments  Malformed inputs -> systems service crash System service methods need to be protected from bad inputs

Problems to address 1.To which extent system service code misses input validation 2.How to develop a cost effective solution

Solving problem 1  Manual inspection of system service code 1972 methods across 96 system services 70% - Perform I.V, 23% - No arguments, 7%- No I.V  Conditions for methods that perform I.V Verify at least one argument Requires that the app satisfies a certain condition

Solving problem 2  Created Buzzer (Binder Fuzzer) Sends malformed requests to Android system services Crash target system service and expose vulnerabilities  Assumptions Acts as an ordinary third party app Can request all permissions that other ordinary third-party apps can Target system version 5.0.1

Buzzer breakdown  Service Module Arguments generator Request data wrapper  Service Chooser  Request Sender/Logger  Log Analyzer Semi-automatic

Buzzer design challenges  Arguments generating Java.util.Random used for primitive, String types Generate random field values for simple classes Replace Android SDK’s library to access hidden classes NULL for complex classes  Too many interface methods (1972 methods!) Methods that require permissions which are not acquirable (703) Methods which return null or have empty function bodies, omitted (8)

#1: Vulnerabilities caused by the generated code  AIDL (Android Interface Definition Language) Allows a programming interface to be agreed upon between application and system service. Necessary for interfaces to be passed onto arguments of the system service method.  Always returns the target interface as long as object is not null

#1: Vulnerability caused by the generate code (2)  Malicious app can forge an interface using a fake object that is not null.  Target system will invoke the forged interface which is actually a different interface on the inside.  SecurityException will be thrown.

#2: Vulnerability in Servicemanager  What is a Servicemanager? All system services must be registered with Servicemanager. Apps must communicate with Servicemanger before sending requests.  Flag value 0 = return reply to app 1 = exit and restart  Servicemanager restart => related processes restart => apps exit/restart. Eg. Zygote, keystore (slightly different scenario)

#3: Vulnerability in the WiFi System Service  Int argument that sets which frequency band to use. 0 = Automatic 1 = 5 GHz 2 = 2.4 GHz  If index > 2 then StringIndexOutOfBoundsException thrown.  WiFi disconnects from access point Attempts to reconnect through settings will cause the settings app to crash

#4: Vulnerability in Search System Service  Search system service Responsible for the search UI Maintains a registry of ‘searchable activities’  launchAssistAction() Method of search system service Starts activities that accept ACTION_ASSIST  Spam launchAssistAction() => UI freeze

#5: Vulnerabilities caused by NULL reference  There are methods which do not check for NULL arguments Eg. registerClient in the system service media.audio_policy  System service crash => related process crash => related system services unavailable Eg. Cannot: watch video, listen to music, use the camera. media.audio_policy mediaserver media.audio_flinger media.player media.camera

Impact of this research  After evaluating 1972 methods across 96 system services 16 vulnerabilities identified.  Findings sent to Google Issues have been accepted, being tracked and investigated.

Criticism  Manual inspection of code to determine methods doing input validation  Buzzers logging is semi-automatic Requests which are constantly sent are logged Messages between between buzzer and target service checked manually  Buzzer is NOT cross-version Relies heavily on native libraries No “Write once, run everywhere” Need NDK set differently for different ABI’s

Thank you