Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
SlideShare a Scribd company logo

KARMA: Adaptive Android Kernel Live Patching

•
•
Yue Chen
Yue Chen

This document describes KARMA, a system for adaptive Android kernel live patching. KARMA can automatically adapt patches to different device kernels by using semantic matching. It confines patches using Lua virtual machine to ensure they are memory-safe. KARMA can apply patches at different levels, from function entry/exit points to specific call sites. The evaluation shows KARMA can patch 76 real vulnerabilities and incurs low performance overhead.

1 of 55
Adaptive Android Kernel Live Patching Yue Chen1, Yulong Zhang2, Zhi Wang1, Liangzhao Xia2, Chenfu Bao2, Tao Wei2 Florida State University1 Baidu X-Lab2 USENIX Security Symposium 2017
Android Kernel Vulnerabilities 2 Apps Java API Framework Native C/C++ Libraries Linux Kernel Android Runtime Hardware Abstraction Layer TrustZone
Android Kernel Vulnerabilities 2 Apps Java API Framework Native C/C++ Libraries Linux Kernel Android Runtime Hardware Abstraction Layer TrustZone
Android Kernel Vulnerabilities 2 Apps Java API Framework Native C/C++ Libraries Linux Kernel Android Runtime Hardware Abstraction Layer TrustZone
Number of Disclosed Android Kernel Vulnerabilities 3
Problem: Old Exploits Remain Effective Number of devices vulnerable to two root exploits as of Nov. 2016 4 • Android 5.0 released in November 2014 • 46.3% of devices run an older version in September 2016
Challenges • Officially patching an Android device is a long process  Third-party • Delayed/non-existing kernel source code  Binary-based 5
Challenges • Severely fragmented Android ecosystem  Adaptive 6 http://d.ibtimes.co.uk/en/full/1395443/android-fragmentation-2014.png
Solution Third-party Binary-based Adaptive Kernel Live Patching 7 Key requirements: • Adaptiveness – It should be adaptive to various device kernels • Safety – Patches should be easy to audit – Their behaviors must be technically confined • Timeliness – Response time should be short, after disclosed vulnerability or exploit • Performance – The solution should not incur non-trivial performance overhead
Feasibility Study: Dataset • Studied 1139 Android kernels 8
• Most kernel functions are stable across devices and Android releases • Most vulnerabilities triggered by malicious inputs • Many functions return error codes – Return a pointer  ERR_PTR Feasibility Study: Observations 9
• Most kernel functions are stable across devices and Android releases • Most vulnerabilities triggered by malicious inputs • Many functions return error codes – Return a pointer  ERR_PTR Gracefully return Feasibility Study: Observations 9 Filter them
Overall Approach: Input Validation 10
KARMA KARMA: Kernel Adaptive Repair for Many Androids  Adaptive – Automatically adapt to various device kernels  Memory-safe – Protect kernel from malicious (misused) patches  Multi-level – Flexible for different vulnerabilities 11
KARMA Design: Safety • Patches are written in Lua, confined by Lua VM at runtime • A patch can only be placed at designated locations • Patched functions must return error codes or void – Use existing error handling to recover from attacks • A patch can read but not write the kernel memory – Confined by KARMA APIs – Prevent malicious (misused) patches from changing the kernel – Prevent information leakage 12
KARMA Design: Multi-level Patching • A patch can only be placed at designated locations Level 1: Entry or return point of a (vulnerable) function Level 2: Before or after the call site to a callee e.g., copy_from_user Level 3: Binary-based patch • 76 critical Android kernel vulnerabilities Level 1: 49/76 (64.5%) Level 2: 22/76 (28.9%) Level 3: 5/76 (6.6%) 13
KARMA Patch Example Part of the official patch of CVE-2014-3153 (Towelroot) 14
KARMA Patch Example 15 -EINVAL More complex examples in the paper
KARMA API 16
KARMA API Available to patches 16
KARMA Architecture 17 Offline Patch Generation and Verification Online Live Patching by KARMA Client
Offline Patch Adaptation Patch A 18
Offline Patch Adaptation Three steps: 1. Identify the vulnerable functions in the target kernel – Same function but different names – Inlined 2. Check if the reference patch works for the target kernel – Same function but different semantics 3. Adapt the reference patch for the target kernel 19
Vulnerable Function Identification Example CVE-2015-3636 (PingPong Root) Device A: ping_unhash Device B: ping_v4_unhash Func_A Func_B Func_C Func_D Func_E ping_unhash Func_A Func_B Func_C Func_D Func_E ping_v4_unhash 20 Call graph based similarity comparison
Semantic Matching • Check if two functions are semantically equivalent • If so, adapt the reference patch to the target kernel • Syntactic matching is too strict – Different compilers can generate different code with same semantics • Instruction order, register allocation, instruction selection, code layout 21
Semantic Matching Same semantics with different syntax 22
Semantic Matching Same semantics with different syntax 22
Semantic Matching Same semantics with different syntax 22
Semantic Matching Same semantics with different syntax 22
Semantic Matching Same semantics with different syntax 22
Semantic Matching • Check if two functions are semantically equivalent • If so, adapt the reference patch to the target kernel • Syntactic matching is too strict – Different compilers can generate different code with same semantics • Instruction order, register allocation, instruction selection, code layout • Use symbolic execution to abstract these differences and adapt patches – Use approximation to improve scalability (details in the paper) 23
Online Patch Application 24 Function entry point hooking
Prototype Implementation • Lua engine in kernel (11K SLOC) – Simple – Memory-safe – Easy to embed and extend – 24 years of development • Semantic matching – angr 25
Evaluation: Applicability • Evaluated 76 critical vulnerabilities in the last three years • Patch level: – Level-1: 49 – Level-2: 22 – Level-3: 5 26
Evaluation: Adaptability 27
Evaluation: Adaptability Types and frequencies of instruction opcodes 27
Evaluation: Adaptability Number of function calls and conditional branches (to abstract CFG) 27
Evaluation: Adaptability KARMA’s semantic matching 27
Evaluation: Performance CF-Bench results with different patches 28
Evaluation: Performance Execution time of chmod with different patches 29
Future Work • User-space vulnerability protection – Project Treble  only partially solve the problem • Lua engine in the kernel (11K SLOC) – Alternative execution engines, like BPF or sandboxed binary patches • Error handling code could be vulnerable – Error injection to detect vulnerable error-handling code • Improve semantic matching 30
Adaptive Android Kernel Live Patching www.YueChen.me Q & A
Backup Slides
Attack TrustZone from Kernel • Example: – Downgrade Attack on TrustZone (see its references) 34
Observations • Most kernel functions are stable across devices and Android releases. Number of syntax clusters for each function 35 About 40% of the shared functions have only one cluster, and about 80% of them have 4 clusters or less. Cluster Number Kernel Function Number
Observations • Most kernel functions are stable across devices and Android releases. 36 For about 60% of shared functions, the largest cluster contains more than 80% of all the kernels that have this function. Kernel Function Number Percentage of kernels in the largest cluster for each function
Symbolic Execution • Challenges – Avoid path explosion – Impact to the environment • Practical Solution – Non-local memory writes – Function calls (and their arguments) – Function return values • Adaptation (e.g., mutate constants or offsets) – foo(symbol_A + 4, 36) foo(symbol_A + 8, 36) 37
Evaluation: Overall Performance • Complex patch for most frequent syscall (gettimeofday) during web browsing • Overall system performance overhead in this extreme situation: 0.9% 39
Example: CVE-2013-6123 49
Example: CVE-2013-6123 50
Example: CVE-2013-6123 51
Example: CVE-2013-6123 52
Example: CVE-2013-6123 53
Example: CVE-2013-6123 54
You May Also Like • A time machine to locate vulnerabilities: – Pinpointing Vulnerabilities • Protect your computer by encrypting memory all the time: – Secure In-Cache Execution • Fine-grained dynamic ASLR during runtime: – Remix: On-demand Live Randomization 55

More Related Content

KARMA: Adaptive Android Kernel Live Patching

  • 1. Adaptive Android Kernel Live Patching Yue Chen1, Yulong Zhang2, Zhi Wang1, Liangzhao Xia2, Chenfu Bao2, Tao Wei2 Florida State University1 Baidu X-Lab2 USENIX Security Symposium 2017
  • 2. Android Kernel Vulnerabilities 2 Apps Java API Framework Native C/C++ Libraries Linux Kernel Android Runtime Hardware Abstraction Layer TrustZone
  • 3. Android Kernel Vulnerabilities 2 Apps Java API Framework Native C/C++ Libraries Linux Kernel Android Runtime Hardware Abstraction Layer TrustZone
  • 4. Android Kernel Vulnerabilities 2 Apps Java API Framework Native C/C++ Libraries Linux Kernel Android Runtime Hardware Abstraction Layer TrustZone
  • 5. Number of Disclosed Android Kernel Vulnerabilities 3
  • 6. Problem: Old Exploits Remain Effective Number of devices vulnerable to two root exploits as of Nov. 2016 4 • Android 5.0 released in November 2014 • 46.3% of devices run an older version in September 2016
  • 7. Challenges • Officially patching an Android device is a long process  Third-party • Delayed/non-existing kernel source code  Binary-based 5
  • 8. Challenges • Severely fragmented Android ecosystem  Adaptive 6 http://d.ibtimes.co.uk/en/full/1395443/android-fragmentation-2014.png
  • 9. Solution Third-party Binary-based Adaptive Kernel Live Patching 7 Key requirements: • Adaptiveness – It should be adaptive to various device kernels • Safety – Patches should be easy to audit – Their behaviors must be technically confined • Timeliness – Response time should be short, after disclosed vulnerability or exploit • Performance – The solution should not incur non-trivial performance overhead
  • 10. Feasibility Study: Dataset • Studied 1139 Android kernels 8
  • 11. • Most kernel functions are stable across devices and Android releases • Most vulnerabilities triggered by malicious inputs • Many functions return error codes – Return a pointer  ERR_PTR Feasibility Study: Observations 9
  • 12. • Most kernel functions are stable across devices and Android releases • Most vulnerabilities triggered by malicious inputs • Many functions return error codes – Return a pointer  ERR_PTR Gracefully return Feasibility Study: Observations 9 Filter them
  • 13. Overall Approach: Input Validation 10
  • 14. KARMA KARMA: Kernel Adaptive Repair for Many Androids  Adaptive – Automatically adapt to various device kernels  Memory-safe – Protect kernel from malicious (misused) patches  Multi-level – Flexible for different vulnerabilities 11
  • 15. KARMA Design: Safety • Patches are written in Lua, confined by Lua VM at runtime • A patch can only be placed at designated locations • Patched functions must return error codes or void – Use existing error handling to recover from attacks • A patch can read but not write the kernel memory – Confined by KARMA APIs – Prevent malicious (misused) patches from changing the kernel – Prevent information leakage 12
  • 16. KARMA Design: Multi-level Patching • A patch can only be placed at designated locations Level 1: Entry or return point of a (vulnerable) function Level 2: Before or after the call site to a callee e.g., copy_from_user Level 3: Binary-based patch • 76 critical Android kernel vulnerabilities Level 1: 49/76 (64.5%) Level 2: 22/76 (28.9%) Level 3: 5/76 (6.6%) 13
  • 17. KARMA Patch Example Part of the official patch of CVE-2014-3153 (Towelroot) 14
  • 18. KARMA Patch Example 15 -EINVAL More complex examples in the paper
  • 21. KARMA Architecture 17 Offline Patch Generation and Verification Online Live Patching by KARMA Client
  • 23. Offline Patch Adaptation Three steps: 1. Identify the vulnerable functions in the target kernel – Same function but different names – Inlined 2. Check if the reference patch works for the target kernel – Same function but different semantics 3. Adapt the reference patch for the target kernel 19
  • 24. Vulnerable Function Identification Example CVE-2015-3636 (PingPong Root) Device A: ping_unhash Device B: ping_v4_unhash Func_A Func_B Func_C Func_D Func_E ping_unhash Func_A Func_B Func_C Func_D Func_E ping_v4_unhash 20 Call graph based similarity comparison
  • 25. Semantic Matching • Check if two functions are semantically equivalent • If so, adapt the reference patch to the target kernel • Syntactic matching is too strict – Different compilers can generate different code with same semantics • Instruction order, register allocation, instruction selection, code layout 21
  • 26. Semantic Matching Same semantics with different syntax 22
  • 27. Semantic Matching Same semantics with different syntax 22
  • 28. Semantic Matching Same semantics with different syntax 22
  • 29. Semantic Matching Same semantics with different syntax 22
  • 30. Semantic Matching Same semantics with different syntax 22
  • 31. Semantic Matching • Check if two functions are semantically equivalent • If so, adapt the reference patch to the target kernel • Syntactic matching is too strict – Different compilers can generate different code with same semantics • Instruction order, register allocation, instruction selection, code layout • Use symbolic execution to abstract these differences and adapt patches – Use approximation to improve scalability (details in the paper) 23
  • 33. Prototype Implementation • Lua engine in kernel (11K SLOC) – Simple – Memory-safe – Easy to embed and extend – 24 years of development • Semantic matching – angr 25
  • 34. Evaluation: Applicability • Evaluated 76 critical vulnerabilities in the last three years • Patch level: – Level-1: 49 – Level-2: 22 – Level-3: 5 26
  • 36. Evaluation: Adaptability Types and frequencies of instruction opcodes 27
  • 37. Evaluation: Adaptability Number of function calls and conditional branches (to abstract CFG) 27
  • 39. Evaluation: Performance CF-Bench results with different patches 28
  • 40. Evaluation: Performance Execution time of chmod with different patches 29
  • 41. Future Work • User-space vulnerability protection – Project Treble  only partially solve the problem • Lua engine in the kernel (11K SLOC) – Alternative execution engines, like BPF or sandboxed binary patches • Error handling code could be vulnerable – Error injection to detect vulnerable error-handling code • Improve semantic matching 30
  • 42. Adaptive Android Kernel Live Patching www.YueChen.me Q & A
  • 44. Attack TrustZone from Kernel • Example: – Downgrade Attack on TrustZone (see its references) 34
  • 45. Observations • Most kernel functions are stable across devices and Android releases. Number of syntax clusters for each function 35 About 40% of the shared functions have only one cluster, and about 80% of them have 4 clusters or less. Cluster Number Kernel Function Number
  • 46. Observations • Most kernel functions are stable across devices and Android releases. 36 For about 60% of shared functions, the largest cluster contains more than 80% of all the kernels that have this function. Kernel Function Number Percentage of kernels in the largest cluster for each function
  • 47. Symbolic Execution • Challenges – Avoid path explosion – Impact to the environment • Practical Solution – Non-local memory writes – Function calls (and their arguments) – Function return values • Adaptation (e.g., mutate constants or offsets) – foo(symbol_A + 4, 36) foo(symbol_A + 8, 36) 37
  • 48. Evaluation: Overall Performance • Complex patch for most frequent syscall (gettimeofday) during web browsing • Overall system performance overhead in this extreme situation: 0.9% 39
  • 55. You May Also Like • A time machine to locate vulnerabilities: – Pinpointing Vulnerabilities • Protect your computer by encrypting memory all the time: – Secure In-Cache Execution • Fine-grained dynamic ASLR during runtime: – Remix: On-demand Live Randomization 55