Adaptive Android Kernel Live Patching - PowerPoint Presentation

Slide1

Adaptive Android Kernel Live Patching

Yue Chen1, Yulong Zhang2, Zhi Wang1, Liangzhao Xia2, Chenfu Bao2, Tao Wei2Florida State University1Baidu X-Lab2

USENIX Security Symposium 2017Slide2
Android Kernel Vulnerabilities

2

AppsJava API FrameworkNative C/C++ LibrariesLinux KernelAndroid Runtime

Hardware Abstraction Layer

TrustZoneSlide3
Android Kernel Vulnerabilities

2

AppsJava API FrameworkNative C/C++ LibrariesLinux KernelAndroid Runtime

Hardware Abstraction Layer

TrustZoneSlide4
Android Kernel Vulnerabilities

2

AppsJava API FrameworkNative C/C++ LibrariesLinux Kernel

Android Runtime

Hardware Abstraction Layer

TrustZoneSlide5

Number of Disclosed Android Kernel V

ulnerabilities3Slide6

Problem: Old Exploits Remain Effective

Number of devices vulnerable to two root exploits as of Nov. 20164Android 5.0 released in November 201446.3% of devices run an older version in September 2016Slide7
Challenges

Officially

patching an Android device is a long process  Third-partyDelayed/non-existing kernel source code  Binary-based5Slide8
Challenges

Severely

fragmented Android ecosystem  Adaptive6http://d.ibtimes.co.uk/en/full/1395443/android-fragmentation-2014.pngSlide9

Solution

Third-party Binary-based Adaptive Kernel Live Patching7Key requirements:AdaptivenessIt should be adaptive to various device kernelsSafetyPatches should be easy to auditTheir behaviors must be technically confinedTimelinessResponse time should be short, after disclosed vulnerability or exploitPerformanceThe solution should not incur non-trivial performance overheadSlide10
Feasibility Study: Dataset

Studied

1139 Android kernels8Slide11

Most kernel functions are stable across devices and Android releasesMost vulnerabilities triggered

by malicious inputsMany functions return error codesReturn a pointer  ERR_PTRFeasibility Study: Observations9Slide12

Most kernel functions are stable across devices and Android releasesMost vulnerabilities triggered

by malicious inputsMany functions return error codesReturn a pointer  ERR_PTRGracefully returnFeasibility Study: Observations9

Filter themSlide13

Overall Approach: Input Validation

10Slide14

KARMA

KARMA: Kernel Adaptive Repair for Many AndroidsAdaptive – Automatically adapt to various device kernelsMemory-safe – Protect kernel from malicious (misused) patchesMulti-level – Flexible for different vulnerabilities11Slide15

KARMA Design: SafetyPatches are written in

Lua, confined by Lua VM at runtimeA patch can only be placed at designated locationsPatched functions must return error codes or voidUse existing error handling to recover from attacksA patch can read but not write the kernel memoryConfined by KARMA APIsPrevent malicious (misused) patches from changing the kernelPrevent information leakage12Slide16

KARMA Design: Multi-level PatchingA patch can only be placed at

designated locationsLevel 1: Entry or return point of a (vulnerable) functionLevel 2: Before or after the call site to a calleee.g., copy_from_userLevel 3: Binary-based patch76 critical Android kernel vulnerabilitiesLevel 1: 49/76 (64.5%)Level 2: 22/76 (28.9%)Level 3: 5/76 (6.6%)13Slide17

KARMA Patch Example

Part of the official patch of CVE-2014-3153 (Towelroot)14Slide18

KARMA Patch Example

15-EINVALMore complex examples in the paperSlide19

KARMA API

16Slide20

KARMA API

Available to patches16Slide21

KARMA Architecture

17Offline Patch Generation and VerificationOnline Live Patching by KARMA ClientSlide22
Offline P

atch Adaptation

Patch A

18Slide23
Offline Patch Adaptation

Three steps:

Identify the vulnerable functions in the target kernelSame function but different namesInlinedCheck if the reference patch works for the target kernelSame function but different semanticsAdapt the reference patch for the target kernel19Slide24

Vulnerable Function Identification ExampleCVE-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 g

raph

b

ased similarity comparisonSlide25

Semantic Matching

Check if two functions are semantically equivalentIf so, adapt the reference patch to the target kernelSyntactic matching is too strictDifferent compilers can generate different code with same semanticsInstruction order, register allocation, instruction selection, code layout21Slide26

Semantic

MatchingSame semantics with different syntax22Slide27

Semantic

MatchingSame semantics with different syntax22Slide28

Semantic

MatchingSame semantics with different syntax22Slide29

Semantic

MatchingSame semantics with different syntax22Slide30

Semantic

MatchingSame semantics with different syntax22Slide31

Semantic Matching

Check if two functions are semantically equivalentIf so, adapt the reference patch to the target kernelSyntactic matching is too strictDifferent compilers can generate different code with same semanticsInstruction order, register allocation, instruction selection, code layoutUse symbolic execution to abstract these differences and adapt patchesUse approximation to improve scalability (details in the paper)23Slide32
Online Patch Application

24

Function entry point hookingSlide33

Prototype ImplementationLua engine in

kernel (11K SLOC)SimpleMemory-safeEasy to embed and extend24 years of developmentSemantic matching – angr25Slide34

Evaluation:

Applicability Evaluated 76 critical vulnerabilities in the last three yearsPatch level:Level-1: 49Level-2: 22Level-3: 526Slide35

Evaluation: Adaptability

27Slide36

Evaluation: Adaptability

Types and frequencies of instruction opcodes27Slide37

Evaluation: Adaptability

Number of function calls and conditional branches (to abstract CFG)27Slide38

Evaluation: Adaptability

KARMA’s semantic matching27Slide39

Evaluation: Performance

CF-Bench results with different patches28Slide40

Evaluation: Performance

Execution time of chmod with different patches29Slide41

Future WorkUser-space vulnerability protection

Project Treble  only partially solve the problemLua engine in the kernel (11K SLOC)Alternative execution engines, like BPF or sandboxed binary patchesError handling code could be vulnerableError injection to detect vulnerable error-handling codeImprove semantic matching30Slide42

Adaptive Android Kernel Live Patching

www.YueChen.meQ & ASlide43

Backup SlidesSlide44

Attack TrustZone from KernelExample:

Downgrade Attack on TrustZone (see its references)34Slide45
Observations

Most

kernel functions are stable across devices and Android releases.Number of syntax clusters for each function35About 40% of the shared functions have only one cluster, and about 80% of them have 4 clusters or less.Cluster NumberKernel Function NumberSlide46

ObservationsMost

kernel functions are stable across devices and Android releases.36For about 60% of shared functions, the largest cluster contains more than 80% of all the kernels that have this function.Kernel Function NumberPercentage of kernels in the largest cluster for each functionSlide47

Symbolic ExecutionChallengesAvoid path explosion

Impact to the environmentPractical SolutionNon-local memory writesFunction calls (and their arguments)Function return valuesAdaptation (e.g., mutate constants or offsets)foo(symbol_A + 4, 36) foo(symbol_A + 8, 36)37 Slide48

Evaluation: Overall PerformanceComplex

patch for most frequent syscall (gettimeofday) during web browsingOverall system performance overhead in this extreme situation: 0.9%39Slide49

Example: CVE-2013-612349Slide50
Example: CVE-2013-6123

50Slide51
Example: CVE-2013-6123

51Slide52
Example: CVE-2013-6123

52Slide53
Example: CVE-2013-6123

53Slide54
Example: CVE-2013-6123

54Slide55

You May Also LikeA time machine to locate vulnerabilities:

Pinpointing VulnerabilitiesProtect your computer by encrypting memory all the time:Secure In-Cache ExecutionFine-grained dynamic ASLR during runtime:Remix: On-demand Live Randomization55