PatchDroid : Scalable Third-Party Security Patches for Android Devices

1. 29thAnnual Computer Security Applications Conference (ACSAC 2013) PatchDroid: Scalable Third-Party Security Patches for Android Devices Collin Mulliner1; Jon Oberheide2; William Robertson1; EnginKirda1 1Northeastern University 2DuoSecurity 左昌國 2013/10/29 Seminar @ ADLab, CSIE, NCU

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

3. Introduction Scope of this paper

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

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

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

7. Design Overview

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

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

10. Design Overview: Components • Alerter: • A separate process • GUI, alerting to the user on detecting an attack attempt • Cloud Components: • Patch Repository • Log Collector

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

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

13. Anatomy of a Patch: Native Code • Patching scenarios (cont.) • Failed Return Value Checking • Avoiding the complexity of replacing large, complicated functions

14. Anatomy of a Patch: DalvikBytecode • 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

15. Anatomy of a Patch: DalvikBytecode

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

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

18. Implementation: Patching Processes • Patch Deployment (2) create shared memory patchd mem (3) inject (1) trace (4) map proc A patch (7) report (5) hook (6) call fixed vuln

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

20. Implementation: Patching Processes • Process blocked by syscall • Can not inject during syscall stimulating 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 libraries using 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 syscallhas beenexecuted

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

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

23. Implementation: The PatchDroid App • The PatchDroid App • Installing patchd and patch libraries • HelperService • To wake up zygote by forcing HelperServiceto start • Terminating immediately • Attack Notification UI • Log file uploader

24. Implementation: Patches

25. 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) • Methodology • Run exploit w/o PatchDroid • Install PatchDroid • Run exploit w/ PatchDroid • Prevent exploitation • Determine vulnerable or not

26. Evaluation: Performance Overhead

27. Evaluation: User Trials

28. Evaluation • Master Key Bug • ReKeyhttps://play.google.com/store/apps/details?id=io.rekey.rekey

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