Pointer Authentication

Pointer Authentication

Hardware-assisted run-time Protection On balancing security and deployability N. Asokan http://asokan.org/asokan/ @nasokan How to thwart run-time attacks? Run-time attacks are now routine Software defenses incur security vs. cost tradeoffs Hardware-assisted defenses are attractive 2 Protect against run-time attacks without incurring a significant performance penalty 3 Hardware-assisted run-time protection Two case studies: HardScope: minimal CPU extensions for hardware-assisted scope enforcement

PARTS: Run-time safety using ARM Pointer Authentication 4 HardScope Hardware-assisted Run-time Scope Enforcement Thomas Nyman, Ghada Dessouky, Shaza Zeitouni, Aaro Lehikoinen, Andrew Paverd, N. Asokan, Ahmad-Reza Sadeghi ) Aalto University, ) Technische Universitt Darmstadt Motivation: Run-time Attacks Memory corruption vulnerabilities in C / C++ can allow an attacker to access to: Control-data, e.g. return address stored on call stack (control-flow hijacking) Decision-making data, e.g. user id used for authorization decisions (data-oriented attack) Sensitive data, e.g. cryptographic keys (information leakage) Access to unintended data Compile-time variable visibility rules make references to unintended variables less likely

Enforcing variable scope also at run-time would reduce potential of memory attacks 6 Challenges Lexical scope only known at compile-time In C / C++, variable visibility information not available at run-time Granularity of enforcement Effective compartmentalization requires fine granularity for subjects (code) and objects (data) Context-sensitive access Same code may operate under different set of access rules depending on caller Pervasiveness Efficiently mediate all memory accesses 7 Design HardScope: High-level Idea Instrument program during compilation to: Split code up into distinct execution contexts (common environment for function or block) Associate each execution context with storage regions, (data memory accessed) Modify underlying hardware with HardScope instructions to: Accumulate rules for storage regions

[new storage region instructions] Track changes in execution context [new scope block instructions] Track dynamic data flows [new data delegation instructions] Enforce accesses to storage regions [modified load / store instructions] 9 New Instructions During run-time, 7 new instructions configure HardScope-hardware with access rules Scope Block instructions mark points of domain transitions, e.g. function call / return Storage Region (SR) instructions whitelist memory regions for current domain, e.g. stack frame Delegation instructions gives callee/caller access to SRs e.g. arguments, return values Mnemonic sbent Name Scope Block ENter Description Mark transition into new domain

sbxit Scope Block eXIT Mark transition ouf of domain sradd Storage Region ADD srdda Storage Region ADD (reverse operands) srdel Storage Region DELete Revoke access to storage region srdlg Storage Region DeLeGate

Delegate existing SR to callee / caller srdsub Storage Region Delegate SUBregion Delegate subregion to an existing SR Set base and limit for new storage region 10 Storage Region Stack SSRS in protected memory Stack-oriented storage for accumulated access rules Stores the bounds of each used storage region (e.g. stack variable, heap object, global variable) Frames created upon domain entry (sbenter push) Frames discarded upon domain exit (sbxit pop) Actively enforced rules in topmost frame Memory accesses matched only against active rules Subsequent frame store inactive rules for inactive domains

Function-level enforcement mirrors structure of call stack Maintained in protected memory Rules only modifiable by HardScope instructions domain n rules domain n-1 rules domain n-2 rules 11 Storage Region Stack Hardware Design Active and delegated storage region rules stored in register banks Allows enforcement without slowing down loads / stores as active rules cached for fast access Cache management amortized over several instructions on execution context change SSRS in protected memory Cache

Active bank Spare bank SRS Controller 12 Function-granularity compartmentalization Functions separated into distinct execution contexts main stack frame int main(int argc, char *argv[]) { ... doit(argv[1]); ... } return 0; void doit(char *str) { char buf[8];

char ptr = buf; strcpy(buf, str); puts(ptr); down) arguments: 0xffffceb8 0xffffd18a (argv[1]) doit stack frame 0xffffceb4 0x08048482 (saved return ip) 0xffffceb8 (saved address: frame 0xffffceb8 pointer: ptr: fp)

0xffffcea0 0xffffcea0 (&buf) void strcpy(char *str) { ... } 0xffffceb0 0xffffceac 0xffffcea8 0xffffcea4 buf: } Stack (grows arguments: 0xffffcea0 (ptr) 0xffffd18a (str) strcpy stack frame

0xffffcea0 0xffffce9c 0xffffce98 Heap (grows up) Bss segment Data segment Text segment 13 Return-state compartmentalization Function prolog and epilog separated into own execution context main stack frame int main(int argc, char *argv[]) { ... doit(argv[1]); ... } return 0;

void doit(char *str) { prolog char buf[8]; char ptr = buf; } strcpy(buf, str); puts(ptr); epilog void strcpy(char *str) { ... } Stack (grows down) arguments: 0xffffceb8 func stack

frame 0xffffd18a (argv[1]) 0xffffd18a 0xffffceb4 0x08048482 (saved return ip) 0xffffceb8 (saved address: frame 0xffffceb8 pointer: ptr: fp) 0xffffcea0 0xffffcea0 (&buf) 0xffffceb0 0xffffceac 0xffffcea8 0xffffcea4

buf: arguments: 0xffffcea0 (ptr) 0xffffd18a (str) strcpy stack frame 0xffffcea0 0xffffce9c 0xffffce98 Heap (grows up) Bss segment Data segment Text segment 14 Implementation Proof-of-Concept Implementation Proof-of-Concept ISA extension for RISC-V processor Software simulation implemented for Spike ISA simulator Integrated with PULPino SoC on ZedBoard FPGA GCC Plug-in for automatic HardScope instrumentation Function granularity enforcement for local, global, and

static variables, function arguments and return values Only 3.2% performance overhead in CoreMark embedded benchmarks 11% binary size increase due to instrumentation 32 entries in register banks (CoreMark used only up to 23) 574 byte memory overhead* *) Maximum SRS depth: 71 entries over 11 frames encoded using 64 bits per SR entry + 4 bits per frame for the number of entries 16 HardScope benefits + Adjustable granularity of enforcement e.g. module-, function-, code-block- compartmentalization + Can provide resilience against multiple classes of attacks e.g. ROP, DOP 17 HardScope limitations -

Currently only supports single-threaded C programs Additions to hardware design needed to support concurrency Currently manual annotations needed to instrument dynamic data structures Coarse-granularity enforcement can be provided via wrappers Assumes programs minimize variable scope and module interdependence Programs without logical structure benefit less and consume more SRS resources - SRS frame size fixed at synthesis time Optimal frame size may be difficult to determine 18 Technical report & source code HardScope: Thwarting DOP with Hardware-assisted Run-time Scope Enforcement DAC 2019?(phew!) Research report version available at https://arxiv.org/abs/1705.10295 Toolchain, emulator and code samples: https://github.com/runtime-scope-enforcement/ https://arxiv.org/abs/1705.10295

https://github.com/runtime-scope-enforcement 19 Towards Pointer Integrity using ARM Pointer Authentication Hans Liljestrand, Thomas Nyman, Kui Wang, Carlos Chinea Perez, Jan-Erik Ekberg, N. Asokan ) Aalto University, ) Huawei Technologies Pointer Integrity (PI): memory safety for pointers Ensures that a pointer at use time is the same as at creation time Code pointer integrity implies CFI CF attacks rely on pointer manipulation Data pointer integrity reduces data-only attack surface prevents all known Data-Oriented

Programming (DOP) attacks function function {{ store store return_address return_address corrupt_address! corrupt_address! load load return_address return_address verify verify integrity integrity return return }} PI

22 Kuznetsov et al. Code-Pointer Integrity, USENIX OSDI 2014 Can PI be realized in practice? Can we use ARM v8.3-A Pointer Authentication (PA)? But, PA is vulnerable to pointer reuse! Our work: Design PA-assisted Run-time Safety (PARTS) Return address signing backward-edge CFI Code pointer signing forward-edge CFI Data pointer signing data-flow integrity for pointers Mitigates pointer reuse with run-time type safety 23 ARM Armv8-A architecture: 2016 additions, 2016 ARM 8.3-A Pointer Authentication 64-bit 64-bit pointer pointer address

Pointer Authentication Codes (PAC) Tweakable MAC Set in unused bits of virtual address modifier Key/configuration set at higher privilege level tweakable MAC PAC Instrument with new PAC handling instructions Opcode determines used key Operands set PA modifier (tweak value) PAC instructions address Code-key A

pacia PA-key B Data-key A B X pacib X pacda X pacdb

X pacga autia autib autda autdb Gen.-key X X X X X 24 Example: PA-based return address signing Function return address LR address func {

pacia LR, SP str LR STACK ldr LR generate PAC Code Key A PAC PAC LR address PAC? PAC? LR address

autia LR, SP ret verify PAC PI Code Key A } 25 Qualcomm Pointer Authentication on ARMv8.3, whitepaper 2017 PA only approximates fully-precise pointer integrity Adversary may re-use PACs /* func1() */ brl %func1 /* func2() */ brl %func2

func1 { pacia LR, SP str LR Not necessarily unique! func2 { pacia LR, SP str LR STACK STACK ldr LR autia LR, SP ret } ..ab08 ..ab10 ..ab18 ..ab20

..ab28 ..ab30 ..ab38 ..ab40 ..ab48 ..ab50 func2 stack frame func1 SP 26 Design Hardening return address signing Modifier: function-id + SP value Function-id assigned at compile-time Prevent cross-function return address reuse Future additions Combine with SP randomization

func { mov Xm, SP mov Xm, #f_id, #lsl_16 pacia LR, Xm str LR ldr LR mov Xm, SP mov Xm, #f_id, #lsl_16 autia LR, Xm ret } Mashtizadeh et al. Cryptographically Enforced Control Flow Integrity, ACM CCS 2015 28 Code pointer signing Modifier: type-id Assigned at compile-time Based on LLVM ElementType

function signature Uses on-use authentication With combined auth+branch instr. /* f_ptr = func; */ mov Xd, #func_address mov Xm, #t_id pacia Xd, Xm PACed PACed only only on on pointer pointer creation! creation! /* f_ptr(); */ mov Xm, #t_id lbraa Xd, Xm

Authenticated Authenticated at at use use 29 Data pointer signing Modifier: type-id Assigned at compile-time Based on IR ElementType data type Uses on-load authentication always auth on load /* data *ptr = &var; */ mov Xm, #type_id

PACed PACed at at store store pacda Xd, Xm str Xd, #store_address /* use(ptr); */ ldr Xd, #store_address mov Xm, #type_id autda Xd, Xm Authenticated Authenticated at at load load 30 Brute-forcing PACs

Key reset does not offer significant gains at low p values Wrong PAC causes process crash Recall: PAC keys reset on process start Probability p of guessing b-bit PAC correctly after n tries: =( ) For b=16, p=0.5, n = 45425 Threading/pre-forking is a concern Commonly used: e.g., Android Zygote Key reset on live process infeasible Restarting siblings+parent disruptive Approach: Restart siblings+parent after threshold number of crashes 31 Implementation PARTS implementation architecture Uses PA to protect: Return addresses on the stack Local, global, and static pointers

Pointers in C structures Source Code LLVM LLVM based compile-time instrumentation Optimizer passes AArch64 backend specific changes Clang frontend Optimizer PARTS Backend PARTS linker PARTSlib PARTS-Instrumented binary

33 Evaluation: nbench performance Reasonable overhead (geom.mean) Combined return address and code pointer signing < 0.5% Data pointer signing ~19.5% nbench-byte benchmark results 1.5 1.4 1.3 1.2 1.1 1 0.9 Numeric sort String sort

Bitfield FP emulation return address signing Fourier code pointer signing Assignment Idea data pointer signing all enabled Huffman Neural net Lu decomposition 34

Technical report & source code PAC it up: Towards Pointer Integrity using ARM Pointer Authentication accepted to USENIX Security 2019 Research report version available at arxiv.org/abs/1811.09189 Compiler and code samples (will appear at): github.com/pointer-authentication arxiv.org/abs/1811.09189 github.com/pointer-authentication 35 PARTS: next steps Threat surface: estimate prevalence of pointer reuse scenarios in real-world programs Performance: evaluate on real hardware Generality: extend to C++ How to handle C++ class hierarchies? Can we protect C++ exception handling? Other C++ specific features? Extensions: (how) can we use PA towards achieving full memory safety? 36

HardScope vs. Pointer Authentication Share the same high-level objective but take entirely different approaches Enforce data-flows between fine-grained subjects by scope enforcement vs Secure data-flows by ensuring integrity of pointers 37 HardScope: Challenges to acceptance Hardware changes (even minimal ones) pose a major hurdle Backward compatibility vs security Dynamic (non-continuous) data structures, global pointers, Scalability vs. extent of problem For embedded domain: low #rules/domain, but are data-oriented attacks a real concern? RISC-V vs. real deployment 38 Hardware-assisted run-time protection: the promise Pointer Authentication is powerful What are other creative uses of PA?

Other hardware primitives in the pipeline Memory Tagging Branch Target Indication Security Usability Deployability/Cost 39 https://ssg.aalto.fi/research/projects/harp https://ssg.aalto.fi/research/projects/harp

Recently Viewed Presentations

  • EO1100 - California State University, Northridge

    EO1100 - California State University, Northridge

    EO1100 refers to sections A-E as "required for all CSU campuses," but does not actually specify the elimination of Section F (Susan Fitzpatrick) ... Reserve multiple rooms for film screening. Add closed captioning to all screenings.
  • 2008 Accountability Annual Meeting Bureau of Research and

    2008 Accountability Annual Meeting Bureau of Research and

    Student tested in FCAT in reading and/or math at alternative school with scores in current and two previous years. Student is 10th grader and has not passed the FCAT in reading and/or math. 2007 - 2008 School Improvement Ratings for...
  • GEOID03 - Home | National Geodetic Survey

    GEOID03 - Home | National Geodetic Survey

    CT DE Mark Eckl MA Curtis Crow MD Donald M. Mulcare ME NH Curtis Crow NJ Warren Payton NY PA RI VT Dan Martin -50% of the world's population lives on or near the oceans -selection of the equipotential value...
  • Year 1 Phonics Check - Broadwater C of E School

    Year 1 Phonics Check - Broadwater C of E School

    a word using phonics skills and not their memory. The pseudo words will be shown to your child with a picture of a monster. This not only makes the check a bit more fun, but provides the children with a...
  • Exploring Periodic Trends - Mr. Ward

    Exploring Periodic Trends - Mr. Ward

    Exploring Periodic Trends. Atomic radius (AR)Definition: the distance from the atomic nucleus to the outermost stable electron orbital in a atom at equilibrium. Group Trend: Size increases . The number of energy levels increases as you move down a group...
  • MZK w Bolesławcu Sp. z o.o.

    MZK w Bolesławcu Sp. z o.o.

    Oprogramowanie umożliwiające prezentację dwujęzycznego rozkładu jazdy na przystankach i w Internecie, z modułem eksportu rozkładu jazdy do formatu TransXchange. Serwer spełniający wymagania zakupionego systemu oraz prezentujący w Internecie graficzną wersję rozkładu jazdy.
  • School of Health &amp; Bioscience - University of East London

    School of Health & Bioscience - University of East London

    E-cigarettes used in quit attempts. Source: Smoking Toolkit Study. Robert West & Jamie Brown. www.smokinginengland.info % of those trying to stop in the past year who used electronic cigarettes to help them E-cigs 39995
  • Eye Witnesses to Peace 1918-20: Primary Sources from LSE Archives

    Eye Witnesses to Peace 1918-20: Primary Sources from LSE Archives

    Eye Witness to Peace 1918-20: Primary Sources from LSE Archives. The resource is linked to sections on the League of Nations in the Giving Peace a Chance: From the League of Nations to Greenham Common exhibition at LSE Library 4...