AnSec2 0

Android Security:
Same-ol’, Same-ol’ (but worse)
Android Security
Jonathan Levin
http://NewAndroidBook.com
http://Technologeeks.com
(C) 2016 Jonathan Levin & Technologeeks.com - Share freely, but please cite source!
About this talk
• Provides- tour
.
of Android security, and insecurity
• Updates Last Year’s talk
- Last year: Features This year: Vulnerabilities
- http://Technologeeks.com/files/AnSec2.0.pdf
• Covered in “Android Internals: A Confectioner’s Cookbook”

- Chapter 8, to be exact
Android Internals::about
“Android Internals: A Confectioner’s Cookbook”
– 深入解析Android 操作系统 - Coming in Chinese (soon)
– “ ” – In Korean (Oct!)
– Volume I (Available now): Power User’s view
– Volume II (Available with N): Developer’s View
– Unofficial sequel to Karim Yaghmour’s “Embedded Android”, different focus:

• More on the how and why Android frameworks and services work
• More on Security (this talk is an excerpt from Volume I)
• (presently) only in-depth books on the subject
– http://www.NewAndroidBook.com/ :
• Free and powerful tools, plus bonus materials
– Android Internals & Reverse Engineering: Oct 10th-14th,, NYC

• http://Technologeeks.com/AIRE
Mobile Security
Attack Surface
• Threat models for mobiles consider three main vectors:
- Rogue applications (malware)
- Sandbox applications App Security
- Enforce Strong Permissions

- Harden OS Component Security
- Drive-By/Targetted REMOTE
- Code Injection via some malicious file format
- Rogue user (device theft, or unauthorized root)

- Lock Screen
- Secure Boot Process Device Security
- Encrypt User Data

Mobile Security
Trusted app may be

compromised as well
Attack Vectors (simplified)
HTML/Plugin/MIME/etc Malformed SMS/MMS
Subverted Trusted App
Any App Arbitrary Code Execution
User carelessness
Abuse system call
Permission mistake Framework vulnerability 3rd party daemon

Insecure, root
Linux kernel APIs
Unfettered access
Get system Get root
system_server runs all services Kernel Code Exec

in same address space!
Get Personal Data Defeat SELinux

As of L, SELinux in
Enforcing Mode provides
another layer of protection Total Compromise
Mobile Security
Mediaserver compromise
Attack Vectors (exploited)
Suberted Trusted App
Mediaserver compromise
Any App Arbitrary Code Execution
User carelessness
Abuse system call
Permission mistake Framework vulnerability 3rd party daemon

HTC WeakSauce
Towelroot (futex bug)
Other kernel 0-days
Get system Get root
Kernel Code Exec

Don’t get me started
Get Personal Data Defeat SELinux
Total Compromise
Local Attacks (rogue app, malware) Remote Attacks (input channels) Mobile Security

Any App
Trusted app may be

compromised as well Arbitrary Code Execution
Subverted Trusted App Remote attacks become local when arbitrary code can be
executed successfully in the context of some vulnerable app
3rd party daemons often less

User carelessness secure, and run as root/system
Abuse system call
Framework vulnerability 3rd party daemon Linux kernel can be

Permission mistake Attacked via syscalls
Get system Get root
system_server runs all services Kernel Code Exec

in same address space!
GOAL: Get Personal Data

Defeat SELinux
As of L, SELinux in
Enforcing Mode provides
another layer of protection GOAL: Total Compromise
Android Security
CVEs
• “Common Vulnerability Exposure” index
• Publishes and standardized security vulnerabilities
• Goal: Uniquely define particular and specific bugs
• Main database is at http://cve.mitre.org *
• Searchable database is at http://www.cvedetails.com/
https://www.cvedetails.com/product/19997/Google-Android.html?vendor_id=1224
* - (pronounced: might-er)
Android Security
A little history
Android Security
Google Response
Android Security
Android Application Security Model

• Android’s security is derived from that of Linux and Java
• Linux inheritance:
- Applications run as separate UIDs
- Kernel supports miscellaneous tweaks
- Network access filtered in kernel by UserID
- SELinux (“SEAndroid”) policies used extensively
• Java Inheritance:
- Dalvik VM provides sandbox for applications
- Declarative security model for operations
Android Security
Android Architecture
Applications
Contacts
PII
Dalvik Permissions Frameworks SMS
Most malware
Code Signatures Dalvik VM JNI .
Native
Binaries
Native Libraries
Unix permissions,
Capabilities HAL
Bionic System level attacks
SELinux, Linux 2.6.21-3.x Kernel RootKits

Kernel Hardening
Hardware
TrustZone
Android Security
Android Code Bases

Applications
Dalvik Permissions Frameworks
Code Signatures Dalvik VM JNI .

Native
Binaries
Native Libraries
Unix permissions,
Capabilities HAL
Bionic
SELinux, Linux 2.6.21-3.x Kernel

Kernel Hardening 3rd Party
Hardware AOSP
TrustZone
Vendor
Linux
Android Security
Scope of Vulnerabilities
• 3rd Party : Affects only devices with installed App
• AOSP:
AOSP : Affects ALL Android devices (global)
Vendor : Affects device vendor or chipset vendor

• Vendor:
• Linux:
Linux : Universal (also desktops, servers)
- Recommended: Monoculture on back of envelope (Geer, Usenix 2005)
3rd Party
AOSP
Vendor
Linux
Android Security
Updates (or lack thereof)

• Android is becoming Windows of the mobile world
Microsoft , 2004 : Google : 2016
• Android’s Update Policy is simply horrendous

– Getting better with N (finally)
– Still problematic due to existing fragmentation
– Exacerbated by vendor, carrier policies
• Impact: 70-80% devices left vulnerable, unpatched
Tour of Android Vulnerabilities
Code Injection
Prelude: Vectors for Code Injection

• Buffer Overflows (stack: rare, heap: uncommon)
– Example: char *c = malloc(10); strcpy (c, str...);
• Integer Overflows (common)

– Example: int a; int b; int c = a+b
– Lethal when used as basis for malloc()
• Use-After-Free (ubiquitous)
– Example: char *c = malloc(..); free (c); *c =....;
Code Injection
CounterMeasures for Code Injection

– isolation/sandboxing, pray SELinux works
– ASLR (ELF PIE + randomize_va_space)
– DEP
– Stack Canaries and compiler level protections.
– PXN (Privileged eXecute Never)
– Restrict dmesg and kernel pointers (via sysctl)
• kernel.kptr_restrict = 2
Code Injection
Counter-
CounterMeasures for Code Injection
Opt-in, still not tight enough, keep praying
– isolation/sandboxing, pray SELinux works
Info Leaks, Feng Shui, sprays
– ASLR (ELF PIE + randomize_va_space)
– DEP Return Oriented Programming (ROP)
Directed overwrite
– Stack Canaries and compiler level protections.
– PXN (Privileged eXecute Never) Overflow in kernel
– Restrict dmesg and kernel pointers (via sysctl)
• kernel.kptr_restrict = 2 Info Leaks, sprays in kernel
Top 3 Risks
Top 3 risks - #3: File Formats

• File Formats: Codec, HTML/CSS, JS
– Vector: Remote (and also Local)
– Impact: Privilege Escalation – usually media/drm/system
– Reason: overly complex formats, interpreters
• Particularly, CSS/JS parsing, media files
– Countermeasures:
• Standard Code Injection Countermeasures
• SELinux
Top 3 Risks
Top 3 risks - #3: File Formats

• Case Study:
– (Another) StageFright Bug (CVE-2015-3864)
– http://googleprojectzero.blogspot.com/2015/09/stagefrightened.html
– https://github.com/NorthBit/Metaphor
– https://www.exploit-db.com/exploits/38226/
Top 3 Risks
Top 3 risks - #2: Binder
• Binder: Deliberately Malformed parcels
- Vector: Local
https://www.blackhat.com/docs/asia-
- Impact: 16/materials/asia-16-He-Hey-Your-Parcel-
Privilege Escalation – system,
Looks-Bad-Fuzzing-And-Exploiting-
likely root
Parcelization-Vulnerabilities-In-Android.pdf
- Reason: LOUSY NATIVE CODE, NO AIDL
- CounterMeasures: q.v. Code Injection
Top 3 Risks
Top 3 risks - #2: Binder

• Case Study #1:
– LibCUtils–CVE-2015-1528 (< 5.1)
– http://seclists.org/fulldisclosure/2015/Mar/63
– https://www.blackhat.com/docs/us-15/materials/us-15-Gong-Fuzzing-
Android-System-Services-By-Binder-Call-To-Escalate-Privilege-wp.pdf
• Case Study #2:

– “Hey, Your Parcel Looks Bad” (BlackHat Asia ‘16)
https://www.blackhat.com/docs/asia-16/materials/asia-16-He-Hey-Your-Parcel-Looks-Bad-
Fuzzing-And-Exploiting-Parcelization-Vulnerabilities-In-Android.pdf
Top 3 Risks
Top 3 risks - #1: Linux Kernel
• Linux Kernel: vulnerable system calls, or network stack
- Vector: Local (usually), Remote (very rare)
- Impact: Full system compromise
- Reason: Too many cooks, with too many features
• Solution: SELinux
• Limited scope, not designed for app security

Top 3 Risks
Top 3 risks - #1: Linux Kernel

• Case Study #1:
– TowelRoot (CVE-2014-3153) – futex bug
• Case Study #2:

– PingPong Root (CVE-2015-3636 ) – ICMP sockets
• Case Study #3: (SELinux blocks this one)

– Keyrings (CVE-2016-0728)
– https://www.exploit-db.com/exploits/40003/
Untrustworthy TrustZone
Bonus Risk: TrustZone

• ARMv7/v8 memory separation at bus level
• SCR separates “secure world” from non secure
– In ARMv8, coupled with Exception Levels (ELx)
• “Secure World” runs own OS(!), providing:

– Keystore Access (“hardware backed cryptography)
– Gatekeeper Functionality (crypto-tokens)
– PRNG
– Boot/System Integrity verification (e.g. Samsung TIMA)
Android & TrustZone

keystore
HAL
com.android.application
TZ Daemon
gatekeeper (e.g. qseecomd)
SVC指令
HAL
Kernel
TZ Driver
3rd Party
Android SMC指令
Vendor
Linux
TZ OS
TrustZone Vulnerabilities
• Problem: TZ OS is often vendor defined, closed source
– Google trying to standardize with “Trusty OS”
– Qualcomm (most common) has own, and BUGGY
• http://bits-please.blogspot.com
– AMAZING detail of trustzone exploitation on MSM, step-by-step
– Particularly as of /2015/03/getting-arbitrary-code-execution-in.html
Android Vulnerabilities
Android Security
Hindsight is 20/20
• All the CVEs discussed are obvious, in retrospect:
“Reports that say that something hasn't happened are always interesting to
me, because as we know, there are known knowns; there are things we
know we know. We also know there are known unknowns; that is to say we
know there are some things we do not know. But there are also unknown
unknowns – the ones we don't know we don't know. And if one looks
throughout the history of our country and other free countries, it is the latter
category that tend to be the difficult ones.
D. Rumsfeld, 2002,
http://archive.defense.gov/Transcripts/Transcript.aspx?TranscriptID=2636
• Known knowns = CVEs, Past Vulnerabilities

• Known unknowns = Vulnerabilities we suspect
• Unknown unknowns = 0-days in the wild
So, overall..
• Sad Truth: Android “spitballs” Linux features together

• Sometimes it sticks. More often than not.. It doesn’t.
Resources
• The Book website: http://NewAndroidBook.com
• Technologeeks.com: http://Technologeeks.com/
• Android Internals: http://Technologeeks.com/AIRE

AnSec2 0

Uploaded by

Copyright:

Available Formats

AnSec2 0

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

AnSec2 0

Uploaded by

Copyright:

Available Formats

Android Security:

Same-ol’, Same-ol’ (but worse)

• Covered in “Android Internals: A Confectioner’s Cookbook”

– Unofficial sequel to Karim Yaghmour’s “Embedded Android”, different focus:

– Android Internals & Reverse Engineering: Oct 10th-14th,, NYC

- Enforce Strong Permissions

- Code Injection via some malicious file format

- Rogue user (device theft, or unauthorized root)

- Encrypt User Data

Trusted app may be

Any App Arbitrary Code Execution

Permission mistake Framework vulnerability 3rd party daemon

system_server runs all services Kernel Code Exec

Get Personal Data Defeat SELinux

Any App Arbitrary Code Execution

Permission mistake Framework vulnerability 3rd party daemon

Kernel Code Exec

Get Personal Data Defeat SELinux

HTML/Plugin/MIME/etc Malformed SMS/MMS

Trusted app may be

3rd party daemons often less

Framework vulnerability 3rd party daemon Linux kernel can be

Get system Get root

system_server runs all services Kernel Code Exec

GOAL: Get Personal Data

Android Application Security Model

SELinux, Linux 2.6.21-3.x Kernel RootKits

Android Code Bases

Dalvik Permissions Frameworks

Code Signatures Dalvik VM JNI .

SELinux, Linux 2.6.21-3.x Kernel

Vendor : Affects device vendor or chipset vendor

Updates (or lack thereof)

• Android’s Update Policy is simply horrendous

• Impact: 70-80% devices left vulnerable, unpatched

Prelude: Vectors for Code Injection

• Integer Overflows (common)

CounterMeasures for Code Injection

Top 3 risks - #3: File Formats

Top 3 risks - #3: File Formats

Top 3 risks - #2: Binder

• Binder: Deliberately Malformed parcels

- CounterMeasures: q.v. Code Injection

Top 3 risks - #2: Binder

• Case Study #2:

Top 3 risks - #1: Linux Kernel

• Linux Kernel: vulnerable system calls, or network stack

- Vector: Local (usually), Remote (very rare)

- Impact: Full system compromise

- Reason: Too many cooks, with too many features

• Limited scope, not designed for app security

Top 3 risks - #1: Linux Kernel

• Case Study #2:

• Case Study #3: (SELinux blocks this one)

Bonus Risk: TrustZone

• “Secure World” runs own OS(!), providing:

Android & TrustZone

• Known knowns = CVEs, Past Vulnerabilities

• Sad Truth: Android “spitballs” Linux features together