Honey, I Shrunk the Attack Surface
Adventures in Android Security Hardening
Nick Kralevich - Blackhat
July 27th, 2017

AgendaBrief history of Android security
Strategies for dealing with vulnerabilities
Bugs and attack surface reduction efforts
Recognition
The future
Questions?

Before we begin...

Android security is more than device
security...

Layers of defense even before code gets to the device...

Google Play
Unknown
SourcesWarning

InstallConfirmation
Verify Apps
Consent
Verify Apps
Warning
Runtime
Security
ChecksSandbox &permissions

Technology throughout Google working together
GooglePlay
InstallApps

AppXAppsApplication Analysis

Apps

Other Google
Services

Knowledge
PHA or not
Best practices

StaticDynamic
Reputation
Etc.

Knowledge
PHA or not

SearchDriveAds
Etc.
Knowledge
Risk Signal

AppY

Data
Rare Apps

ChromeAppZ

Smart Lock
Device Manager

AttestAPI

Safe Browsing
Android
App Sandbox
Verified Boot
Encryption
Etc.

Google PlayProtect
App Install
ChecksVerify Apps

Data
App
installs
Install
SourceKnowledge
PHA or Not

Protections
Warnings
Configuration
changes
Etc

Device Data
EventsMeasurements
Configurations
Etc.

SafetyNet
Analysis
Exploit Detection
ACESIC
Etc.

Key Principles

Key Android Security Principles●

Exploit Mitigation●

Attack Surface Reduction○Exploit Containment○

Principle of Least Privilege●

Safe by design APIs and interfaces●Architectural Decomposition

Stepping back in time...

10 years ago...
●Windows Vista was released○●

Replaced "administrator-by-default" philosophy of Windows XP

All desktop OSes○No difference between application capabilities and user
capabilities (remains mostly true today)○●

User has Administrator / root access (still mostly true today)

Mobile devices○

Primarily feature phones○

Smart devices not widely availableAndroid enters the picture●

HTC Dream - October 22nd, 2008○

First commercially available Android device●

Centralized application store●

Application sandboxing●

Memory safe programming language (Java)●

Designed with security in mind●

Strong desire to not repeat the security mistakes oflegacy consumer OSes

Early Android Security●

Exploit mitigation technologies
were the primary focus○-fstack-protector

○

ASLR

○

NX

○

FORTIFY_SOURCE○

mmap_min_addr○

Format string vulnerabilities○

etc...

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

Early Android Security
Applications sandboxed using Linux UIDtechnologies. Sandboxing of otherprocesses done on a limited basis.
Global “root” user which was unconstrained
and targeted for attack.

IPC boundaries were not consistently definedand enforced.
Security “policy” not auditable.

http://powerofcommunity.net/poc2016/keen.pdf

Heavy early use of discretionary access
control (DAC) tools.
●

Address space separation/process isolation●

UID controls●

UNIX permissions●

DAC capabilities●

namespaces●...

Greater focus oncompartmentalization,
attack surface reduction●

Sept 2011●

Proven effectiveness at preventing
or mitigating 7 rooting exploits●

Oct 2013: Android 4.4 partiallyenforcing●Oct 2014: Android 5.0 fully
enforcing

Immediate success in mitigating exploits!

●●●

vold “asec create” exploit (Android 4.4)●

Constrained attack surface mitigated exploit●

Blocked several ways○

/data/local/tmp directory and file access disallowed○

No symlink following allowed○

Mount restrictions

http://www.androidpolice.com/2014/06/04/android-4-4-3-patch-finally-closes-ancient-vulnerability-shuts-several-serious-security-exploits/
https://plus.google.com/u/0/+JustinCaseAndroid/posts/7BxgPNc7ZJs?cfem=1

Modern Day Android
Security
Every process compartmentalized (includingUID=0 processes)●“root” no longer exists on Android
Principle of least privilege widely deployedAttack surface limited through tightly
controlled IPC boundaries
Auditable security policy
Most executable code comes from signed
source / cryptographically verified (dm-verity).
http://powerofcommunity.net/poc2016/keen.pdf

Android TodayUser 1

User 2

Google Play

Google Play

Google Security
Services

Google PlayProtect

Contacts

Game XContacts

Game Y

Verify Apps

Safe Browsing

EmailGame YEmailGame ZDevice
ManagerSmart LockSystemSystemSystemSystemSystemSystem

System

UID=0

UID=0

UID=0

UID=0

UID=0

Trust Zone
KernelHardwareAttack Surface Reduction Examples

CVE-2017-6074: DCCP double-free vulnerability (local root)Networking Protocols●●

Only a whitelist of socket families areallowed# Restrict socket ioctls. Either# 1. disallow privileged ioctls,# 2. disallow the ioctl permission, or# 3. disallow the socket class.

○Netlink Route Sockets

neverallowxperm untrusted_app domain:{ rawip_socket
tcp_socket udp_socket } ioctl priv_sock_ioctls;○Ping Sockets

neverallow untrusted_app *:{ netlink_route_socket
netlink_selinux_socket } ioctl;○

TCP / UDP Sockets○

Unix stream and datagram sockets

Whitelist allowed ioctls

neverallow untrusted_app *:{socket netlink_socket packet_socket key_socket
appletalk_socket netlink_firewall_socket
netlink_tcpdiag_socket netlink_nflog_socket
netlink_xfrm_socket netlink_audit_socket
netlink_ip6fw_socket
netlink_dnrt_socket netlink_kobject_uevent_socket
tun_socket netlink_iscsi_socket
netlink_fib_lookup_socket netlink_connector_socket
netlink_netfilter_socket netlink_generic_socket
netlink_scsitransport_socketnetlink_rdma_socket netlink_crypto_socket} *;CVE-2017-6074: DCCP double-free vulnerability (local root)
Layers of attack surface reduction●Not compiled into Android commonkernels●

Even if compiled in, not reachable
due to SELinux restrictions.

●“dodged a bullet” -> “working asintended”

Whitelisted socket families - Other bugs mitigated●

Other bugs blocked○

CVE-2016-2059 - Linux IPC router binding any port as a control port○

CVE-2015-6642 - Security Vulnerability in AF_MSM_IPC socket:
IPC_ROUTER_IOCTL_LOOKUP_SERVER ioctl leaks kernel heap memory to userspace○

CVE-2016-2474 - Security Vulnerability - Nexus 5x wlan driver stack overflow○

etc...

CVE-2017-7184: xfrm kernel heap out-of-bounds accessCVE-2017-7184: xfrm kernel heap out-of-bounds access●Compiled into Android kernels●

Requires CAP_NET_ADMIN○●

Available to lots of processes on Android.

Requires netlink_xfrm_socket●

Who has it?

CVE-2017-7184: xfrm kernel heap out-of-bounds access●

Reachability:○

Only available to one process!

○Effectively unreachable.

nnk@nick:/android$ adb pull /sys/fs/selinux/policy/sys/fs/selinux/policy: 1 file pulled. 8.5 MB/s (451031 bytes in 0.051s)

nnk@nick:/android$ sesearch --allow -c netlink_xfrm_socket -p create ./policy
allow netmgrd netmgrd:netlink_xfrm_socket { nlmsg_write setopt setattr read lockcreate nlmsg_read write getattr connect shutdown bind getopt append };TL;DR:

Careful attack surface management
kept these bugs from being
reachable.

Attack Surface Management
Android O: Project TrebleProject Treble●A modular base for Android●Allows updating Android withoutAndroidAppsAndroid OS
framework

Vendorimplementation

additional work from silicon
vendor●Strong separation and APIs
between vendor and Android
codeDeveloperAPI

https://android-developers.googleblog.com/2017/05/here-comes-treble-modular-base-for.html

Vendor interface

Project Treble - Attack Surface Management

https://android-developers.googleblog.com/2017/07/shut-hal-up.html

Project Treble - Attack Surface Management●

Each HAL runs in its own sandbox○ Limited to only capabilities
needed●Calling process no longer requires
HAL permissions○ Example: 20 HALs moved outof system_server●Longer attack chain to the mostvulnerable drivers

https://android-developers.googleblog.com/2017/07/shut-hal-up.html

Mediaserver hardening

Stagefright●Series of bugs discovered mid 2015

●Integer overflow in parsing process●

Mediaserver architected for containment
with minimal attack surface●

Mediaserver grew up. More features =>more capabilities●

Android’s first “successful failure”○

No evidence of widespread
exploitation for 2 years now.

https://twitter.com/jduck/status/756197298355318784

Media Stack Hardening in Nougat

MediaServer
ExtractorService
MediaServer

MediaCodecService
AudioServer
CameraServer
MediaDrmServer

https://www.blackhat.com/docs/us-16/materials/us-16-Kralevich-The-Art-Of-Defense-How-Vulnerabilities-Help-Shape-Se
curity-Features-And-Mitigations-In-Android.pdf

mediaextractor: seccomp
Significant reduction in syscall attack
surfaceArchitecture

arm

arm64

x86

Allowedsyscalls

42

34

42

Kernelsyscalls

364

271

373

Percent
reduction

89%

87%88%

finit_module(5, "", 0) = ?
ERESTART_RESTARTBLOCK (Interrupted by signal)--- SIGSYS {si_signo=SIGSYS, si_code=SI_USER,
si_pid=20745, si_uid=2000} --+++ killed by SIGSYS +++Bad system call

$ cat mediaextractor-arm64.policy# Organized by frequency of system call
# - in descending order for best performance.
ioctl: 1
futex: 1
prctl: 1
write: 1
getpriority: 1
close: 1
dup: 1
mmap: 1munmap: 1
openat: 1
mprotect: 1
madvise: 1
getuid: 1...

mediaserver: additionalchanges●

Signed and unsigned integer overflow
protections●

Remove “execmem”○●

No anonymous executable memory

No loading executable code from outside/system (not new in Nougat)●

Executable content can only come fromdm-verity protected partition●… and moreopen("/system/lib/libnetd_client.so",
O_RDONLY) = 3
mmap2(NULL, 12904, PROT_READ|PROT_EXEC,MAP_PRIVATE, 3, 0) = 0xb6d9f000
open("/data/data/com.foo.bar/libnetd_client.
so", O_RDONLY) = 4mmap2(NULL, 12904, PROT_READ|PROT_EXEC,
MAP_PRIVATE|MAP_FIXED, 4, 0) = -1 EACCES(Permission denied)
mmap2(NULL, 20,
PROT_READ|PROT_WRITE|PROT_EXEC,
MAP_PRIVATE|MAP_ANONYMOUS, 4, 0) = -1 EACCES(Permission denied)mediaserver - Refactoring
results●Vastly improved architectural
decomposition●

Vastly improved separation of privileges●Riskiest code moved to strongly sandboxedprocess●

Containment model significantly morerobust

https://android-developers.blogspot.com/2016/0
5/hardening-media-stack.html“I started working on this exploit
on a build of the upcoming
Android N release, and anyone
sitting near my desk will testify tothe increased aggravation thiscaused me. A lot of general
hardening work has gone into N,
and the results are impressive.”
Mark Brand
Google Project Zerohttps://googleprojectzero.blogspot.com/2016/09/return-to-libs
tagefright-exploiting.html

Mediaserver hardening effectiveness

Security bulletin bugsin the media stack
for the first 4 monthsof 201723.8%

No longer security issue in N
3.2%

Downgraded severity from M to N
No change between M and N

73.0%

Media Stack Hardening Improvements in O
with
Project Treble

MediaServer

MediaServer

ExtractorService

ExtractorService

MediaCodecService

MediaCodecService

AudioServer
CameraServer
MediaDrmServer

Accessto kernel
drivers

AudioServer

Audio HAL

CameraServer Camera HAL
MediaDrmServer DRM HALAccessto kernel
drivers

Android O:Webview Security

Webview Security

KitKatLollipop

Shipped with theoperating system

Separate APK
updateable via thePlay store

O Preview
Renderer in isolatedprocess
Safe Browsing

Webview Security
AppWebView 1

WebView N

Inter-process boundary

Renderer process
Web content

Linux Kernel

The kernel is the new target for vulnerability research

2014

2015

2016

Security bugs reported to Android by year, broken down between userspace and kernel

Why the rise in kernel bugs?
● Lockdown of userspace makes UID 0 significantly less useful.
● 2016 is the first year > 50% of devices in ecosystem haveselinux in global enforcing.
● Android Vulnerability Rewards: Critical bugs payout more $$$.
○ … and kernel bugs tend to be high or critical severity

How are kernel bugs reached - syscall (before mitigations)

100% of perf vulns
introduced in vendor
customizations

all bugs

bugs reachable by apps
Data: Jan 2014 → April 2016

commit fa1aa143ac4a682c7f5fd52a3cf05f5a6fe44a0a
Author: Jeff Vander Stoep <jeffv@google.com>
Date:

Fri Jul 10 17:19:56 2015 -0400

selinux: extended permissions for ioctls

Add extended permissions logic to selinux. Extended permissions
provides additional permissions in 256 bit increments. Extend thegeneric ioctl permission check to use the extended permissions for
per-command filtering. Source/target/class sets including the ioctl
permission may additionally include a set of commands. Example:

allowxperm <source> <target>:<class> ioctl unpriv_app_socket_cmds
auditallowxperm <source> <target>:<class> ioctl priv_gpu_cmdsMitigations - attack surface reduction
Ioctl command whitelisting in SELinux●Wifi○

Originally hundreds of ioctl commands → 29 whitelisted safe network socket ioctls○

Blocks access to all bugs without restricting legitimate access.

○

Unix sockets: wifi ioctls reachable by local unix sockets :( Hundreds → 8 whitelisted unix socketioctls○●

No ioctls allowed on other socket types including generic and netlink sockets

GPU○e.g. Shamu originally 36 -> 16 whitelisted commands○

Ioctl commands needed varies by device but < 50% needed seems consistent across KGSL drivers

Mitigations - attack surface reduction●●Restrict access to perf○

Access to perf_event_open() is disabled by default.

○

Developers may re-enable access via debug shell

Remove access to debugfs○●All app access to debugfs removed

Remove default access to /sys○

App access to files in /sys must be whitelisted○

38,000 files to 500 files (98% reduction)

Impact of mitigations
Because most bugs are driver specific, effectiveness of mitigations varies acrossdevices. In general most previously reachable bugs were made unreachable●

Case study of bugs reachable by apps on Nexus 6 (Shamu)○

100% of wifi bugs blocked○

50% of GPU bugs blocked○

100% of debugfs bugs blocked○

100% of perf bugs blocked (by default)

SELinux Effectiveness

Reducedseverity

SELinux reduced severity ofalmost half of kernel bugs
(Android security bulletin data for Jan-Apr, 2017)44%

Other Attack Surface Reductions●●

Restricted /proc/PID visibility (hidepid=2, credit CopperheadOS)○

Limit visibility between Android processes○

Prevents popups, notification spam, and phishing○

Addresses UI State Inference attacks

DAC capabilities removal○●

Whitelist of /proc files (new in Android O)○●Kernel module loading, writes to /system, most root capabilities

4400 files -> 2500 files (remainder mostly in /proc/sys/net)

Hardlink removal

Recognition

Good reviews from attackers :-)Q: It might be good for everyone to know: Which Android
devices do you find the most secure?
CunningLogic (aka jcase)Now ~70% of Android devices!

A: Android 5.x and up is particularly annoying for me to try androot, my go to tactics are often dead due to the strengthened
SELinux policies.
https://www.reddit.com/r/Android/comments/3hhciw/ask_us_almost_anything_about_android_security/

Good reviews from attackers :-)https://papers.put.as/papers/macosx/2016/sandbox_defcon.pdf

Second highest exploit cost!

2x increase in exploit cost!

pwn2own
Category

Obtaining Sensitive Information

Install Rogue Application

●

Phone

Price (USD)“Master of Pwn”
PointsApple iPhone$50,000

10

Google Nexus$50,000

10

Other Android$35,000

7

Apple iPhone$125,00023

Google Nexus$100,000

20

Other Android$60,000

15

http://blog.trendmicro.com/presenting-mobile-pwn2own-2016/

pwn2own●Price parity among the major

Phone

Price (USD)

Apple iPhone$50,000

Google Nexus$50,000

Other Android$35,000

Apple iPhone$125,000

Google Nexus$100,000

Other Android$60,000

mobile operating systems●Smaller attack surface increases
complexity and cost of finding anexploit

pwn2own successes
ContestCore Android
Platform Bug

Additional Notes

2009 pwn2own

NO

All mobile devices unexploited

2010 pwn2own

NO

iPhone 3GS compromised. No Android compromised

2011 pwn2own

NO

Google Stays Strong

2012 pwn2own

NO

Non-Android device specific parsing bug - NFC delivered

2013 pwn2own

NO

Non-Android device specific bug

2014 pwn2own

YES

1.
2.

2015 pwn2own

NO

Chrome exploit -> Google Play Install - No OS compromise

2016 pwn2own

NO

Chrome exploit -> Google Play Install - No OS compromise

NFC triggered remote leak of Bluetooth MAC address
DHCP code execution (partial win)No success from the Project Zero prize

http://www.zdnet.com/article/didnt-we-offer-you-enough-googles-350000-project-zero-prize-attracts-junk-entries/

Accelerating bug discovery

https://www.extremetech.com/mobile/250316-google-increases-android-bug-bounties-much-200000

“... no researcher has claimed the top reward for anexploit chains in 2 years ...”Old AmountNew AmountRemote chain toTrustZone or Verified
Boot compromise$50,000$200,000

Remote to Kernel$30,000$150,000

https://security.googleblog.com/2017/06/2017-android-security-rewards.html

Wikileaks: CIA Hacking Tools Revealed“Furthermore, when SELinux became common onAndroid, this became more problematic since theradio SELinux context that rild started with was too
restrictive for the implant to function.”

https://wikileaks.org/ciav7p1/cms/page_28049453.html

FutureFuture: Global Seccomp Whitelist

Architecturesyscalls provided bysyscalls in bionickernelreduction (%)

arm364204

44

arm64271

198

27x86373203

46x86_64

326

199

39

Future Attack Surface Reduction●

Take better advantage of Treble - system / vendor split●

Continued reduction in /proc files●

Removal of useless /dev files○

Faster boot time, less kernel code, less attack surface●

Stronger IPC controls●

System Properties●

Finer grain attack surface reduction for applications●

Scale back shared data stores

Takeaways

Takeaways●Attack surface management is critical to preventing or mitigating
unknown bugs.

●Android has invested significantly in reducing attack surface andcontaining processes.

●Vulnerabilities will never go away, but they can be contained andmanaged.

“Perfection is achieved not when
there is nothing more to add, butwhen there is nothing left to takeaway.”- Antoine de Saint-Exupery - 1939

THANK YOU
security@android.com

Nick Kralevich
nnk@google.com