Mind the Gap: Dissecting the Android Patch Gap

Home , Patch (computing), Stagefright (bug)

Mind the Gap – Dissecting the Android patch gap

Ben Schlabs

SRLabs Template v12

Corporate Design 2016 Allow us to take you on two intertwined journeys

This talk in a nutshell

§ Wanted to understand how fully-maintained Android phones can be exploited Research § Found surprisingly large patch gaps for many Android vendors journey – some of these are already being closed § Also found Android exploitation to be unexpectedly difficult

§ Wanted to check thousands of firmwares for the presence of Das Logo Horizontal hundreds of patches — Pos / Neg Engineering § Developed and scaled a rather unique analysis method journey § Created an app for your own analysis

3 Android patching is a known-hard problem

Patching challenges Patch ecosystems

§ Computer OS vendors regularly issue patches OS vendor § Users “only” have to confirm the installation of § Microsoft OS patches Patching is hard these patches § Apple Endpoints & severs to start with § Still, enterprises consider regular patching § Linux distro among the most effortful security tasks

§ “The mobile ecosystem’s diversity […] OS Chipset Phone Android contributes to security update complexity and vendor vendor vendor phones inconsistency.” – FTC report, March 2018 [1] The nature of Telco § Das Logo HorizontalAndroid makes Patches are handed down a long chain of — Pos / Negpatching so typically four parties before reaching the user much more § Only some devices get patched (2016: 17% [2]). difficult We focus our research on these “fully patched” phones

Our research question – How many patching mistakes are made in this complex Android ecosystem? That is: how many patches go missing?

3 Vendor patch claims can be unreliable; independent verification is needed

How do we determine whether an Android binary has a patch installed, without access to the corresponding source code?

Try exploiting the Apply binary-only patch Trust vendor claims? corresponding vulnerability? heuristics

§ No exploits publicly § Find evidence in the binary available for most Android itself on whether a patch is bugs installed § A missing patch also does § Scale to cover hundreds of not automatically imply an patches and thousands of open vulnerability phones Das Logo Horizontal (It’s complicated. — Pos / Neg § Let’s talk about it later) The topic of this presentation

Important distinction: A missing patch is not automatically an open security vulnerability. We’ll discuss this a bit later.

3 Patching is necessary in the Android OS and the underlying Linux kernel

Android OS patching (“userland”) Linux kernel patching

Responsibility § Android Open Source Project (AOSP) is maintained by § Same kernel that is used for much of the Internet Google § Maintained by a large ecosystem § In addition, chipset and phone vendors extend the OS § Chipset and phone vendors contribute hardware to their needs drivers, which are sometimes kept closed-source

Security § Most exposed attack surface: The OS is the primary § Attackable mostly from within device relevance layer of defense for remote exploitation § Relevant primarily for privilege escalation (“rooting”)

Das Logo Horizontal — Pos / NegPatch § Monthly security bulletins published by Google § Large number of vulnerability reports, only some of situation § Clear versioning around Android, including a patch which are relevant for Android level date, which Google certifies § Tendency to use old kernels even with latest Android for some phones version; e.g., Kernel 3.18 from 2014, end-of-life: 2017

We focus our attention on userland patches

3 Agenda

§ Research motivation

§ Spot the Android patch gap

§ Try to exploit Android phones

Das Logo Horizontal — Pos / Neg

3 We want to check hundreds of patches on thousands of Android devices

Android Android’s 2017 Source code is Of these So far, we The heuristics would userland security available for userland bugs, implemented optimally work on patch bulletins list heuristics for hundreds of thousands analysis of Android firmwares: ~280 ~240 ~180 164 – 60,000 Android variants [3] bugs (~CVEs) of these bugs originate from of the – with Critical or C/C++ code corresponding Regular updates for High severity (plus a few Java) patches many of these variants

Das Logo HorizontalOut-of- ~700 kernel and The remaining We do not yet — Pos / Neg scope medium/low bugs are in support most (for now) severity closed-source Java patches userland vendor-specific patches components

3 The patch gap: Android patching completeness varies widely for different phones

Not affected Patch found applied as claimed Patch found above claimed level Not tested Patch not found within claimed level Claimed patch level Patch not found outside claimed level Android version release date

2016 2017 Patches ”missing” 9 10 12 1 2 3 4 5 6 7 8 9 11 12 Critical High

Google Pixel 2 Android version 8.1 0 0 Patch level: Apr 2018

Samsung J5 (2017) Android version 7.0 0 0 Patch level: Apr 2018

Das Logo Horizontal — Pos / NegNOKIA 3 Android version 7.1.1 0 8 Patch level: Mar 2018

Wiko Freddy Android version 6.0.1 17 49 Patch level: Sep 2017

3 Binary-only analysis: Conceptually simple

1 Prepare patch test set 2 Test for patch presence

Apply Vulnerable source code patch Patched source code

Compile with different compliers, compiler configurations, Binary file CPU options

Mask volatile Mask volatile information (e.g. call destinations) information Das Logo Horizontal — Pos / Neg Compare to collections: Collection of unpatched Collection of patched Find match with patched binaries binaries ? or unpatched sample

3 At scale, three compounding challenges need to be solved

Too much source code § There is too much source code to collect § Once collected, there is too much source code to compile

Too many compilation possibilities § Hard to guess which compiler options to use § Need to compile same source many times

Das Logo Horizontal — Pos / Neg Hard to find code “needles” in binary “haystacks” § Without symbol table, whole binary needs to be scanned § Thousands of signatures of arbitrary length

3 Amount of source code

Signature generation would require huge amounts of source code Compilation possibilities

Needles in haystacks

One Android source code tree is roughly 50 GiB in size Source code trees are managed in a manifest, which lists git repositories with revision and path in a source code tree … … +~500 MORE REPOSITORIES

Signature generation requires many source code trees Das Logo Horizontal — Pos / Neg § Hundreds of different Android revisions Currently ~1100 source code trees are used in total (e.g. android-7.1.2_r33) (many more exist!) § Device-specific source code trees (From Qualcomm Codeaurora CAF) 1100 x 50 GiB = 55 TiB Would require huge amount of storage, CPU time, and network traffic to check out everything

3 Amount of source code

We leverage a FUSE (filesystem in userspace) to retrieve files only on demand Compilation possibilities

Needles in haystacks Insight: The same git repositories are used for many manifests.

Manifest 1 platform/frameworks/av platform/frameworks/av rev 330d132d rev 330d132d platform/frameworks/base rev 85838fea rev d43a8fe2 rev deadbeef

Manifest 2 platform/frameworks/base platform/frameworks/av rev d43a8fe2 rev 85838fea platform/frameworks/base rev 18fac24b rev 18fac24b rev cafebabe Manifest 3 platform/frameworks/av rev deadbeef

Das Logo Horizontal platform/frameworks/base rev cafebabe — Pos / Neg How this can be leveraged Filesystem in userspace (FUSE) Reduces storage requirement by >99%: § Store each git repository only once 55 TiB => 300 GiB (with git clone --no-checkout) Saves network bandwidth and time required for § Extract files from git repository on demand checkout when the file is read Prevents IP blocking by repository servers § Use database for caching directory contents

3 Amount of source code

Brute-forcing 1000s of compiler variants finds 74 that produce valid signatures Compilation possibilities

for all firmwares tested to date Needles in haystacks

Tests are regularly optimized Successful sub-tests § Our collection includes 3897 compiler 10000 configuration variants, only 74 of which are 9000 required for firmwares 8000 § tested to date. For 224 tested 64-bit firmwares, signatures from the first 74 § To ensure a high rate of 7000 conclusive tests, test compiler config variants provide results are regularly 6000 full test coverage § à checked for success. 74 variants à § The test suite is amended 5000 6,944 signatures 3MB Just two variants account for 60% of successful sub-tests: § We tried 3,897 variants à with additional variants - gcc version 4.9.x-google 20140827 (prerelease) 775,795 signatures à 34MB from the collection as 4000 Das Logo Horizontal - Android clang version 3.8.256229 needed. — Pos / Neg 3000 Both were run with each git’s default configuration § The collection itself is amended with additional 2000 compiler configuration variants as they become 1000 relevant. 0 0 10 20 30 40 50 60 70 80 90 100 110 120 130 # compiler config variants = compilers x [compiler options]

3 Amount of source code

Using improved rolling signatures, we can efficiently search the binary ‘haystack’ Compilation possibilities

for our code ‘needles’ Needles in haystacks

Process step Hex dump of instruction Assembly code / instructions ... Potential relocation entries are Sanitize arguments before 97fee7a2 bl c7c40 checksumming detected based on instruction. Zero-out volatile bits 94000000 bl 0 f10002ff cmp x23, #0x0 1a9f17e8 cset w8, eq Match signatures of Size-8 window matches on b40000b6 cbz x22, 10ddbc arbitrary lengths using start of signature 3707fdc8 tbnz w8, #0, 10dd6 sliding windows f10006d6 subs x22, x22, #0x1 § Two overlapping sliding windows 54ffff42 b.cs 10dd9c § Only needs powers of 35fffd48 cbnz w8, 10dd64 Das Logo Horizontal2 as window sizes to — Pos / Neg 36000255 tbz w21, #0, 10de08 match arbitrary 394082e8 ldrb w8, [x23,#32] function lengths Overlapping window matches § Allows efficient on end of signature 35000208 cbnz w8, 10de08 scanning of a binary 52adad21 mov w1, #0x6d690000 for a large number of 320003e8 orr w8, wzr, #0x1 signatures 728daca1 movk w1, #0x6d65

To avoid false positives (due to guessed relocation entries), signature is matched from the first window to the end of the overlapping window

3 Putting it all together: With all three scaling challenges overcome, we can start testing

1 2 Prepare patch test set Test for patch presence

Mount source code tree Run source-code analysis Generate build log § Find and extract § Read manifest § Source-code patch analysis § Run build system in dry-run function (using § Fuse filesystem to read files is much easier than binary mode, don’t compile symbol table or on demand analysis everything rolling signature) § Determines whether a § Save log of all commands to § Mask relocation signature match means that be executed entries from the patch is applied or not § Various hacks/fixes to build signature system required § Calculate and compare hash of remaining code Preprocess source files Recompile with variants Generate signatures Das Logo Horizontal — Pos / Neg§ Use command line from § >50 different compiler § Evaluate relocation entries saved build log binaries and create signatures for § Save preprocessor output § All supported CPU types each compiler variant in database § Optimization levels (e.g. -O2, -O3) § 3897 combinations in total, 74 in our current optimized set

3 SnoopSnitch version 2.0 introduces patch analysis for all Android users

Tool name

SnoopSnitch

Purpose

§ [new in 2.0] Detect potentially missing Android security patches § Collect network traces on Android phone and analyze for abuse § Optionally, upload network traces to GSMmap for further analysis

Requirements

§ Android version 5.0 Das Logo Horizontal — Pos / Neg § Patch level analysis: All phones incl. non-rooted § Network attack monitoring: Rooted Qualcomm-based phone

Source

Search: SnoopSnitch

3 Patch gap: Android vendors differ widely in their patch completeness

Missed patches Vendor Samples* Missed patches Vendor Samples* Notes

BlackBerry Lots Alps Many – The tables shows the average Essential Many Infinix Lots number of missing Critical and Fairphone Many LEAGOO Many High severity patches before the claimed patch date GM Many Lenovo Many Google Lots 2 to 4 TCL Lots * Samples – Few: 5-9; Many: 10-49; Lots: 50+ LG Lots TECNO Many Motorola Lots – Some phones are included 0 to 1 vernee Lots multiple times with different OnePlus Lots WIKO Lots firmware releases Samsung Lots ZTE Many – Not all patch tests are always SHARP Many conclusive, so the real number Blackview Many Sony Lots of missing patches could be DOOGEE Many higher Wileyfox Many GIONEE Lots – Not all patches are included in Das Logo Horizontal Xiaomi Lots — Pos / Neg Itel Many our tests, so the real number ZUK Lots could be higher still LeEco Many Asus Lots 4 or more – Only phones are considered Meizu Many HONOR Lots that were patched October- HTC Lots Micromax Many 2017 or later 1 to 2 Huawei Lots nubia Lots – A missing patch does not automatically indicate that a Nokia Lots OPPO Many related vulnerability can be vivo Lots Oukitel Many exploited

3 Vendors are improving the speed to bring patches to their phones, especially for newer Android versions – Samsung

Patch delay for different Android versions over time - Samsung

260

210

160

110 Das Logo Horizontal — Pos / Neg

2015-10 2016-01 2016-04 2016-07 2016-11 2017-02 2017-05 2017-09 2017-12 2018-03 2018-06 5.x 6.x 7.x 8.x Linear (5.x) Linear (6.x) Linear (7.x) Linear (8.x) -40

3 Vendors are improving the speed to bring patches to their phones, especially for newer Android versions – Huawei

40 Patch delay for different Android versions over time - Huawei

Das Logo Horizontal0 — Pos / Neg 2015-10 2016-01 2016-04 2016-07 2016-11 2017-02 2017-05 2017-09 2017-12 2018-03 2018-06

-10

After SnoopSnitch -20 release 5.x 6.x 7.x 8.x Linear (5.x) Linear (6.x) Linear (7.x) Linear (8.x)

3 Phones more recently receive updates faster and with fewer gaps

50 Patch delay and number of missing patch over time - Huawei P9 Lite

Das Logo Horizontal0 — Pos / Neg2016-01 2016-04 2016-07 2016-10 2017-02 2017-05 2017-08 2017-12 2018-03 2018-06

-10

-20 Days between patch bulletin and firmware build Missed patches [crit+high] Linear (Days between patch bulletin and firmware build) Linear (Missed patches [crit+high])

3 Agenda

§ Research motivation

§ Spot the Android patch gap

§ Try to exploit Android phones

Das Logo Horizontal — Pos / Neg

3 Can we now hack Android phones due to missing patches?

Mobile operating systems are inherently At first glance, Android phones look hackable VS. difficult to exploit § We find that most phones miss patches § Modern exploit mitigation techniques within their patch level increase hacking effort § While the number of open CVEs can be § Mobile OSs explicitly distrust applications smaller than the number of missing patches, through sandboxing, creating a second layer we expect some vulnerabilities to be open of defense

Das Logo Horizontal — Pos / Neg § Many CVEs talk of “code execution”, § Bug bounties and Pwn2Own offer relatively suggesting a hacking risk based on what we high bounties for full Android exploitation experience on Windows computers

3 Do criminals hack Android? Very rarely.

Criminals generally use three different methods to compromise Android devices

Social engineering Local privilege escalation Remote compromise Trick user into insecure actions: § Trick user into installing malicious app § Exploit vulnerability in an outside- § Install malicious app § Then exploit kernel-level vulnerability to facing app (messenger, browser) Approach § Then grant permissions gain control over device, often using § Then use local privilege escalation standard “rooting” tools § Possibly request ‘device administrator’ role to hinder uninstallation

§ Ransomware [File access permission] § Targeted device compromise, e.g. § (Google bug bounty, Pwn2Own) Used for § 2FA hacks [SMS read] FinFisher and Crysaor (Same company as infamous Pegasus malware) § Premium SMS fraud [SMS send] Das Logo Horizontal § Advanced malware — Pos / Neg Frequency in § Almost all Android “Infections” § Regular observed in advanced § Very few examples of recent criminal malware and spying criminal use activity

Made harder through (userland or kernel) (userland and kernel) patching û ü ü

3 An exploitable vulnerability implies a missing patch, but not the other way around

Missing patches in source code

Code parts that are ignored during compilation Missing patches (source code analysis) Missed patches in binary = Missing patches (binary analysis) Vendor created alternative patch

Vulnerability requires a specific configuration Open Das Logo Horizontal vulnerabilities — Pos / Neg Bug is simply not exploitable

Errors in our heuristic (it happens!) = Open vulnerabilities

3 A single Android bug is almost certainly not enough for exploitation

Android remote code execution is a multi-step process Simplified exploit chain examples with 4 bugs 1 Information leakage is used to derive ASLR memory offset (alternatively for 32-bit binaries, this offset can possibly be brute-forces) 1 Info leakage (IL) 2 Corrupt memory in an application. Examples: ASLR - Malicious video file corrupts memory using Stagefright bug 2 Memory 3a 4a - Malicious web site leverages Webkit vulnerability corruption (MC) IL MC Ø This gives an attacker control of the application including the apps access permission Application context ASLR Das Logo Horizontal 3 4 Do the same again with two more bugs to gain — Pos / Neg access to system context or kernel 3b IL System context Ø This gives an attacker all possible permissions KASLR (system context), or full control over the device 4b MC (kernel) Kernel Aside from exploiting MC and IL programming bugs, Android has experienced logic bugs that can enable alternative, often shorter, exploit chains

3 Remotely hacking a modern Android device usually requires chains of bugs

Application context System context High privileged domain Remote protection mechanism protection mechanisms (e.g. system-server, attacker (e.g. ASLR, sandbox) (e.g. ASLR, sandbox) Bluetooth) 1 2 3 4

Famed Stagefright [2015] real-world Android < 5.1.1 X DH exploit Weakness severities examples Return to libstagefright [2016] Critical Android < 7.0 DH DH DH High BlueBorne [2017] Not needed: BNEP stack SF DH Android < 8.0 is addressed directly Moderate Pixel - Nexus 6P [2017] Chrome Android prior DH DH SF X Weakness classes 54.0.2840.90 Pixel [2018] DH Data handling errors (CWE-19) Das Logo Horizontal e.g. buffer errors, input — Pos / Neg Chrome Android prior TS DH 61.0.3163.79 validation mistakes SF Security features gaps (CWE-254) Step 1: Remote Code Execution Step 2: Escalation of Privilege e.g. permission errors, privileges and Information disclosure At least one other weakness (or mishandling, access control errors In many cases, one critical or high- the users themselves) helps the TS Time and state errors (CWE-361) severity weakness is exploited to attacker overcome protection e.g. race conditions, incorrect allow for Remote Code Execution mechanisms and gain access to type conversions or casting (RCE). (In the special case of higher privileges BlueBorne, no sandbox exists.)

3 In case you want to dive deeper: More details on well-documented Android exploit chains

1 2 3 4 DH Famed Return to Heap pointer leak to ROP execution in Module pointer leak to Call mprotect to get real-world libstagefright bypass ASLR protection mediaserver process get address of executable RCE into privileged exploit 2016 code system-server domain examples Not SF DH BlueBorne is a vulnerability in the needed Information leak Trigger memory Android Bluedroid/Fluorid userland stack, vulnerability leaks corruption in BNEP which is already a high-privileged domain arbitrary data from service that enables an BlueBorne the stack, which attacker to execute 2017 allows an attacker to arbitrary code in the derive ASLR base high privileged address for a bypass Bluetooth domain

DH DH SF X Content view client in Attacker perform arbitrary Open intent Exploit chain does not Das Logo Horizontal Chrome allowed read/write operations controlled URL include break-out of — Pos / Neg Pixel / Nexus 6P arbitrary intent leading to code execution in Google Drive untrusted app context 2017 scheme opening, based on incorrect to get shell in which allows escaping optimization assumption untrusted app the Chrome sandbox in Chrome v8 context

TS DH Chrome V8 bug to get RCE Use map and unmap mismatch in libgralloc to escape Chrome sandbox and Pixel in sandbox using a OOB inject arbitrary code into system-server domain by accessing a malicious URL 2018 bug in GetFirstArgument- in Chrome AsBytes function

3 Take aways

§ Android patching is more complicated and less reliable than a single patch date may suggest – but the situation has started improving

§ Remote Android exploitation is also much more complicated than commonly thought

§ You can finally check your own patch level thanks to binary-only analysis, and the app SnoopSnitch

Many thanks to Jakob Lell, Stephan Zeisberg, Jonas Schmid, Mark Carney, Das Logo Horizontal Lukas Euler, Patrick Lucey, and Karsten Nohl! — Pos / Neg

Questions? Ben Schlabs

3 References

1. Federal Trade Commision, Mobile Security Updates: Understanding the Issues, February 2018 https://www.ftc.gov/system/files/documents/reports/mobile-security-updates-understanding- issues/mobile_security_updates_understanding_the_issues_publication_final.pdf

2. Duo Labs Security Blog, 30% of Android Devices Susceptible to 24 Critical Vulnerabilities, June 2016 https://duo.com/decipher/thirty-percent-of-android-devices-susceptible-to-24-critical-vulnerabilities

3. Google, Android Security 2017 Year In Review, March 2018 Das Logo Horizontal https://source.android.com/security/reports/Google_Android_Security_2017_Report_Final.pdf — Pos / Neg

3 Backup

Das Logo Horizontal — Pos / Neg

3 A bit more background: Android firmwares go from source code to binaries in two steps

CompilerSource code Compiler Linker contains placeholders that are filled preprocesses and compiles source combines the object files into an in during preprocessing code into object files that are then executable firmware binary. fed into the linker

#include stp x28, x27, [sp,#-32]! stp x28, x27, [sp,#-32]! #include […] […] void foo(char* fn){ orr w2, wzr, #0x1000 orr w2, wzr, #0x1000 char buf[PATH_MAX]; mov x1, x8 mov x1, x8 strncpy(buf, fn, PATH_MAX); bl 0 bl 11b3e8 Das Logo Horizontal — Pos / Neg} […] […] ret ret

3 The basic idea: Signatures can be generated from reference source code

1 Compile reference source code (before and after patch)

Parse Disassembly of object file, after compiler but before linker disassembly 0000000000000000 : 0: a9bd7bfd stp x29, x30, [sp, #-48]! listing for 4: 910003fd mov x29, sp relocation […] 20: f9413e60 ldr x0, [x19, #632] entries 24: 52800042 mov w2, #0x2 // #2 28: b9402021 ldr w1, [x1, #32] Prepare 2c: 94000000 bl 0 2c: R_AARCH64_CALL26 impeg2_buf_mgr_release patch […] test set Sanitize instructions Instruction format of the bl instruction Das Logo Horizontal Toss out irrelevant destination — Pos / Neg 100x 01 ii iiii iiii iiii iiii iiii iiii addresses of the instruction

Create hash of remaining binary code

Generate signature containing function length, position/type of relocation entries, and hash of the code

3 Amount of source code

Using our custom FUSE, we can finally generate a large collection of signatures Compilation possibilities

Needles in haystacks

1 Mount source code tree Run source-code analysis Generate build log § Read manifest § Source-code patch analysis § Run build system in dry-run § Use FUSE filesystem to read is much easier than binary mode, don’t compile files on demand analysis everything § Determines whether a § Save log of all commands to signature match means that be executed the patch is applied or not § Various hacks/fixes to build Next system required question: Prepare How many patch different test set Preprocess source files Recompile with variants Generate signatures compiler § Use command line from § >50 different compiler § Evaluate relocation entries variants do Das Logo Horizontal — Pos / Neg saved build log binaries and create signatures for we need? § Save preprocessor output § All supported CPU types each compiler variant in database § Optimization levels (e.g. -O2, -O3) § 3897 combinations in total, 74 in our current optimized set

3 Amount of source code

Finding needles in a haystack: What do we do if there is no symbol table? Compilation possibilities

Needles in haystacks

2 Function Simply compare function with pre-computed samples found in symbol table

Function Challenge Insight Solution not in Checking signature at each position Similar problem already Take advantage of rsync rolling symbol Test for is computationally expensive solved by rsync checksum algorithm patch table presence

Das Logo Horizontal Relocation entries are not known Relocation entries are only Guess potential relocation entries — Pos / Neg while calculating checksum used for certain instructions based on instruction type and sanitize args before checksumming

32bit code uses Thumb encoding, Same binary code is often Only test 64bit code for which instruction start is not also available in 64bit version always clear based on same source code