vulnerabilities in embedded harvard architecture processors presented by: michael j. hohnka cyber...
TRANSCRIPT
Vulnerabilities in Embedded Harvard Architecture Processors
Presented By:
Michael J. HohnkaCyber Vulnerabilities LeadCyber Innovation Division
Communications, Information, and Navigation OfficeApplied Research Laboratory
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??