1. 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

2. Introduction What is an Embedded Harvard Architecture processor? Why do we care about vulnerabilities? General Harvard Structure Stack Memory Vulnerabilities Mitigation

3. What is an Embedded Harvard Architecture Processor? Lets 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

4. 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

5. 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

6. 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

7. 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

8. 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

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

10. 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

11. 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

12. 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

13. Mitigation Strategies What can be done about this? Its easy to say, Dont 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……….

14. Questions??