Android Kernel Security

Qualcomm Security Summit

May 2019

Jeff Vander Stoep

@jeffvanderstoep

AcknowledgementsSami Tolvanen

Evgenii Stepanov

2

This data is public

https://source.android.com/security/bulletin/

3

Android is an open source project

Patches accepted!

4

Kernel vulns in Android

Kernel accounts for 1/3 of security vulnerabilities on Android.

5

What’s working well:Attack Surface Reduction

6

“We think that by far the most effective mitigation work that we’ve seen on the Android platform over the last three

years has been the investment in attack surface reduction. The deployment and tightening of selinux policies and the addition of seccomp sandboxing both result in an attacker

needing to find more vulnerabilities in a smaller attack surface.”

Mark Brand - Google Project Zero

7

Attack surface reduction

Kernel vulnerabilities that are reachable in userspace but unreachable by unprivileged processes.

(su → kernel vulns are excluded)

8

Unprivileged AccessAccess Restricted

SELinux

e.g. CVE-2018-5858

Access control mechanismUnix Permissions

e.g. CVE-2017-14892

Capabilities

e.g. CVE-2017-17712

9

Unprivileged AccessPrivileged Access

Starting in Android Oreo all apps run with a

seccomp filter. e.g. Blocks CVE-2017-14140

10

Access control is effectiveAttack surface reduction works!

Kernel provided access control + separation of privilege can substantially mitigate risks to the kernel.

11

Unprivileged reachable bugs

(userspace reachable)

Some futex() and meltdown vulns.

12

Access controls are “hard” mitigations which can be applied without

knowledge of exploitation techniques.

13

Other userspace → kernelmitigations

14

Hardened UsercopyProvides some run-time checks on data copied to/from userspace

copy_*_user()

15

Vulnerabilities by root cause(userspace reachable)

PAN

Prevents direct kernel access to userspace.

Enforces use of (hardened) copy_*_user functions.

Found/fixed multiple instances of kernel directly accessing userspace.

16

Unfortunately, not all kernel vulns are reached via

userspace.

17

Kernel vuln reachability

Userspace Reachable Not Userspace Reachable

We’ve been discussing this.

But what about this ?!?!

18

Non-userspace reachable vulns

By access vector

By root cause

KRACK

19

Summary Userspace → kernel(a) The attack surface reduction tools provided by the kernel have been very effective on Android.

(b) In addition to attack surface reduction, the kernel now provides mechanisms such as hardened-usercopy + PAN which mitigate some userspace-reachable vulnerabilities.

(c) However, 1/3 of Android’s kernel bugs are reached by other vectors. We need tools similar to (a) and (b) to help address other access vectors.

20

Memory (un)safety

All kernel bugs

21

Control Flow Integrity

22

Control Flow Integrity

What?

Helps protect against code reuse attacks by adding runtime checks to ensure control flow stays within a precomputed graph.

Where?

LLVM ≥ 3.7 implements forward-edge CFI, which protects indirect branches.

How?

Allows an indirect branch only to the beginning of a valid function with the correct type.

23

How effective is CFI?

55% of indirect calls have ≤ 5 allowed targets

7% have > 100 allowed targets

24

80% have ≤ 20 allowed targets

Link Time Optimization

LLVM’s CFI implementation requires LTO to determine all valid call targets.

Must use LLVM’s integrated assembler for inline assembly and an LTO-aware linker, i.e. GNU gold or LLVM lld.

Nearly all problems caused by toolchain compatibility issues. No kernel stability issues during several months of testing.

25

Link Time Optimization

.S.c.c

.o.bc.bc

Front-end Linker

Thin archive

Optimizer

Code generation

vmlinux

Combined bitcode

26

CFI in the Linux kernel

C compilers allow indirect calls with mismatching types. Several benign CFI failures that had to be fixed.

Cross-DSO CFI support needed for kernel modules.

CFI adds a small overhead to indirect calls. Thanks to LTO, overall performance improved despite CFI.

27

Example of a CFI failure

Mismatching function pointer type

LLVM limits indirect calls to functions that match the type of the function pointer.

drivers/media/v4l2-core/v4l2-ioctl.c:

if (info->flags & INFO_FL_STD) {typedef int (*vidioc_op)(struct file *file, void *fh,

void *p);const void *p = vfd->ioctl_ops;const vidioc_op *vidioc = p + info->u.offset;

ret = (*vidioc)(file, fh, arg);}

Fixed in 3ad3b7a2ebaefae3 (“media: v4l2-ioctl: replace IOCTL_INFO_STD with stub functions”)

28

Example cont’d

CFI check, slowpath for cross-DSO. Only returns if the target address is allowed.

Indirect function call.

29

Example cont’d

Error handling

In normal mode, CFI failure results in a kernel panic, which includes the target address.

For debugging only, a permissive mode that produces a warning instead.

CFI failure (target: [<fffffff3e83d4d80>] my_target_function+0x0/0xd80):------------[ cut here ]------------kernel BUG at kernel/cfi.c:32!Internal error: Oops - BUG: 0 [#1] PREEMPT SMP…Call trace:…[<ffffff8752d00084>] handle_cfi_failure+0x20/0x28[<ffffff8752d00268>] my_buggy_function+0x0/0x10…

30

CFI in Android kernels

Supported in 4.9, 4.14, and 4.19 for arm64

CONFIG_LTO_CLANG=yCONFIG_CFI_CLANG=y

# CONFIG_CFI_PERMISSIVE=y for debugging.

Requires clang ≥ 5.0 and binutils ≥ 2.27.

31

Shipped on Pixel 3 & 3a

32

Shadow Call Stack

33

Shadow Call Stack

What?

Protects against return address overwrite.

Where?

LLVM ≥ 7.0 implements backward-edge CFI Only available for aarch64 architecture.

How?

Saves return addresses to a separate “shadow call” stack.

34

SCS Instrumentation

35

Comparison

36

Shadow Call stack

● Protects return address against linear, non-linear, and arbitrary writes.

● Protects Shadow Call Stack location from leakage using a reserved register.

● Does not protect other stack data from overwrite.

Stack Protector

● Protects return address against linear stack buffer overflows.

● Protects other stack frames against linear overwrites.

● Does not protect against non-linear/arbitrary writes.

● Does not protect against reads. i.e. stack contents may be leaked including the canary.

Use both!

SCS in Android kernels

Supported in 4.9, 4.14, and 4.19 for arm64

CONFIG_SHADOW_CALL_STACK=y

Requires clang ≥ 7.0. arm64 only.

37

Enabled on Pixel 3 in Android Q Beta

38

CFI -> forward edge CFISCS -> backward edge CFI

These provide complimentary, non-overlapping protection.

You need both!

39

HWASAN

40

HWASanFast(*) memory bug detector.

~2x CPU, ~50% binary size.10%-35% RAM.

● Compare with ASan’s 2x-3x RAM overhead.● Low enough to use the device as a daily driver.

Detects same bugs as ASan and more:● Use-after-free / use-after-return / out of declaration scope● Out of bounds access (heap and stack)● Double free, wild free, etc

Only AArch64 - depends on the “Top Byte Ignore” feature.

41

HWASanHWASan is a software implementation of the “Memory Tagging” approach.

● 8-bit tag in MSB of a pointer● Memory metadata (“shadow”) - one 8-bit tag per 16 bytes.

malloc() updates the memory tag and returns the same tag in the pointer.free() updates the memory tag.Stack allocations are tagged in function prologue/epilogue by the compiler.Load/store check that pointer tag == memory tag (compiler instrumentation).

42

HWASan in Android

make SANITIZE_TARGET=hwaddress

Requires kernel patches to allow tagged pointers in syscall arguments:https://source.android.com/devices/tech/debug/asan#using-hwasan

Works on Pixel 2/3/3a in AOSP/master. Try it!

Google “dogfood” statistics:● ~5 people using as daily device since ~Feb 2019● ~40 bugs found● new users => new use patterns => more bugs● new devices => new code paths => more bugs

43

ARM MTE

44

Future hardware extension, ARM v8.5Functionality mostly same as HWASan,but faster, simpler, and without recompilation.

● LD/ST check tag (mis)match implicitly● ISA extension to update pointer and memory tags● 4-bit tag per 16 bytes of memory.

Expected overheads:● RAM: ~ 3%● code size: 0%-5%● CPU: hopefully small single digit %

Future work

Memory (un)safety is an industry-wide crisis.

Vulnerabilities are being added faster than they’re being fixed.

We need to stop or slow the creation of vulnerabilities.

Memory safe languages are the best (only?) hope for actually fixing the issue.

45

Thank you