1. Root-proof Smartphones and Other Myths and Legends Scott G. Kelly March 8, 2012 CanSecWest 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, 2012CSW 20122

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

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

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

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

7. 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

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

9. 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

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

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

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

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

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

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

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

17. SP Architecture (2) March 8, 2012CSW 201217

18. SP Architecture (3) March 8, 2012CSW 201218 http://www.arm.com/images/processor/Mobile_Computing_Diagram_550.jpg

19. SP Architecture (4) March 8, 2012CSW 201219 http://www.ti.com/general/docs/wtbu/wtbuproductcontent.tsp?templateId=6123&navigationId=12843&contentId=53243

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

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.e n.html 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, 2012CSW 201221

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

39. IE Vulnerabilities March 8, 2012 Source: http://www.accuvant.com/capability/accuvant-labs/security-research/browser-security-comparison-quantitative- approach CSW 201239

40. Chrome looks no better March 8, 2012 Source: http://www.accuvant.com/capability/accuvant-labs/security-research/browser-security-comparison-quantitative- approach CSW 201240

41. What about Firefox? March 8, 2012 Source: http://www.accuvant.com/capability/accuvant-labs/security-research/browser-security-comparison-quantitative- approach CSW 201241

42. Browser Vulnerability Summary March 8, 2012 Source: http://www.accuvant.com/capability/accuvant-labs/security-research/browser-security-comparison-quantitative- approach CSW 201242

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

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

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

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

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.orgwww.trustedcomputingroup.org, www.globalplatform.orgwww.globalplatform.org March 8, 2012CSW 201247

48. Trusted Execution Environment March 8, 2012CSW 201248

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

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

51. Hardware TEE Example March 8, 2012CSW 201251

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

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

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

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

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/membershipcurrentfu ll.asp http://www.globalplatform.org/membershipcurrentfu ll.asp March 8, 2012CSW 201256

57. Remember this? March 8, 2012CSW 201257

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

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

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

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 http://htcdev.com/bootloader March 8, 2012CSW 201261

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

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

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

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

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

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

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

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