Root-proof Smartphones

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

4. What’s a multi-tenant environment? • Computing environmentwhere • 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 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 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” CSW 2012

7. Misaligned Interests 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” CSW 2012

9. Rooting • Basically, two ways to root phone: • Install new firmware image (“rom”) using built-in firmware update facility • 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 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 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. 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 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 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. 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 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 CSW 2012

17. SP Architecture (2) CSW 2012

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

19. SP Architecture (4) http://www.ti.com/general/docs/wtbu/wtbuproductcontent.tsp?templateId=6123&navigationId=12843&contentId=53243 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 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. 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 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 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 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. CSW 2012

26. Secure Boot Overview • Based on “chain of trust” • Requires trusted root • Trusted code (RoT) withability to verify next link in chain • Verification mechanism • Typically, digital signatures • Public key(s) protected (in ROM/OTP) Source: www.trustedcomputinggroup.org 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 • rootfskey is in kernel/BL Source: www.trustedcomputinggroup.org 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? 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 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” 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? 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…. 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? 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. 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. 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? 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 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 CSW 2012

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

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

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

42. Browser Vulnerability Summary Source: http://www.accuvant.com/capability/accuvant-labs/security-research/browser-security-comparison-quantitative-approach 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 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 (!!) 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 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 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 CSW 2012

48. Trusted Execution Environment CSW 2012

49. Global Platform Vision of TEE Source:GlobalPlatform_TEE_White_Paper_Feb2011.pdf 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) CSW 2012