Root-proof Smartphones
and
Other Myths and Legends
Scott G. Kelly
March 8, 2012
CanSecWest 2012
Agenda
• Smartphone tug of war
– Why we want control
– Why providers want control
• The struggle for control
– Rooting/jailbreaking
– Provider responses
– How/why of provider control failures
• New security technologies
– What they are, how they work
– Some potential implications
March 8, 2012
CSW 2012
2
Evolution
• Smartphones (SPs) are increasingly powerful
– In some cases, can functionally replace PCs
– Email, web, video, etc.
• But SPs and PCs differ in at least one subtle
and important way:
– By design, SP is multi-tenant environment; PC is
not
March 8, 2012
CSW 2012
3
What’s a multi-tenant environment?
• Computing environment where
– Hardware/resources are shared
– among multiple stakeholders
– whose interests not necessarily aligned
• Cloud service (Amazon EC2) is good example
– Provider: Amazon
– Hardware: shared server, storage, network
– Tenants
• Provider + VMs
• VM owners may be mutually suspicious
• At least 2 tenants: Amazon + VM owner
March 8, 2012
CSW 2012
4
PCs are single-tenant*
• PC manufacturer may have configured system certain
way, but…
• You are free to change it
–
–
–
–
–
Add hardware
Replace OS
Replace pieces of OS
Install/remove applications
Etc.
*Enterprise PC or home PC with multiple users is multi-tenant, but to much
lesser degree than cloud example, and in different way than SP
March 8, 2012
CSW 2012
5
SP has >=2 tenants
• Tenant 1
– Service provider*
– Similar to cloud provider example above
• Tenant 2
– SP user (you)
– Like VM owner in EC2 example
• DOH! But I OWN my SP, right?
– Well… sort of.
– Depends on what you mean by “own”
March 8, 2012
CSW 2012
6
Misaligned Interests
You
Provider
Want to customize
• Install custom “ROM”
• Install “unauthorized” apps
• Remove/replace “bloatware”
Wants “Brand control”
• Fixed OS
• Limit/control app sources
• Pre-installed, undeletable apps
Want to tether phone
Wants to charge extra for tethering
Want to unlock SIM
Wants to lock phone to network
• Phone is loss-leader
• Customer churn is bad
• Phone exclusivity is valuable
Want to overclock
Wants to charge more for un-throttling
Want to install custom baseband
Wants to protect/control cellular network
Want to remove CarrierIQ
??? (ask Trevor )
March 8, 2012
CSW 2012
7
Whose pwn is it, anyway?
• Technically, it is yours.
• As a practical matter (more often than not),
that’s an illusion.
• Why?
– Because you got it from the provider.
– And the provider designed/configured the phone
to maintain control.
– smart pwn.
• Solution: “rooting”/”jailbreaking”
March 8, 2012
CSW 2012
8
Rooting
• Basically, two ways to root phone:
1. Install new firmware image (“rom”) using built-in
firmware update facility
2. Exploit a system vulnerability, overwrite/replace
firmware image*
• The first way works if providers don’t prevent it
– But providers are implementing barriers
• In fact, barriers may become the norm
– So, some phones require sploitz
March 8, 2012
CSW 2012
9
SP Architecture Overview
• To understand rooting barriers, we need some
background
• Following is a brief overview in two parts
– Embedded systems architecture
– Modern SP architecture
• Once we have that background, we can come
back to attacker/defender discussion
March 8, 2012
CSW 2012
10
Embedded Systems 101
• Embedded systems
generally include
– NAND/NOR Flash
• non-volatile memory in
which firmware is stored
– CPU/MCU
• processor for OS/apps
– DRAM
• random access memory
(just like your PC)
– Interfaces
• Wifi, ethernet, etc.
March 8, 2012
CSW 2012
11
Embedded Systems 101 (2)
• At power-on
– Processor comes out of reset
– Begins running code from
flash*
• Boot Loader (BL) is typically
first code to run
• BL initializes HW (memory,
etc.)
• BL usually copies itself into
DRAM before continuing
March 8, 2012
CSW 2012
12
Embedded Systems 101 (3)
• BL continues hardware
initialization from
DRAM
• BL validates, loads, and
jumps into OS
• OS finishes init, goes to
runtime steady state
March 8, 2012
CSW 2012
13
Terminology
• SoC
– A System on Chip packages all or most necessary system
elements into a single Integrated Circuit (IC) package
• Application CPU/processor/core
– SPs typically utilize a multi-core SoC. The application
CPU runs the user interface and apps
• Baseband processor
– The baseband (aka modem/radio) processor handles
cellular communications.
March 8, 2012
CSW 2012
14
Terminology (2)
• System firmware
– Collection of system code controlled by provider
• System image
– System firmware and file systems are packaged for
distribution.
• OTP/eFuse
– One Time Programmable memory, typically
implemented with eFuse technology
March 8, 2012
CSW 2012
15
SP Architecture (1)
• Embedded systems are all
around us
– Variations depending on
application
• But core components are
essentially the same
–
–
–
–
CPU(s)
NVRAM
DRAM
I/O
• And so are development
procedures
http://wiki.openmoko.org/wiki/Neo_FreeRunner_Hardware
March 8, 2012
CSW 2012
16
SP Architecture (2)
March 8, 2012
CSW 2012
17
SP Architecture (3)
http://www.arm.com/images/processor/Mobile_Computing_Diagram_550.jpg
March 8, 2012
CSW 2012
18
SP Architecture (4)
http://www.ti.com/general/docs/wtbu/wtbuproductcontent.tsp?templateId=6123&navigationId=12843&contentId=53243
March 8, 2012
CSW 2012
19
Important Observations
• SPs have multiple processors/cores
– application processor (may be SMP)
– Baseband (a.k.a. modem) processor
– Others
• These cores run distinct instruction streams
– They are not all controlled by the OS that is running on the
application processor (and they are not all running the
same OS)
– What resources they share (e.g. memory, buses, etc.) are
design choices that may or may not be informed by
security concerns
March 8, 2012
CSW 2012
20
Important Observations (cont.)
• Inter-processor communication requires
protocols, interconnects, protocol handlers, etc.
– These are all part of the system attack surface
• The complexity of the code running on the
baseband and other cores is a design choice
– QCOM MSM6280 runs 32MB+ of code on baseband
• http://events.ccc.de/congress/2011/Fahrplan/events/4735.e
n.html
• http://tjworld.net/wiki/Android/HTC/Vision/RadioAnalysis
– P(bugs|32MB) >> 0? Seems highly likely.
March 8, 2012
CSW 2012
21
Going back…
• So, how did that first approach to rooting work,
again?
– SPs support firmware upgrade
• Firmware is stored in flash
– Provider (or someone) creates image file
– Image is delivered to SP
•
•
•
•
OTA (over the air)
OTN (over the network)
SD/MMC (download)
USB (fastboot)
– write new image to flash
March 8, 2012
CSW 2012
22
Image upgrades (2)
• To use the first approach, need to
– Reverse engineer image format
– Assemble tool chain, source code*
– Recreate working facsimile of system image, with
your mods added
• NOTE: can re-use binary pieces of existing images (!)
– Construct new image file
– Flash new image
March 8, 2012
CSW 2012
23
Why the second rooting method?
• Providers often want to ensure that only
authorized images run on SPs
– Initially, some assumed that creating a firmware
image is sufficiently “hard”
• Security through obscurity
• But they were wrong.
– Many available “roms”, “rom kitchens”, etc. prove this
is not hard
• Plan B: implement secure boot
March 8, 2012
CSW 2012
24
Secure Boot?
• Put simply, means that only authorized (system)
code runs
• If image is corrupted, or you try to install your
own (unauthorized) code, system will not run.
• Neat! Why don’t they have that for Windows yet?
– D’oh! UEFI is coming.
– But that’s another presentation.
March 8, 2012
CSW 2012
25
Secure Boot Overview
• Based on “chain of
trust”
• Requires trusted root
– Trusted code (RoT) with
ability to verify next link
in chain
• Verification mechanism
– Typically, digital
signatures
– Public key(s) protected
(in ROM/OTP)
March 8, 2012
Source: www.trustedcomputinggroup.org
CSW 2012
26
Secure Boot Overview (2)
• Chain of trust, cont.
– RoT verifies BL
– BL verifies kernel, rootfs
– Kernel may be configured
to validate applications
(e.g., iOS)
• Trick is to ensure public
keys are protected
• Can use multiple public
keys:
– BL key is in ROM/OTP
– Kernel key is in BL
– rootfs key is in kernel/BL
Source: www.trustedcomputinggroup.org
March 8, 2012
CSW 2012
27
Is this “bootloader locking”?
• Bootloader locking is a form of secure boot
– Protects against bootloader replacement
– Ensures that bootloader policy is applied to kernel
• Bootloader locking typically prevents you from
“flashing a rom” – it prevents full image
replacement.*
• So, how does this “locking” work?
March 8, 2012
CSW 2012
28
BL Locking
• Multiple approaches to locking*
– Permanently write-protect bootloader (e.g. by
storing it in ROM, or read-only flash)
– Require signed bootloader (IPL code in ROM
verifies/loads)
– Have some system element assert wp on BL flash
sector during boot process
• Multiple HTC/QCOM phones have been known to do
this
• Baseband asserts wp on EMMC during boot
March 8, 2012
CSW 2012
29
Subverting BL Locking
• If bootloader is signed
– If symmetric key is used, may be able to obtain this
key somehow (examples to follow)
– If public key can be replaced, you can load your own
image
• This implies a fundamental security implementation error
• SoC vendors typically know better
– If bootloader is verified in flash and then loaded into
DRAM, a hardware attack is possible (let check
succeed, then substitute your BL)
– Voltage glitching may cause bogus BL to seem “valid”
March 8, 2012
CSW 2012
30
Subverting BL Locking (2)
• If dynamic write-protect scheme is used
– Defeat write-protect
• By preventing wp operation from completing
• By undoing wp operation after the fact
– Mutliple HTC phones have fallen to this approach
– Power-cycling EMMC resets WP
– http://forum.xda-developers.com/wiki/HTC_Vision
– Replace flash chip (modchip)
– Others?
March 8, 2012
CSW 2012
31
Subverting BL Locking (3)
• Uh…
– Hardware attacks?
– Timing attacks?
– Glitching?
• Isn’t there an easier way!?
– Good question.
– Lazy attackers work smart, look for weak links in chain
– Hmmm….
March 8, 2012
CSW 2012
32
Finding a weak link
• ROM loads bootloader
• Bootloader loads Linux
• Linux loads
–
–
–
–
UI
Network drivers
Browser
Apps
• Boot process looks secure
• Or is it?
March 8, 2012
CSW 2012
33
GTV recovery example
• Sony GTV supports a “recovery” kernel
• Earlier version contained a subtle flaw
– ls /tmp/mnt/diskb1/package_list_*.zip | head -1 | grep
"package_list_”
– Attacker controls filename (package_list_*.zip)!
– “package_list_;cd /tmp;cd /mnt;cd /diskb1;sh t.sh;.zip” allows exec of
t.sh on USB (D’OH!)
– Game over.
• TOCTTOU flaw allows downgrade
– http://gtvhacker.com
• Secure boot FAIL.
March 8, 2012
CSW 2012
34
Weak Validation examples
• Asus SBK
– Asus EEE Transformer Tablet uses symmetric AES key to validate
bootloader, image (SBK)
– Key is well protected within system, but it was leaked by
someone with access (they since changed SBK)
– Secure boot FAIL.
• Samsung CMAC key
– Various Samsung DTV/BDP devices use symmetric key to
validate bootloader, image
– Key is not well protected within system
– Attackers root device, directly read key.
– Secure boot FAIL.
March 8, 2012
CSW 2012
35
Attacking runtime system
• Even if secure boot method is robust, can still
attack runtime
– More features == more complexity
– More complexity == more bugs
– More bugs == more opportunity for sploitz
• So, how to find the openings?
March 8, 2012
CSW 2012
36
Attack Surface Analysis
• Need to do some recon
– Figure out what’s running
– Determine distribution of
security bugs in code
– Each interface is an entry
point
– Each entry point exposes code
paths, data
– Find path to exploitable bug
• Need to craft inputs in
such a way as to gain
control of the system
March 8, 2012
CSW 2012
37
Reconnaissance: Linux
140
• Publicly reported Linux
vulnerabilities for last 12+
years
–
–
–
–
2011: 85
2010: 125
2009: 100
(etc).
• Many of these yield full
control of the system
120
100
80
60
40
• This looks promising.
20
Source: http://www.cvedetails.com
0
1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011
March 8, 2012
CSW 2012
38
IE Vulnerabilities
Source: http://www.accuvant.com/capability/accuvant-labs/security-research/browser-security-comparison-quantitativeapproach
March 8, 2012
CSW 2012
39
Chrome looks no better
Source: http://www.accuvant.com/capability/accuvant-labs/security-research/browser-security-comparison-quantitativeapproach
March 8, 2012
CSW 2012
40
What about Firefox?
Source: http://www.accuvant.com/capability/accuvant-labs/security-research/browser-security-comparison-quantitativeapproach
March 8, 2012
CSW 2012
41
Browser Vulnerability Summary
Source: http://www.accuvant.com/capability/accuvant-labs/security-research/browser-security-comparison-quantitativeapproach
March 8, 2012
CSW 2012
42
Webkit/Opera public stats
• Apple Webkit vulnerabilities*
– 2010: 94 (code execution >= 63)
– 2011: 112 (code execution >= 96)
• Opera Browser vulnerabilities*
– 2009: 16 (code execution >= 1)
– 2010: 36 (code execution >= 5)
– 2011: 56 (code execution >= 4)
Source: http://www.cvedetails.com
March 8, 2012
CSW 2012
43
Promising avenue: runtime
• Why?
– OS’s have vulnerabilities
• Function of complexity,
number of contributors,
engineering decisions
– So do browsers/webkit
– App support
• Android apps can include
*.so (!!)
March 8, 2012
CSW 2012
44
Surprise!
Wait:
– The SP correctly implements secure boot, but I can
still root it?
– And if I can configure the exploit to run at boot time,
this is persistent!
– Woohoo!
• The only way this can be fixed is if
– Provider forces an OTA update*, or
– You voluntarily download/install an update, and
– Provider can (forcibly) prevent rollback
March 8, 2012
CSW 2012
45
So, what will they do?
• The industry is struggling with this
• Things working against solution
– SP ecosystem complexity
– Vocal rooting community
– Solution cost
• Things creating solution pressure
– Providers want to prevent SIM unlocking, cloning, etc.
– 3rd party providers need secure platform
• DRM, NFC, wallet apps, etc.
– Malware is going to become a problem
March 8, 2012
CSW 2012
46
Emerging Solutions
• Google’s (rumored) initiatives
–
–
–
–
Lock down *.so usage
Add capabilities/LSM protections
Up to date patching strategy
All are helpful, but losing battle given provider mods?
• Trusted Computing Group (TCG) has been working on
Mobile Trust Module (MTM)
• Global Platform has been working on Trusted Execution
Environment (TEE) definitions/specifications
www.trustedcomputingroup.org, www.globalplatform.org
March 8, 2012
CSW 2012
47
Trusted Execution Environment
March 8, 2012
CSW 2012
48
Global Platform Vision of TEE
Source:GlobalPlatform_TEE_White_Paper_Feb2011.pdf
March 8, 2012
CSW 2012
49
Numerous ways to implement TEE
• Multiple cores (hardware TEE)
– Sensitive operations run on “security” core
– Security core controls (and isolates)
•
•
•
•
OTP/keys
Secure on-chip RAM
Crypto operations/processor
Secure boot, firmware integrity protection
– Application core runs untrusted code (e.g. UI,
Android)
March 8, 2012
CSW 2012
50
Hardware TEE Example
March 8, 2012
CSW 2012
51
Numerous Ways to Implement TEE (2)
•
With ARM TrustZone™
– Normal/secure world
abstraction supported by
hardware
– sensitive operations run in
“secure world”
– secure world controls (and
isolates)
• OTP/keys and related crypto ops
• internal SRAM
• Other critical assets
*copied from “TrustZone: Integrated Hardware and Software Security”,
Information Quarterly, Volume 3, Number 4, 2004
– “normal world” runs untrusted
code
March 8, 2012
CSW 2012
52
TrustZone Hardware Example
Source: ARM, PRD29-GENC-009492C_trustzone_security_whitepaper.pdf
March 8, 2012
CSW 2012
53
Numerous Ways to Implement TEE (3)
• Virtualization
– secure boot
– robust hypervisor
– MMU/MPU under hypervisor
control
– functionally equivalent to HW TEE,
TrustZone
• Hypervisor + MMU/MPU enforces
isolation of sensitive
operations/keys
March 8, 2012
CSW 2012
54
Numerous Ways to Implement TEE (4)
•
Software TEE
– Challenge is in providing effective
isolation between trusted and
untrusted elements
– Tools that can help:
•
•
•
•
rigorous obfuscation techniques
white-box cryptography
anti-debugging techniques
runtime tampering/integrity
checks
• policy/containment framework
(e.g. SELinux, grsecurity)
•
Can always be defeated with
enough time/effort
•
Don’t know of any real-world SP
examples*
March 8, 2012
CSW 2012
55
Current TEE Implementations
• Rapidly gaining momentum
–
–
–
–
–
–
–
Texas Instruments M-Shield
ST-Ericsson
NVIDIA Tegra2
Marvell
Motorola
Intel (GTV, etc.)
Others
• GP membership is growing
– http://www.globalplatform.org/membershipcurrentfu
ll.asp
March 8, 2012
CSW 2012
56
Remember this?
March 8, 2012
CSW 2012
57
TEE is the future for SP
• ARM has significant lead in this market
• Many (most?) SPs have ARM processors in
them already (including iPhone!)
• Turning on TZ is a no-brainer for many SP
providers
• Primary barriers are cost/complexity
– But this should scale as TZ gets traction
March 8, 2012
CSW 2012
58
TEE/shmee
140
• Even with a robust TEE and
secure boot, rooting can’t
be stopped.
120
100
80
60
– “There is no spoon.”
40
20
• As long as there are system
vulnerabilities, control is up
for grabs
0
1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011
• And this is really difficult to
“fix” (impossible?)
March 8, 2012
CSW 2012
59
What prevents a fix?
• Fundamental problem
– Vulnerabilities are a given
– Ecosystem does not facilitate patching
• Fragmentation  not enough security experts
• Carrier certification requirements have scaling implications
• Not always clear who’s on the hook (Google? Apple? IC
vendor? Handset manufacturer? Carrier?)
• Result
– Sploitz have potentially long lifetime
March 8, 2012
CSW 2012
60
Providers and Rooting
• Providers have mixed feelings about this
– Allowing rooting makes them more popular
– With TEE, it doesn’t really hurt anything
– Malware might change things
• If malware is using sploit, providers will need to
respond
• One possible answer: A/V in TEE
• HTC explicitly supports unlocking
– http://htcdev.com/bootloader
March 8, 2012
CSW 2012
61
Other implications
• Probably would have ended here, but Carrier IQ
raised some interesting questions
• Providers’ and users’ interests are often not
aligned
• Providers may want access/control that users
would rather not cede
• What are implications of TEE?
March 8, 2012
CSW 2012
62
Hypothetically…
• Unlockable HTC phones are based on QC
SnapDragon
– Supports TrustZone
• Is TZ disabled when BL is unlocked?
• What if it’s not?
March 8, 2012
CSW 2012
63
Hypothetically… (2)
• Boot process starts in TZ
• HTC said they are
unlocking bootloader
My bet is here
• But they didn’t say which
bootloader.
This one?
• “Perhaps we are asking
the wrong questions.”
– Agent Brown
March 8, 2012
CSW 2012
64
Hypothetically… (3)
• Unfortunately, no one can be told what The Matrix
is. You have to see it for yourself.
• Blue pill, anyone?
March 8, 2012
CSW 2012
65
Paranoia?
• You decide:
– Provider has strong
incentives to maintain
control
– Secure world code may
be encrypted
– Normal world cannot
see secure world*
Provider has
complete control
over this
• What if CarrierIQ were
in the secure world?
March 8, 2012
CSW 2012
66
Winds of Change
• We are gradually ceding control of our computing
devices
• Many (most?) users don’t yet see this as an issue
• Recent Win8/ARM/UEFI flap should give us pause
• If we don’t resist, invasive provider controls may
become De facto standard
“Do you hear that Mr. Anderson? That is the sound of inevitability.”
–Agent Smith
March 8, 2012
CSW 2012
67
Some Observations
• Without oversight, providers are
not accountable
– Regulation might help, but is not a
panacea
• Some consolation
– TEEs complexity will lead to bugs
• TEE sploitz will happen.
– TEE reversing may provide our only
insights into some of these devices
– H/W attacks are also possible (by
those with skilz)
• Openmoko suddenly looks a lot
more appealing.
March 8, 2012
CSW 2012
68
Parting Thoughts
• Matrix Preloaded?
– TEE provides ability to bare-metal virtualize
Application OS (AOS)
– From safety of TEE, “agent” can monitor/modify AOS
– Naïve implementations will not be “aware” of agent
– With UEFI, this extends to the PC
– Quis custodiet ipsos custodes?
• Red pill, please.
March 8, 2012
CSW 2012
69