vulnerabilities in embedded harvard architecture processors presented by: michael j. hohnka cyber...

Vulnerabilities in Embedded Harvard Architecture Processors

Presented By:

Michael J. HohnkaCyber Vulnerabilities LeadCyber Innovation Division

Communications, Information, and Navigation OfficeApplied Research Laboratory

814-867-4145mjh147@arl.psu.edu

Introduction

What is an Embedded Harvard Architecture processor?

Why do we care about vulnerabilities?

General Harvard Structure

Stack Memory

Vulnerabilities

Mitigation

What is an Embedded Harvard Architecture Processor?

Let’s break this down…..

We all know what a processor is

Embedded processors:

Generally used in a relatively small, self-contained system and possesses very specific or targeted functionality

Wide variety of uses: appliances, automotive, communications, etc

These processors are used virtually everywhere

In addition, more and more devices are being connected to the Internet

We have gone from:

Why worry about vulnerabilities in these processors?

Internet

These processors are used virtually everywhere

In addition, more and more devices are being connected to the Internet

We have gone from:

To this:

Why worry about vulnerabilities in these processors?

Internet

Internet

Harvard Architecture Overview

Main Memory System

Central Processing Unit

Operational Registers

Program Counter

Arithmetic and Logic

Unit

Control Unit

Input/Output System

Data and Instruction Pathway

Address Pathway

Von Neumann Machine

Main Memory System

Central Processing Unit

Operational Registers

Program Counter

Arithmetic and Logic

Unit

Control Unit

Input/Output System

Instruction Pathway

Instruction Address Pathway

Non-Von Neumann Machine

Data Address Pathway

Data Pathway

Harvard Architecture Processor

Main Memory System

Central Processing Unit

Operational Registers

Program Counter

Arithmetic and Logic

Unit

Control Unit

Input/Output System

Instruction Pathway

Instruction Address Pathway

Non-Von Neumann Machine

Data Address Pathway

Data Pathway

A Harvard Architecture processor is a non-von Neumann machine

Processors have physically separate storage and signal pathways for instructions and data

This becomes relevant when analyzing for vulnerabilities

Stack Structure

System Memory

Location 1

Location 7

Stack Memory

Stack memory is used by the processor to:

1. Keep track of where it is when calling subroutines

2. Preserve registers during subroutine calls

3. Pass calling parameters

The stack is set up by the compiler when your code is compiled

Location 2

Location 3

Location 4

Location 5

Location 6

…..

Location 8

Location 9

Stack Structure - Example

System Memory

Location 1

Main { A = 1; B = 2; C = 3; Addem (A,B,C);}

Location 7

Stack Memory

When Addem() is called the processor will:

1. Push return address

2. Push any registers that require preserving

3. Push calling parameters

4. Adjust pointer into stack memory based on how much memory the subroutine needs

Location 2

Location 3

Location 4

Location 5

Location 6

…..

Location 8

Location 9

Return Address

Registers

Calling Parameters

Available for use by subroutine

Adjusted stack pointer

Stack Structure - Example

System Memory

Location 1

Location 7

Stack Memory

What if Addem() uses more stack memory than the compiler allotted?

1. Calling parameters can be overwritten (Not a big deal)

2. Registers can be overwritten (May mess things up when we return)

3. Return address can be overwritten (This is a huge deal and represents a vulnerability!)

Location 2

Location 3

Location 4

Location 5

Location 6

…..

Location 8

Location 9

Return Address

Registers

Calling Parameters

Available for use by subroutine

Adjusted stack pointer

Vulnerability Realization

System Memory

Location 1

Location 7

Stack Memory

Can this really happen intentionally?

• If someone is familiar with the code…..

• AND they are aware of this vulnerability……

• AND they can force it to happen by introducing data into your device externally….

• THEN they can essentially control execution of your software

Location 2

Location 3

Location 4

Location 5

Location 6

…..

Location 8

Location 9

Return Address

Registers

Calling Parameters

Available for use by subroutine

Adjusted stack pointer

Vulnerability Realization

System Memory

Location 1

Location 7

Stack Memory

How about an example?

• The “C” function strcpy() is widely used

• It copies a string from a source to a destination

• If the destination is on the stack AND there is no bounds checking on the copy the stack can be intentionally corrupted to exploit this vulnerability

Location 2

Location 3

Location 4

Location 5

Location 6

…..

Location 8

Location 9

Return Address

Registers

Calling Parameters

Available for use by subroutine

Adjusted stack pointer

Mitigation Strategies

What can be done about this?

• It’s easy to say, “Don’t use strcpy()!”

• Buffer overflows are the most common and can manifest themselves in different ways

• The designer/programmer should be aware of these issues and should have an idea of how the compiler will translate their software, written in a high-level language, into machine code

• This is only 1 potential vulnerability of many……….

Questions??