Loading presentation...

Present Remotely

Send the link below via email or IM

Copy

Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.

DeleteCancel

Protecting The Code

No description
by

oren Ben simhon

on 1 May 2018

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of Protecting The Code

ROP Attack
ROP Attack
Similar Attack Techniques
Parameters and control flow reside on the stack
JOP - Jump Oriented Programming

Each gadget block ends with JMP instruction
Monday, April 16, 2018
Oren Benita Ben Simhon
Overview
ROP Attack
Control-flow Enforcement Technology
Defenses Against ROP/JOP/COP Attacks
Control-flow Integrity (CFI) checks perform the following:

Indirect branches target only valid target addresses

Return instructions should only transfer control to the call site


Protecting The Code
Control-flow Enforcement Technology
Intel technologies’ features and benefits depend on system configuration and may require enabled hardware, software or service activation. Performance varies depending on system configuration. Learn more at Intel.com, or from the OEM or retailer.
You may not use or facilitate the use of this document in connection with any infringement or other legal analysis concerning Intel products described herein. You agree to grant Intel a non-exclusive, royalty-free license to any patent claim thereafter drafted which includes subject matter disclosed herein.
No license (express or implied, by estoppel or otherwise) to any intellectual property rights is granted by this document.
Intel disclaims all express and implied warranties, including without limitation, the implied warranties of merchantability, fitness for a particular purpose, and non-infringement, as well as any warranty arising from course of performance, course of dealing, or usage in trade.
No computer system can be absolutely secure.
Intel and the Intel logo are trademarks of Intel Corporation or its subsidiaries in the U.S. and/or other countries.
Copyright © Intel Corporation

Disclaimers
Intel Arch allows instruction decoding to start from any byte

Intel Arch has variable length instruction

Attackers scan the code for meaningful snippets (gadgets)

Attacker can execute chained gadgets
* Tim Rains, David Weston, Matt Miller. Exploitation Trends: From Potential Risk to Actual Risk. In RSA conference 2015.

Overview & Agenda
* Tyler Bletsch, Xuxian Jiang, Vince Freeh. Jump-Oriented Programming: A New Class of Code-Reuse Attack. April 22, 2010
COP - Call Oriented Programming

Each gadget block ends with Call instruction
Keeping Shadow Stack In Sync
Setjmp / Longjmp
The compiler needs to save the SSP in the jump buffer

The compiler increments SSP by skipped number of frames

New instructions were introduced RDSSP and INCSSP
Exception Handling
C++ runtime library is updated to use indirect jump instead of return

It also needs to increment the SSP to pop skipped call frames
Context Switching
Different shadow stacks for each privilege level

Each shadow stack is setup by Operating System
The OS save/restore SSP for thread switching

New ISA was added SAVEPREVSSP and RSTORSSP
Protecting From ROP and Return Address Corruption On Stack
Protection #1: Shadow Stack
Shadow stack is separate stack used exclusively for control transfer operations and is separate from data stack

Shadow stack supporting processors use a new register – Shadow Stack Pointer (SSP)

Writes to the shadow stack are restricted to control transfer instructions and special protected instructions

Call -> Pushes return address on both stacks
No parameters passing on shadow stack
Far calls push Code Segment (CS), Linear Instruction Pointer (LIP) and SSP

Ret -> pops return address from both stacks
Control Flow Protection (#CP) exception in case return addresses don't match


Intel® Control-flow Enforcement Technology (CET) is a CPU instruction set extension to implement CFI

Shadow Stack Introduces mean Instruction-Per-Cycle loss of less than 2%
Protecting From JOP and COP Attacks
Protection #2: Indirect Branch Tracking
IBT introduces new instructions:
ENDBRANCH32 for 32 bit programs
ENDBRANCH64 for 64 bit programs

Indirect Branch Tracking (IBT) detects and prevents attempts to redirect control flow to unintended targets

ENDBRANCH instructions are NOP instructions on Intel 64 processors that do not support CET

If a target instruction of indirect jump / call has no ENDBRANCH instruction a #CP exception is fired

Compiler instruments ENDBRANCH instruction to:

Instructions/functions that their address was taken

Global functions

A new nocf_check attribute was added to:

Disable ENDBRANCH instruction in the beginning of a function

Add no_track prefix to indirect jump/call to disable control flow check

Fine-grained Indirect Branch Tracking
IBT State Machine
Software may restrict certain sensitive functions in program address space (e.g. exec, execv, etc.)

NO_TRACK Prefix and Legacy Compatibility
No perceptible slowdown was measured on average
Code size growth of 0.41%
CET Security Analysis
LLVM already supports Shadow Stack and IBT (including optimizations)
The architecture is enabled using
-mshstk
/
-mibt
flags
Instrumentation is enabled using
-fcf-protection = return/branch
flag
New attribute
nocf_check
is currently supported
ICC / GCC implemented CET and updated corresponding libraries, program loader and linker (ld)
MS Compiler is also being updated

In the future a super set flag of -mibt & -mshstk called -
mcet
will be added
A fix up for setJump / longJump is being promoted into LLVM
LLVM lInker will also be updated to support new ABI flags and generating IBT-enabled PLT

Summary
?
Using buffer overrun you can manipulate the stack
It allows you to inject malicious code to the stack and return to it
One could also use Return Oriented Programming
Unintended gadgets makes the problem even worst
* Calculated using ICC compiler using a suite of microprocessor benchmarks
* Used GCC compiler and ran SPEC 2006 benchmarks
* Used ICC compiler and ran SPEC 2006 benchmarks
CET Status and Future Work
OS and dynamic loader can setup legacy code page bitmap to support code that was not compiled with CET enabled or disable legacy interwork

Indirect Branch Tracking
Shadow Stack
Manipulating The Stack
Using Unintended Gadgets
Is It That Critical?
Average Indirect branch Reduction (AIR), quantifies the fraction of possible indirect targets eliminated by a CFI technique [*]

[*] M. Zhang and R. Sekar. Control Flow Integrity for COTS Binaries. In USENIX Security, 2013.
Full transcript