PatchDroid: Scalable Third-Party Security Patches for Android DevicesCollin Mulliner1; Jon Oberheide2; William Robertson1; Engin Kirda1

1Northeastern University2DuoSecurity

29th Annual Computer Security Applications Conference (ACSAC 2013)

左昌國2013/10/29 Seminar @ ADLab, CSIE, NCU

Outline• Introduction• Design Overview• Anatomy of a Patch• Implementation• Evaluation• Discussion and Conclusions

2

Introduction

3

Scope of this paper

Introduction• Android provides an over-the-air (OTA) update

mechanism over the network• Long-term: Only devices sold by Google• Most manufacturers only support products for 1-2 years

• In May 2013, 38% of all Android devices were running Android 2.3 (Gingerbread)• In Oct: 28.5% as Gingerbread

4

Introduction• Vulnerability uncertainty

• Manufacturer’s version of Android release might still be vulnerable even if Google has officially released security patches to the same version

• Two devices running non-Google versions of Android 2.3.6 and 3.2 are both vulnerable to the GingerBreak bug• Google officially patched it in Android 2.3.4 and 3.0.1

5

Introduction• What do we need?

• A system for applying 3rd-party security patches to unsupported Android devices

• This system should be reliable• In-memory patching

• Scalability• Supporting both native code and dalvik code• Fast deployment

• OTA• Do not rely on manufacturers to provide source code• AOSP: http://source.android.com/

• Attack detection on patched devices

6

Design Overview

7

Design Overview: Components• Patch Injector:

• Deploying patches into running processes• Verifying the patch requirements

• Patch Monitor:• Monitoring the execution of a patch for stability• Collecting log messages

• Process Creation Monitor:• Interposing on process creation to determine a patch necessity• init: system services• zygote: dalvik-based processes

8

Design Overview: Components• Attack Detector:

• Analyzing the warning messages from Patch Monitor, and processing the messages for reporting

• Patch Updater:• Checking for new patches with the cloud service• Downloading new patches over a secure channel, and verifying the

file integrity

• Reporter:• Collecting information of attack attempts and patch stability• Transmitting to the cloud service

9

Design Overview: Components• Alerter:

• A separate process• GUI, alerting to the user on detecting an attack attempt

• Cloud Components:• Patch Repository• Log Collector

10

Anatomy of a Patch: Native Code• Replacing vulnerable functions with equivalent functions

that do not contain the vulnerability• Inline hooking• Global offset table (GOT) hooking• The patch method is based on shared library injection

• Patching scenarios• Function Replacement

11

Anatomy of a Patch: Native Code• Patching scenarios (cont.)

• Fixing via Function Proxy• For complex functions• Enforcing a form of input sanitization to the vulnerable function

12

Anatomy of a Patch: Native Code• Patching scenarios (cont.)

• Failed Return Value Checking• Avoiding the complexity of replacing large, complicated functions

13

Anatomy of a Patch: Dalvik Bytecode• Using JNI to replace arbitrary methods in Dalvik code with

a native function call• Inline hooking (one time) a common function call (such as epoll_wait())

• In the above hooking, • Resolving symbols from Dalvik VM Library (libdvm)

• Obtaining a class reference through dvmFindLoadedClass• Obtaining a method reference via dvmFindVirtualMethodHierByDescriptor

• Replacing (hooking) the method with a native method via dvmJNIBridge

• Loading other classes

14

Anatomy of a Patch: Dalvik Bytecode

15

Implementation• patchd: the patch daemon

• Launched at startup• Running continuously in the background• Main tasks:

• Monitoring process creation• Performing patching• Monitoring the stability• Logging

• On startup, collecting information, loading the meta data for all available patches

• Patch injection into already-running processes• Runtime patch deployment system

16

Implementation: Patching Processes• Process Creation Monitor

• Tracing the init and zygote processes• init: for crashed system services, ex: zygote or vold• zygote: for Dalvik-based processes

• ptrace API: TRACE_FORK and TRACE_EXEC (fork, clone, exec)• Base executable or Dalvik class name

• Inspecting /proc/$PID/cmdline• Used to match the patch

17

Implementation: Patching Processes• Patch Deployment

18

patchd

proc A

(1) trace

mem

(2) create shared memory

patch

(3) inject

(4) map

vuln

(5) hook(6) call fixed

(7) report

Implementation: Patching Processes• Patch injection

• Using ptrace API• patchd writes a loader stub to the stack• Executing the stub

• Invoking mprotect to mark the stack as executable• Invoking dlopen to load the patch shared library

• Transferring the execution to the injected library by calling the library’s init function

19

Implementation: Patching Processes• Process blocked by syscall

• Can not inject during syscallstimulating the process to return from syscall

• For zygote, forcing a creation of a new DVM instance

• Patching newly started processes• Can not inject before dynamic linker has loaded the executable and

some librariesusing a set of heuristics to determine the injecting time

• For zygote, the timing is it changed name to zygote from app_process

• For native processes, the timing is that a specific syscall has been executed

20

Implementation: Patching Processes• Handling statically-linked code

• No library injection• Using TRACE_SYSCALL tracing to monitor the exploitation attempt

• If an attempt is detected, kill the process• Virtually no processes are statically-linked• To date, only one vulnerability

21

Implementation: Patch Monitoring and Attack Detection• Reliability

• Entry and exit counters• If enter counter > exit counter a crash happened

• Storing the failure code• Ex: a missing symbol patch incompatible forwarded to reporting

system

• Attack Detection• A trigger condition in each patch• Using the shared memory IPC to report to patchd

22

Implementation: The PatchDroid App• The PatchDroid App

• Installing patchd and patch libraries• HelperService

• To wake up zygote by forcing HelperService to start• Terminating immediately

• Attack Notification UI• Log file uploader

23

Implementation: Patches

24

Evaluation• Functional Evaluation

• Test devices• HTC Wildfire S (2.3.3)

• GingerBreak, ZergRush• Motorola FlipOut (2.1)

• GingerBreak, ZergRush, Zimperlich• HTC One V (4.0.1)

• Dalvik-based SMS spoofing (https://github.com/thomascannon/android-sms-spoof)

• Methodology1. Run exploit w/o PatchDroid2. Install PatchDroid3. Run exploit w/ PatchDroid

• Prevent exploitation• Determine vulnerable or not

25

Evaluation: Performance Overhead

26

Evaluation: User Trials

27

Evaluation• Master Key Bug

• ReKey https://play.google.com/store/apps/details?id=io.rekey.rekey

28

Discussion and Conclusions• Discussion

• Root

• Conclusions• Almost 40% of android devices run software that is more than 24

months old• Most of these devices contain privilege escalation vulnerabilities• PatchDroid, a system to patch security vulnerabilities on legacy

Android devices• Dynamic instrumentation techniques in memory• Can be deployed on every devices• Does not need to flash of modify system partitions or binaries• Effectively• Does not produce noticeable performance overhead

29