Vulnerabilities in Embedded Harvard Architecture Processors

Vulnerabilities in Embedded
Harvard Architecture Processors
Presented By:
Michael J. Hohnka
Cyber Vulnerabilities Lead
Cyber Innovation Division
Communications, Information, and Navigation Office
Applied Research Laboratory
814-867-4145
mjh147@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
Why worry about vulnerabilities
in these processors?
 These processors are used virtually everywhere
 In addition, more and more devices are being connected to
the Internet
 We have gone from:
Internet
Why worry about vulnerabilities
in these processors?
 These processors are used virtually everywhere
 In addition, more and more devices are being connected to
the Internet
 We have gone from:
Internet
 To this:
Internet
Harvard Architecture Overview
Main Memory System
Data and
Instruction Pathway
Address
Pathway
Central Processing
Unit
Operational
Registers
Arithmetic
and Logic
Unit
Program
Counter
Main Memory System
Instruction
Address
Pathway
Instruction
Pathway
Data
Address
Pathway
Central Processing
Unit
Operational
Registers
Arithmetic
and Logic
Unit
Program
Counter
Control Unit
Input/Output System
Von Neumann
Machine
Control Unit
Input/Output System
Non-Von Neumann
Machine
Data
Pathway
Harvard Architecture Processor
Main Memory System
Instruction
Address
Pathway
Instruction
Pathway
Data
Address
Pathway
Central Processing
Unit
Operational
Registers
Arithmetic
and Logic
Unit
Program
Counter
Control Unit
Input/Output System
Non-Von Neumann
Machine
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
Stack
Memory
Location 1
 Stack memory is used by the
processor to:
1. Keep track of where it is
when calling subroutines
Location 2
Location 3
Location 4
Location 5
2. Preserve registers
during subroutine calls
Location 6
Location 7
3. Pass calling parameters
Location 8
Location 9
…..
 The stack is set up by the
compiler when your code is
compiled
Stack Structure - Example
Main {
A = 1;
B = 2;
C = 3;
Addem (A,B,C);
}
System Memory
 When Addem() is called the
processor will:
Stack
Memory
Location 1
Location 2
Location 3
Return Address
Registers
Location 4
Location 5
Calling Parameters
Location 6
1. Push return address
2. Push any registers that
require preserving
Location 7
Location 8
Location 9
…..
Available for use
by subroutine
3. Push calling parameters
Adjusted stack
pointer
4. Adjust pointer into stack
memory based on how
much memory the
subroutine needs
Stack Structure - Example
 What if Addem() uses more
stack memory than the
compiler allotted?
System Memory
Stack
Memory
Location 1
Location 2
Location 3
Return Address
Registers
Location 4
Location 5
Calling Parameters
Location 6
Location 7
Location 8
Location 9
…..
Available for use
by subroutine
Adjusted stack
pointer
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!)
Vulnerability Realization
 Can this really happen
intentionally?
System Memory
•
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
Stack
Memory
Location 1
Location 2
Location 3
Return Address
Registers
Location 4
Location 5
Calling Parameters
Location 6
Location 7
Location 8
Location 9
…..
Available for use
by subroutine
Adjusted stack
pointer
Vulnerability Realization
 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
System Memory
Stack
Memory
Location 1
Location 2
Location 3
Return Address
Registers
Location 4
Location 5
Calling Parameters
Location 6
Location 7
Location 8
Location 9
…..
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??