QPSI. Qualcomm Technologies Countermeasures Update

Transcription

1 QPSI Qualcomm Technologies Countermeasures Update 1

2 Introduction Sometime back in 2010 Let s have exploit countermeasures on our products Why? Hard to fix all bugs. We might as well make them more fun difficult to exploit. Where? All embedded images. Let our customers worry about Linux/Windows How? Lets start with some basics

3 Introduction Sometime back in 2010 Let s have exploit countermeasures on our products Why? Hard to fix all bugs. We might as well make them more fun difficult to exploit. Where? All embedded images. Let our customers worry about Linux/Windows How? Lets start with some basics

4 Introduction SoC architecture An SoC contains a number of processor cores Applications, Modem, DSP, Wireless, Sensors, Processors may have different architectures ARM, Hexagon, etc. Each processor has one or more images ROM images, Bootloaders, TrustZone HLOS (High-Level Operating System) Modem Peripheral images

5 Baseline mitigations Data Execution Prevention (DEP) Memory should not be writable and executable at the same time (W^X). Also make sure page 0 is not mapped. Stack Protection Enable stack canaries in builds. Make sure the canaries are generated randomly. Heap Hardening Protect heap metadata, do safe linking/unlinking/... ASLR Randomize as much as possible

6 Data Execution Prevention (DEP) Hardware support needed Processor cores must support non-executable mappings Hexagon DSPs for Modem etc. ARM7 (ARMv3), ARM9 (ARMv5) as peripheral processors. ARM11 (ARMv6) or Scorpion (ARMv7) as the applications processor. Memory permissions must be adjusted Either RW or RX, but never WX. Also do not map page 0 Requires image alignment -> has physical memory impact. Default permissions must be fixed. No more RWX for new mappings.

7 Software Stack Protection (SSP) Toolchain support needed: -fstack-protector RVCT (ARM) compiler v3.8 had no stack protection support We asked ARM to add support for stack protection It was delivered in v5.01 of the compiler. GCC used for Hexagon DSP already had support. Need random numbers during initialization Hardware RNG available. Had to enable it early on. Make drivers available in all images.

8 Heap Hardening SafeHeap: Guidelines for a robust heap implementation Header integrity and safe unlinking Debugging aids Secure redesign Implementing SafeHeap Identify heap implementations 17 distinct heap implementations across 12 images, 2 SoC s. Evaluate them against SafeHeap criteria Come up with a plan to transition to SafeHeap compliant heaps. Fixing existing heaps did not work. Converged to two heaps we reviewed.

9 Address Space Layout Randomization Randomize all the things Turns out it is hard to randomize embedded images. Many assumptions about physical addresses. Lack of MMU in some cases. Architectural limitations. Time critical code that needs to run from fixed locations. Performance/size concerns regarding position independent code. Toolchain limitations No PIE (Position Independent Executable) support We ended up randomizing heap/stack base on certain images. Started exploring alternatives to code layout randomization.

10 Countermeasures Roadmap 10

11 Countermeasures Roadmap Overview Lets do this for ALL products Work with all image/product leads Establish security requirements for products Work with developers to implement countermeasures Provide proof-of-concept implementations Review the implementations. Test for the presence of countermeasures Figure out solutions for non-standard cases New architectures/images/toolchains. Research domain-specific countermeasures

12 Countermeasures Roadmap ALL products Initial work focused on embedded cores in mobile chipsets. MSM/APQ/MDM. Embedded (non-hlos) images. We need to cover other products. Router, Automotive, Small cell, IoT, QNX, OpenWRT, other embedded Linux distributions,. Android and Windows are fine. What about OpenWRT? Need to engage with HLOS images as well.

13 Countermeasures Roadmap Domain Specific Countermeasures DEP for ARM9 (video core) Use SMMU to enforce DEP TrustZone Secure application ASLR Linux kernel Kernel randomness at boot for SSP Privileged Access Never (PAN) support for ARMv8 Stack protection for Xtensa cores Register window architecture with no compiler support. Hexagon FRAMEKEY Stack frame scrambling in hardware

14 Countermeasures Roadmap Testing Need both static and dynamic tests. DEP dynamic allocations. Stack protection presence and canary randomness. Error handlers. Successful tests crash the system Opposite of how functional testing frameworks determine success. Interesting issues A new feature introduced aliased RW mappings, breaking DEP. Only the test code was actually compiled with SSP. QSEE Application ASLR randomness.

15 Domain-Specific Countermeasures 15

16 StackGhost Tensilica Xtensa Register File ar0 ar3 ar4 ar7 ar8 ar11 ar12 ar15 ar16 ar19 ar20 ar23 ar24 ar27 ar28 ar31

17 StackGhost Tensilica Xtensa Register File ar0 ar3 ar4 ar7 ar8 ar11 Register Window ar12 ar15 ar16 ar19 ar20 ar23 ar24 ar27 ar28 ar31

18 StackGhost Tensilica Xtensa Register File call0 call4 call8 call12 ar0 ar3 ar4 ar7 ar8 ar11 ar12 ar15 ar16 ar19 ar20 ar23 ar24 ar27 ar28 ar31 Register Window

19 StackGhost Tensilica Xtensa Register File ar0 ar3 call0 call4 call8 call12 ar4 ar7 ar8 ar11 ar12 ar15 ar16 ar19 ar20 ar23 ar24 ar27 ar28 ar31 Register Window

20 StackGhost Tensilica Xtensa Register File File ar0 ar3 call0 call4 call8 call12 ar4 ar7 ar8 ar11 ar12 ar15 ar16 ar19 ar20 ar23 ar24 ar27 ar28 ar31 Register Window???

21 StackGhost Tensilica Xtensa Register File File ar0 ar3 ar4 ar7 call0 call4 call8 call12 ar8 ar11 ar12 ar15 ar16 ar19 ar20 ar23 ar24 ar27 Register Window ar28 ar31

22 StackGhost Tensilica Xtensa Stack Protection Saved return addresses are spilled onto the stack during window overflow and restored during window underflow. Stack canaries make little sense.

23 StackGhost StackGhost: Hardware Facilitated Stack Protection Window {over,under}flows are exceptions handled by the kernel. Encode the saved return address and frame pointer before spilling them onto the stack. Decode the saved return address and frame pointer after restoring them from the stack. The key is stored in a special register when available or memory. The key can be refreshed in some situations.

24 Countermeasures Research 24

25 Control Flow Integrity Definition Control Flow Integrity (CFI) is a property of a program where the control flow follows only legitimate paths through the program determined in advance.

26 Control Flow Integrity Call Flow Graph

27 Control Flow Integrity Exploitation

28 Control Flow Integrity

29 Control Flow Integrity Active research area since about Control-Flow Integrity: Principles, Implementations, and Applications. Microsoft s Control Flow Guard. LLVM implementations. Enforcing Forward-Edge Control-Flow Integrity in GCC & LLVM. GRSecurity Reuse Attack Protector (RAP).

30 Control Flow Integrity Challenges and Lessons Key challenges / goals for embedded images. Low performance overhead. Low code size overhead. Support modern software engineering practices. Interoperability. Security. Lessons Protecting indirect branches is less expensive than protecting return addresses. Use different solutions for indirect branches and return addresses. Hardware support is necessary.

31 Hexagon Hardware Stack Protection FRAMEKEY Hexagon has instructions to allocate/deallocate stack frames. allocframe pushes LR and FP to the stack and adjusts SP. deallocframe restores LR and FP and adjusts SP. FRAMEKEY scrambles the return address. Encode the return address before spilling it onto the stack in allocframe. Decode the return address after restoring it from the stack in deallocframe. The key is stored in a new FRAMEKEY register. Kernel manages FRAMEKEY for threads. Generate a random FRAMEKEY when creating a new thread. Save/restore FRAMEKEY when switching threads.

32 Hexagon Hardware Stack Protection SSP FRAMEKEY Coverage 2 % of functions. 100 % of non-leaf functions. Size and Performance Impact Information Leaks Error Handling Proportional to coverage The canary value can be recovered from the stack. All threads use the same canary value. A software error handler is invoked when a mismatch is detected. None The key can be recovered from the stack. Each thread uses a different key. The program counter is set to an unpredictable address and a fault occurs if the address is unaligned, if non-executable memory is executed, etc.

33 Code Pointer Authentication Proposal for a New Hardware Primitive What if we could detect corrupted pointers? Without additional memory overhead. Without expensive software operations. Observation: 64-bit function pointers have many unused bits. Make use of these bits to store an authentication tag. Use a cryptographically secure algorithm. Use an ephemeral, per process key. Compute the tag over the pointer and a context. Context determines where the authentication tag is valid. Makes it harder to substitute signed pointers for other signed pointers.

34 Code Pointer Authentication New Instructions Authenticate a pointer with a MAC when it is created. TAUTH Rd, Rs, Rc Verify the pointer before it is dereferenced. TVERIFY Rd, Rs, Rc Address Tag MAC Context Key

35 Conclusion pointers

36 Thank you All data and information contained in or disclosed by this document is confidential and proprietary information of Qualcomm Technologies, Inc. and all rights therein are expressly reserved. By accepting this material the recipient agrees that this material and the information contained therein is to be held in confidence and in trust and will not be used, copied, reproduced in whole or in part, nor its contents revealed in any manner to others without the express written permission of Qualcomm Technologies, Inc QUALCOMM Incorporated and/or its subsidiaries. All Rights Reserved. Qualcomm is a trademark of Qualcomm Incorporated, registered in the United States and other countries. Other products and brand names may be trademarks or registered trademarks of their respective owners References in this presentation to Qualcomm may mean Qualcomm Incorporated, Qualcomm Technologies, Inc., and/or other subsidiaries or business units within the Qualcomm corporate structure, as applicable. Qualcomm Incorporated includes Qualcomm s licensing business, QTL, and the vast majority of its patent portfolio. Qualcomm Technologies, Inc., a wholly-owned subsidiary of Qualcomm Incorporated, operates, along with its subsidiaries, substantially all of Qualcomm s engineering, research and development functions, and substantially all of its product and services businesses, including its semiconductor business. 36