1 / 14

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.

montana
Download Presentation

Vulnerabilities in Embedded Harvard Architecture Processors

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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? • 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

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

  5. 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: • To this: Internet Internet

  6. Harvard Architecture Overview Main Memory System Main Memory System Data Address Pathway Instruction Address Pathway Data Pathway Data and Instruction Pathway Instruction Pathway Address Pathway Central Processing Unit Central Processing Unit Operational Registers Arithmetic and Logic Unit Operational Registers Arithmetic and Logic Unit Program Counter Program Counter Control Unit Control Unit Input/Output System Input/Output System Von Neumann Machine Non-Von Neumann Machine

  7. Harvard Architecture Processor • A Harvard Architecture processor is a non-von Neumann machine • Processors have physicallyseparate storage and signal pathways for instructions and data • This becomes relevant when analyzing for vulnerabilities Main Memory System Data Address Pathway Instruction Address Pathway Data Pathway Instruction Pathway Central Processing Unit Operational Registers Arithmetic and Logic Unit Program Counter Control Unit Input/Output System Non-Von Neumann Machine

  8. Stack Structure • Stack memory is used by the processor to: • Keep track of where it is when calling subroutines • Preserve registers during subroutine calls • Pass calling parameters • The stack is set up by the compiler when your code is compiled System Memory Stack Memory Location 1 Location 2 Location 3 Location 4 Location 5 Location 6 Location 7 Location 8 Location 9 …..

  9. Stack Structure - Example Main { A = 1; B = 2; C = 3; Addem (A,B,C); } System Memory • When Addem() is called the processor will: • Push return address • Push any registers that require preserving • Push calling parameters • Adjust pointer into stack memory based on how much memory the subroutine needs Stack Memory Location 1 Return Address Location 2 Registers Location 3 Location 4 Calling Parameters Location 5 Location 6 Location 7 Location 8 Available for use by subroutine Location 9 ….. Adjusted stack pointer

  10. Stack Structure - Example • What if Addem() uses more stack memory than the compiler allotted? • Calling parameters can be overwritten (Not a big deal) • Registers can be overwritten (May mess things up when we return) • Return address can be overwritten (This is a huge deal and represents a vulnerability!) System Memory Stack Memory Location 1 Return Address Location 2 Registers Location 3 Location 4 Calling Parameters Location 5 Location 6 Location 7 Location 8 Available for use by subroutine Location 9 ….. Adjusted stack pointer

  11. Vulnerability Realization • 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 System Memory Stack Memory Location 1 Return Address Location 2 Registers Location 3 Location 4 Calling Parameters Location 5 Location 6 Location 7 Location 8 Available for use by subroutine Location 9 ….. Adjusted stack pointer

  12. 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 Return Address Location 2 Registers Location 3 Location 4 Calling Parameters Location 5 Location 6 Location 7 Location 8 Available for use by subroutine Location 9 ….. Adjusted stack pointer

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

  14. Questions??

More Related