1

RAKSHA: A FLEXIBLE ARCHITECTURE FOR SOFTWARE SECURITY

Computer Systems Laboratory

Stanford University

Hari Kannan, Michael Dalton, Christos Kozyrakis

August 2007

2

PRESENTATION OUTLINE

Motivation

Goals of a Security Technique

What is Dynamic Information Flow Tracking

Raksha Architecture

Security and Performance Evaluation

Summary

Questions

3

MOTIVATION

High-level semantic vulnerabilities are prevalent in web-based attacks SQL injection – code inserted into entry field

Cross-Site Scripting (XSS)

Injected website sends malicious code to client

Real-World Examples: Website database breach

The Wall Street Journal database in July 2014

Twitter worms

statement = "SELECT * FROM users WHERE name ='" + userName + "';"

SELECT * FROM users WHERE name = ‘bob' OR '1'='1';

‘bob’ OR '1'='1userName:ERROR

!

4

GOALS OF SECURITY TECHNIQUES

Robust

Flexible

End-to-End

Practical

Fast

Few false positives or false negatives

Adapt to cover evolving threats

Cover all parts of the

system

Easy to implement

Low overhead

WHAT IS DIFT?

DIFT – Dynamic Information Flow Tracking Associates a tag with every word of memory

Tag is used to mark tainted data from untrusted sources

Data produced from tainted data is also tainted

Check tag when data is used for potentially unsafe operations (ex. Code Execution)

Detects both low and high-level attacks

5

userName=

X ‘bob’

X OR

X ‘1’=‘1

Tag Data

'bob' OR '1'='1userName:

User input(untrusted)

Tag Check

SECURITYTRAP

6

RAKSHA ARCHITECTURE OVERVIEW

Hardware-supported DIFT Tag checking in Pipeline

Key Features of Raksha: 4-bit Tags per Word

Programmable security policies

User-level Exception handling

UserProgram

A

UserProgram

B

OS

Security

Handler

HardwareTags &

Checkers

TagAware

32-bit WordTag

MemoryRegisters

Cache lines

One Tag per Policy

7

RAKSHA: TAG AND POLICY REGISTERS

4-bit tag for each word in registers, cache lines, and memory Allow up to four different policies

Each policy (tag bit) comes with two configuration registers: Tag Check Register (TCR) - Specify what checks to enable for different

instructions

Tag Propagation Register (TPR) - Specify the rules for propagating the tags load r2 ← M[r1+offset]

Check• Check source register r1• Check source address

M[r1+offset]

Propagation• Only source register r1• Only source address

M[r1+offset] • OR / AND of source tags

32-bit WordTag

8

RAKSHA: PIPELINE

Modified Leon SPARC V8 processor pipeline 4-bit tag in registers, caches and memory

Tag ALU propagates tags based on TPR

Tag-checker checks tags based on TCR and raises exception if needed

Execut

e Memor

y Exceptio

n Writebac

k Fetch Decod

e Access

RakshaTags Raksha Logic

9

RAKSHA: SECURITY HANDLER

Runs at the same privilege level as applications in trusted mode Handles security exception without going into OS kernel

Allows protection of OS code

Direct access to tag bits & tag instructions

Protected against malicious applications by sandboxing

App App

OS

Security

Handler

Hardware trap

Untrusted

Trusted

10

EXAMPLE: SQL COMMAND INJECTION

MOV:Source

propagation

Policy #1: TPR

EXEC:Instruction

Check

Policy #2: TCR

ERROR

X ‘bob’

X OR

X ‘1’=‘1

InterpreterX

X

X

SQLCode

ExecutingSQL

In HW

Argument Safe?

YES

NO

SECURITY HANDLER detected

X

X

X

SQLFunctio

nsLibrary

X

X String Tainting

XFunct. Call Interposition

Untagged

11

TEST SETUP

Hardware Modified Leon SPARC V8 processor

Mapped to an FPGA board

Software Modified Linux kernel 2.6.11

Applications (Apache, PostgreSQL, OpenSSH, …)

SPEC2000 benchmarks

12

SECURITY EVALUATION

Security test for low-level and high-level attacks

False positives and negatives?

13

PERFORMANCE EVALUATION

Performance slow down for Raksha vs OS exception handling

SPEC2000 integer benchmarks with memory corruption protection policy

Varying overheads due to different bounds checking techniques by the applications

14

CONCLUSION / SUMMARY

Raksha Features: DIFT implementation with hardware support

Detects high-level and low-level attacks

Flexible security policies

Low performance overhead

Limitations 7.17% gate overhead, 12.5% memory overhead

Tagging not well defined for byte-level data

Inaccuracies in protection against memory corruption vulnerabilities

15

Questions?

16

DISCUSSION POINTS

Is the 4-bit tag enough or too much? How well will this scale for large systems?

Is Raksha (designed for unmodified binaries) suitable for protection against memory corruption vulnerabilities?

Is it safe for security handler to run at the user-level?

PROCON

17