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, 2012CSW 20122

Evolution Smartphones (SPs) are increasingly powerful – In some cases, can functionally replace PCs – , 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, 2012CSW 20123

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, 2012CSW 20124

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, 2012CSW 20125

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, 2012CSW 20126

Misaligned Interests YouProvider 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 phoneWants to charge extra for tethering Want to unlock SIMWants to lock phone to network Phone is loss-leader Customer churn is bad Phone exclusivity is valuable Want to overclockWants to charge more for un-throttling Want to install custom basebandWants to protect/control cellular network Want to remove CarrierIQ??? (ask Trevor ) March 8, 2012CSW 20127

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, 2012CSW 20128

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, 2012CSW 20129

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, 2012CSW

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, 2012CSW

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, 2012CSW

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, 2012CSW

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, 2012CSW

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, 2012CSW

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 March 8, 2012CSW

SP Architecture (2) March 8, 2012CSW

SP Architecture (3) March 8, 2012CSW

SP Architecture (4) March 8, 2012CSW

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, 2012CSW

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 n.html n.html – P(bugs|32MB) >> 0? Seems highly likely. March 8, 2012CSW

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, 2012CSW

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, 2012CSW

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, 2012CSW

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, 2012CSW

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: March 8, 2012CSW

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: March 8, 2012CSW

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, 2012CSW

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, 2012CSW

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, 2012CSW

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 – – Replace flash chip (modchip) – Others? March 8, 2012CSW

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, 2012CSW

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, 2012CSW

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 – Secure boot FAIL. March 8, 2012CSW

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, 2012CSW

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, 2012CSW

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, 2012CSW

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: March 8, 2012CSW

IE Vulnerabilities March 8, 2012 Source: approach CSW

Chrome looks no better March 8, 2012 Source: approach CSW

What about Firefox? March 8, 2012 Source: approach CSW

Browser Vulnerability Summary March 8, 2012 Source: approach CSW

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: March 8, 2012CSW

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, 2012CSW

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, 2012CSW

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. – 3 rd party providers need secure platform DRM, NFC, wallet apps, etc. – Malware is going to become a problem March 8, 2012CSW

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 March 8, 2012CSW

Trusted Execution Environment March 8, 2012CSW

Global Platform Vision of TEE March 8, 2012CSW Source:GlobalPlatform_TEE_White_Paper_Feb2011.pdf

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, 2012CSW

Hardware TEE Example March 8, 2012CSW

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, 2012CSW *copied from “TrustZone: Integrated Hardware and Software Security”, Information Quarterly, Volume 3, Number 4, 2004

TrustZone Hardware Example March 8, 2012CSW Source: ARM, PRD29-GENC C_trustzone_security_whitepaper.pdf

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, 2012CSW

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, 2012CSW

Current TEE Implementations Rapidly gaining momentum – Texas Instruments M-Shield – ST-Ericsson – NVIDIA Tegra2 – Marvell – Motorola – Intel (GTV, etc.) – Others GP membership is growing – ll.asp ll.asp March 8, 2012CSW

Remember this? March 8, 2012CSW

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, 2012CSW

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, 2012CSW

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, 2012CSW

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 – March 8, 2012CSW

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, 2012CSW

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, 2012CSW

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, 2012CSW This one?

Hypothetically… (3) Unfortunately, no one can be told what The Matrix is. You have to see it for yourself. Blue pill, anyone? March 8, 2012CSW

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, 2012CSW

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, 2012CSW

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, 2012CSW

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, 2012CSW