69
Root-proof Smartphones and Other Myths and Legends Scott G. Kelly March 8, 2012 CanSecWest 2012

Root-proof Smartphones

  • Upload
    tyanne

  • View
    25

  • Download
    1

Embed Size (px)

DESCRIPTION

Root-proof Smartphones. a nd 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 - PowerPoint PPT Presentation

Citation preview

Page 1: Root-proof Smartphones

Root-proof Smartphonesand

Other Myths and Legends

Scott G. KellyMarch 8, 2012CanSecWest 2012

Page 2: Root-proof Smartphones

CSW 2012 2

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

Page 3: Root-proof Smartphones

CSW 2012 3

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

Page 4: Root-proof Smartphones

CSW 2012 4

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

Page 5: Root-proof Smartphones

CSW 2012 5

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

Page 6: Root-proof Smartphones

CSW 2012 6

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

Page 7: Root-proof Smartphones

CSW 2012 7

Misaligned InterestsYou 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

Page 8: Root-proof Smartphones

CSW 2012 8

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

Page 9: Root-proof Smartphones

CSW 2012 9

Rooting

• Basically, two ways to root phone:1. Install new firmware image (“rom”) using built-in

firmware update facility2. 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

Page 10: Root-proof Smartphones

CSW 2012 10

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

Page 11: Root-proof Smartphones

CSW 2012 11

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

Page 12: Root-proof Smartphones

CSW 2012 12

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

Page 13: Root-proof Smartphones

CSW 2012 13

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

Page 14: Root-proof Smartphones

CSW 2012 14

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

Page 15: Root-proof Smartphones

CSW 2012 15

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

Page 16: Root-proof Smartphones

CSW 2012 16

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

Page 17: Root-proof Smartphones

CSW 2012 17

SP Architecture (2)

March 8, 2012

Page 18: Root-proof Smartphones

CSW 2012 18

SP Architecture (3)

March 8, 2012

http://www.arm.com/images/processor/Mobile_Computing_Diagram_550.jpg

Page 19: Root-proof Smartphones

CSW 2012 19

SP Architecture (4)

March 8, 2012

http://www.ti.com/general/docs/wtbu/wtbuproductcontent.tsp?templateId=6123&navigationId=12843&contentId=53243

Page 20: Root-proof Smartphones

CSW 2012 20

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

Page 21: Root-proof Smartphones

CSW 2012 21

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.en.html• http://tjworld.net/wiki/Android/HTC/Vision/RadioAnalysis

– P(bugs|32MB) >> 0? Seems highly likely.

March 8, 2012

Page 22: Root-proof Smartphones

CSW 2012 22

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

Page 23: Root-proof Smartphones

CSW 2012 23

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

Page 24: Root-proof Smartphones

CSW 2012 24

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

Page 25: Root-proof Smartphones

CSW 2012 25

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

Page 26: Root-proof Smartphones

CSW 2012 26

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) Source: www.trustedcomputinggroup.org

March 8, 2012

Page 27: Root-proof Smartphones

CSW 2012 27

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

Page 28: Root-proof Smartphones

CSW 2012 28

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

Page 29: Root-proof Smartphones

CSW 2012 29

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

Page 30: Root-proof Smartphones

CSW 2012 30

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

Page 31: Root-proof Smartphones

CSW 2012 31

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

Page 32: Root-proof Smartphones

CSW 2012 32

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

Page 33: Root-proof Smartphones

CSW 2012 33

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

Page 34: Root-proof Smartphones

CSW 2012 34

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

Page 35: Root-proof Smartphones

CSW 2012 35

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

Page 36: Root-proof Smartphones

CSW 2012 36

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

Page 37: Root-proof Smartphones

CSW 2012 37

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

Page 38: Root-proof Smartphones

CSW 2012 38

Reconnaissance: Linux• Publicly reported Linux

vulnerabilities for last 12+ years– 2011: 85– 2010: 125– 2009: 100– (etc).

• Many of these yield full control of the system

• This looks promising.

Source: http://www.cvedetails.com

March 8, 2012

1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 20110

20

40

60

80

100

120

140

Page 39: Root-proof Smartphones

CSW 2012 39

IE Vulnerabilities

March 8, 2012

Source: http://www.accuvant.com/capability/accuvant-labs/security-research/browser-security-comparison-quantitative-approach

Page 40: Root-proof Smartphones

CSW 2012 40

Chrome looks no better

March 8, 2012

Source: http://www.accuvant.com/capability/accuvant-labs/security-research/browser-security-comparison-quantitative-approach

Page 41: Root-proof Smartphones

CSW 2012 41

What about Firefox?

March 8, 2012

Source: http://www.accuvant.com/capability/accuvant-labs/security-research/browser-security-comparison-quantitative-approach

Page 42: Root-proof Smartphones

CSW 2012 42

Browser Vulnerability Summary

March 8, 2012

Source: http://www.accuvant.com/capability/accuvant-labs/security-research/browser-security-comparison-quantitative-approach

Page 43: Root-proof Smartphones

CSW 2012 43

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

Page 44: Root-proof Smartphones

CSW 2012 44

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

Page 45: Root-proof Smartphones

CSW 2012 45

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

Page 46: Root-proof Smartphones

CSW 2012 46

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

Page 47: Root-proof Smartphones

CSW 2012 47

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

Page 48: Root-proof Smartphones

CSW 2012 48

Trusted Execution Environment

March 8, 2012

Page 49: Root-proof Smartphones

CSW 2012 49

Global Platform Vision of TEE

March 8, 2012

Source:GlobalPlatform_TEE_White_Paper_Feb2011.pdf

Page 50: Root-proof Smartphones

CSW 2012 50

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

Page 51: Root-proof Smartphones

CSW 2012 51

Hardware TEE Example

March 8, 2012

Page 52: Root-proof Smartphones

CSW 2012 52

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

– “normal world” runs untrusted code

March 8, 2012

*copied from “TrustZone: Integrated Hardware and Software Security”, Information Quarterly, Volume 3, Number 4, 2004

Page 53: Root-proof Smartphones

CSW 2012 53

TrustZone Hardware Example

March 8, 2012

Source: ARM, PRD29-GENC-009492C_trustzone_security_whitepaper.pdf

Page 54: Root-proof Smartphones

CSW 2012 54

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

Page 55: Root-proof Smartphones

CSW 2012 55

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

Page 56: Root-proof Smartphones

CSW 2012 56

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/membershipcurrentfull.asp

March 8, 2012

Page 57: Root-proof Smartphones

CSW 2012 57

Remember this?

March 8, 2012

Page 58: Root-proof Smartphones

CSW 2012 58

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

Page 59: Root-proof Smartphones

CSW 2012 59

TEE/shmee• Even with a robust TEE and

secure boot, rooting can’t be stopped.– “There is no spoon.”

• As long as there are system vulnerabilities, control is up for grabs

• And this is really difficult to “fix” (impossible?)

March 8, 2012

1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 20110

20

40

60

80

100

120

140

Page 60: Root-proof Smartphones

CSW 2012 60

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

Page 61: Root-proof Smartphones

CSW 2012 61

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

Page 62: Root-proof Smartphones

CSW 2012 62

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

Page 63: Root-proof Smartphones

CSW 2012 63

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

Page 64: Root-proof Smartphones

CSW 2012 64

Hypothetically… (2)• Boot process starts in TZ

• HTC said they are unlocking bootloader

• But they didn’t say which bootloader.

• “Perhaps we are asking the wrong questions.”

– Agent Brown

My bet is here

March 8, 2012

This one?

Page 65: Root-proof Smartphones

CSW 2012 65

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

Page 66: Root-proof Smartphones

CSW 2012 66

Paranoia?

• You decide:– Provider has strong

incentives to maintain control

– Secure world code may be encrypted

– Normal world cannot see secure world*

• What if CarrierIQ were in the secure world?

Provider has complete control over this

March 8, 2012

Page 67: Root-proof Smartphones

CSW 2012 67

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

Page 68: Root-proof Smartphones

CSW 2012 68

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

Page 69: Root-proof Smartphones

CSW 2012 69

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