Title of Selected Paper: IMPRES: Integrated Monitoring for Processor Reliability and Security Authors: Roshan G. Ragel and Sri Parameswaran Presented by: Arjun Prakash

Outline What is Code Injection Attack? Related Work Motivation IMPRES Architecture – An overview Software Instrumentation Code Injection Attack Detection Check-summing at Runtime Contribution and Limitations Code Integrity Violation Model Encryption Hardware Design Flow Evaluation Summary

Format String Vulnerabilities Stack Based Buffer Overflows Heap Based Buffer Overflows Attacks violating software integrity (dynamically changing instructions with the intention of gaining access to a program). Insertion of harmful instructions into the program stream. Dangling Pointer References Code Injection Attacks 47% of vulnerabilities reported from were code injection

Examples for Code Injection Attack (1) Return Address Overwriting

Heap Based Buffer Overflow Examples for Code Injection Attack (2)

Related Work Existing work on Code Injection detection can be categorized into: Software based Static Technique Detect Vulnerability at compile time (automated static code analysis) Dynamic Technique Methods to prove program behaves as expected at runtime Software constructs to prove program behavior Hardware based (Usually attack specific) Use of additional co-processor Addition co-processor & hardware tables Embedded Micro Monitoring - MicroInstruction routines to perform in-line security monitoring (only partial support)

Motivation Software Approach Huge Code-size Overhead High Performance Penalty Check-summing is susceptible to code injection attacks Solutions to Code Injection Attacks Hardware Approach –High Area Impact –Interfacing Problem –Memory/table limitations –Scalability Problems IMPRES is a novel Hardware/Software technique at the granularity if micro- instructions to reduce overheads considerably

Software Instrumentation Compile Assemble & Link Application Source Code Code Injection Detection IMPRES HARDWARE Secure IMPRES Architecture: An Overview Instrumented Binary Loading

Software Instrumentation A special instruction ( chk ), with the checksum is inserted at the beginning of each logical basic block

Chk e-checksum Inst1 Inst2 Inst3 Inst4 Inst5 CFI Check-summing at Runtime e-checksum e-checksum’ Chksum 1 Encrypt = √ Chksum Chksum Chksum Chksum Chksum BB + A Typical Basic Block Incremental checksum recalculation:- Does not accumulate workload to particular points in the program flow Encryption (a time consuming task) is used only when it is required. Decreases overhead!

Code Injection Attack Detection  Static time Check-summing  Load time encryption using hardware secret key  Runtime encrypted check-summing and comparison  fBB flag : Set only when Check Instructions at the beginning of BBs and micro instruction embedded into the machine instructions server as interface between H/w and S/w

A code injection detector which require only a rudimentary software analysis Instruction memory transient fault detector (Single Event Upset in the instruction memory are fully detected with small latency) Encrypted Basic Block Check-summing for code integrity violation detection × Will only detect code injection attacks and will NOT detect any other security threats Contributions & Limitations

Code Integrity Violation Model

Code Integrity Violation Model (2)  The model in the previous slide covers all the possible cases  All the combinations other than those presented in the previous slide are duplicates/subsets  Some duplicates are depicted below (D1 ε T01, D2 ε T09 and D3 ε T14)

Integrity Violation Detection Type Original Changed Error Signal T01 chk checksum SIGCKSM T02 chk CFI SIGCKSM T03 chk nonBI SIGCKSM T04 chk undefined SIGSYSM T05 CFI another CFI SIGCKSM T06 CFI chk SIGNCFI T07 CFI nonBI SIGNCFI T08 CFI undefined SIGSYSM T09 nonBI SIGCKSM T10 nonBI chk SIGNCFI T11 nonBI CFI SIGCKSM T12 nonBI undefined SIGSYSM T13 chk & nonBIs any insts. SIG(CKSM/NCFI) T14 whole BB any insts. SIG(CKSM/NCFI)

Encryption Hardware The encryption is performed in parallel to the pipeline. A single encryption takes 18 clock cycles with a clock period 20x smaller than that of the processor.

Design Flow (a) Software Instrumentation (b) IMPRES Hardware Model

Evaluation SIGCHSM - Encrypted Checksum mismatch SIGNCFI - No Control Flow Instruction SIGSYSM- System Error

Performance Overhead Average performance overhead is Blowfish benchmark performs better… Why?

Hardware and Memory Overheads Clock Period (ns) Area (gates) Leakage Power (10 -6 watt) Ordinary H/W IMPRES H/W Overhead (%)0.06%0.91%1.05%

Fault Injection Analysis

Error Detection Latency Type Activated At Detected At   (/bbsize) T011 bbsize bbsize-11 T T T T05 bbsize 01 T06 bbsize 01 T07 bbsize bbsize+111 T08 bbsize 01 T09 bbsize/2 bbsize bbsize/2 bbsize-2 T10 bbsize/2 0 bbsize-2 T11 bbsize/2 0 bbsize-2 T12 bbsize/2 0 bbsize-2 Average Error Detection Latency =

Summary and Conclusions  Code Injection Attacks are still Real  IMPRES provides a low cost rudimentary solution to code injection attacks  IMPRES’s overheads and detection latency are minimum

THANK YOU!