1 / 36

Hardware Support for Code Integrity in Embedded Processors

Hardware Support for Code Integrity in Embedded Processors. Milena Milenković § , Aleksandar Milenković ‡ , Emil Jovanov § WebSphere Process Server Performance, IBM ‡ The LaCASA Laboratory Electrical and Computer Engineering Department The University of Alabama in Huntsville

geona
Download Presentation

Hardware Support for Code Integrity in Embedded 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. Hardware Support for Code Integrity in Embedded Processors Milena Milenković§, Aleksandar Milenković‡, Emil Jovanov § WebSphere Process Server Performance, IBM ‡ The LaCASA Laboratory Electrical and Computer Engineering Department The University of Alabama in Huntsville Email: milenka@ece.uah.edu Web: http://www.ece.uah.edu/~milenka http://www.ece.uah.edu/~lacasa

  2. st r2,(r3) mul r3,3 st r2,(r3) ld r1,(r3) add r1,r2 jmp (r1) Outline • Motivation • Techniques to Counter Code Injection Attacks • Architectures for Run-Time Verification of Software Integrity • Results • Conclusion

  3. Motivation Computer security today is a critical issue…even more so in the future Attackers in the past Today Tomorrow

  4. Arbitrary code execution Code injection Arc injection Motivation Computer security landscape • Confidentiality • Integrity • Availability

  5. Many Opportunities For Arbitrary Code Execution • Multiple format string vulnerabilities in (1) neon 0.24.4 and earlier, and other products that use neon including (2) Cadaver, (3) Subversion, and (4) OpenOffice, allow remote malicious WebDAV servers to execute arbitrary code. • Buffer overflow in MMClient.exe in Indiatimes Messenger 6.0 allows remote attackers to cause a denial of service (application crash) and possibly execute arbitrary code via a long group name argument to the RenameGroup function in the MMClient.MunduMessenger.1 ActiveX object. • Multiple heap-based buffer overflows in the imlib BMP image handler allow remote attackers to execute arbitrary code via a crafted BMP file. • Stack-based buffer overflow in the URL parsing function in Gaim before 1.3.0 allows remote attackers to execute arbitrary code via an instant message (IM) with a large URL. • Buffer overflow in WIDCOMM Bluetooth Connectivity Software, as used in products such as BTStackServer 1.3.2.7 and 1.4.2.10, Windows XP and Windows 98 with MSI Bluetooth Dongles, and HP IPAQ 5450 running WinCE 3.0, allows remote attackers to execute arbitrary code via certain service requests. • Integer overflow in pixbuf_create_from_xpm (io-xpm.c) in the XPM image decoder for gtk+ 2.4.4 (gtk2) and earlier, and gdk-pixbuf before 0.22, allows remote attackers to execute arbitrary code via certain n_col and cpp values that enable a heap-based buffer overflow. • Multiple buffer overflows in RealOne Player, RealOne Player 2.0, RealOne Enterprise Desktop, and RealPlayer Enterprise allow remote attackers to execute arbitrary code via malformed (1) .RP, (2) .RT, (3) .RAM, (4) .RPM or (5) .SMIL files. • Buffer overflow in the JPEG (JPG) parsing engine in the Microsoft Graphic Device Interface Plus (GDI+) component, GDIPlus.dll, allows remote attackers to execute arbitrary code via a JPEG image.

  6. Stack Smashing Lower addresses ProgramCode Buf[0] ... Literal Pool localvariables Buf[n-1] Local var #2 Local var #1 Oldpointer Heap Previous FP FP Return Address Arg #1 ... functionarguments Arg #n Stack … Higher addresses

  7. Stack Smashing Lower addresses ProgramCode Buf[0] ... Literal Pool localvariables Buf[n-1] Local var #2 Local var #1 Oldpointer Heap Previous FP FP Return Address Arg #1 ... functionarguments Arg #n Stack … Higher addresses

  8. Stack Smashing Lower addresses ProgramCode Buf[0] ... Literal Pool localvariables Buf[n-1] Local var #2 Local var #1 Heap Previous FP FP Return Address Arg #1 ... Newpointer functionarguments Arg #n Stack … Attack Code Higher addresses

  9. st r2,(r3) mul r3,3 st r2,(r3) ld r1,(r3) add r1,r2 jmp (r1) Outline • Motivation • Techniques to Counter Code Injection Attacks • Software-based, Static • Software-based, Dynamic • Hardware-based • Architectures for Run-Time Verification of Software Integrity • Results • Conclusion

  10. Software Techniques • Static techniques – in compile time • Automated tools: not scalable or not precise • Programmers’ annotations: additional burden • Dynamic techniques – in run time • Prevent attacks or make them less likely to succeed • Augment the code with run-time checks • “Safe dialects” of C • Code and address obfuscation • Monitoring of program behavior • Often require recompilation and incur significant performance and power overhead

  11. Hardware-Based Defense Techniques • Promise lower overhead in performance and power, reduce overall cost • Support to prevent stack-smashing attacks • Obfuscation and encryption • Data tagging: prevents control flow transfer based on data tagged as spurious • Instruction block signatures: protect code integrity by verifying the signature of executing instruction blocks [UAH; UCLA/Microsoft]

  12. st r2,(r3) mul r3,3 st r2,(r3) ld r1,(r3) add r1,r2 jmp (r1) Outline • Motivation • Techniques to Counter Code Injection Attacks • Architectures for Run-Time Verification of Software Integrity • Results • Conclusion

  13. Architectures for Runtime Verification of Software Integrity • Goal: come up with architectural extensions that are • Universal • Cost-effective • Power efficient • Performance effective • Applicable to legacy software

  14. Architectures for Runtime Verification of Software Integrity • Common sign-and-verify mechanism • Secure installation • Instruction block signatures are generatedand stored together with the program binary • Secure execution • Signatures are calculated from fetched instructionsand compared to stored signatures • Signatures • Extended Multiple Input Signature Register (MISR) • Advanced Encryption Standard (AES)

  15. Secure Installation Secure Execution Original Code Signed Code Trusted Code ... *&-!//*+)@ inc r0 st r2,(r3) mul r3,3 st r2,(r3) ... ... inc r0 st r2,(r3) mul r3,3 st r2,(r3) ... ... inc r0 st r2,(r3) mul r3,3 st r2,(r3) ... Signature Fetch *&-!//*+)@ AES (Enc) InstructionFetch MISR AES (Dec) MISR =? Signature Match Mechanism for Trusted Instruction Execution

  16. Binary+ Sigs Binary Binary Installation Installation Sigs S-Placement Embedded (SIGCEx) Table(SIGCTx) S-Handling S-Handling Discard Keep Keep Discard SIGCED SIGCEK SIGCTD SIGCTK Taxonomy of Proposed Techniques

  17. Data bus Processor sig MMU L1 D-cache … … … … sig Datapath L1I-cache … … … … SIGM FPUs MISR IF L1 I-cache AESDecrypt IBSVU Control =? S-match SC_hit S-Cache … … … … Hardware Support for Signature Verification

  18. Legend: Parallel tasks Steps supporting signature verification SIGCED: Signature Verification I-Cache Lookup No I-cache Miss? Go to decode & execute Yes Address Translation Virtual to Physical Address Translation Fetch Signature Fetch Instructions Calculate Instruction Block Signature Using MISR and a Hidden Key Decrypt Signature from Memory Using a Hidden Key No Cache Line Fetched? Yes No Decrypted Signature == Calculated Signature Yes Go to decode & execute Trap OS

  19. SIGCEK: Signature Verification I-Cache Lookup (PC)S-Cache Lookup (PC) No I-cache Miss? Yes Go to decode & execute Address Translation Virtual to Physical Address Translation No S-cache Miss? Yes Fetch Signature Fetch Instructions Decrypt Signature from Memory Using a Hidden Key Calculate Instruction Block Signature Using MISR and a Hidden Key No Cache Line Fetched? Yes No Decrypted Signature == Calculated Signature Yes Go to decode & execute Trap OS

  20. SIGCTD: Signature Verification I-Cache Lookup No Signature Address Calculation I-cache Miss? Yes No SigAddress  SigTableEnd? Go to decode & execute Yes Trap OS Virtual to Physical Address Translation (Signature) Fetch Signature Virtual to Physical Address Translation Fetch Instructions Calculate Instruction Block Signature Using MISR and a Hidden Key Decrypt Signature from Memory Using a Hidden Key No Cache Line Fetched Yes No Decrypted Signature == Calculated Signature Yes Go to decode & execute Trap OS

  21. SIGCTK: Signature Verification I-Cache Lookup(PC) S-Cache Lookup (PC) No I-cache Miss? Signature Address Calculation Yes No SigAddress  SigTableEnd? Go to decode & execute Yes No Trap OS S-Cache Miss? Yes Virtual to Physical Address Translation (Signature) Fetch Signature Virtual to Physical Address Translation Fetch Instructions Calculate Instruction Block Signature Using MISR and a Hidden Key Decrypt Signature from Memory Using a Hidden Key No Cache Line Fetched Yes No Yes Decrypted Signature == Calculated Signature Trap OS Go to decode & execute

  22. Other Considerations • More complex memory hierarchy • Even less overhead • Dynamically linked libraries • Each DLL has signatures • Dynamically generated code • Code generator can generate the signatures • Replay attacks • Signature function includes relative address • Arc injection (return-into-libc) • Direct jumps: already protected • Indirect jumps: allowed target addresses embedded in signatures • Returns: secure stack

  23. st r2,(r3) mul r3,3 st r2,(r3) ld r1,(r3) add r1,r2 jmp (r1) Outline • Motivation • Techniques to Counter Code Injection Attacks • Architectures for Run-Time Verification of Software Integrity • Results • Conclusion

  24. Experimental Methodology • Secure installation • Program that adds signatures to binaries in ELF format • Architectural simulators • Expanded SimpleScalar, SimPanalyzer • Benchmarks • MiBench • MediaBench • Basicrypt

  25. Performance Overhead:Embedded Signatures, No S-Cache

  26. Performance Overhead: Embedded Signatures, With S-Cache

  27. Performance Overhead:Signatures in Table, No S-Cache

  28. Performance Overhead:Signatures in Table, With S-Cache

  29. Sensitivity to Bus Width, Core Speed, I-Cache Line Size • Lower overhead with wider buses, faster memory, longer I-cache lines • With relatively large caches, overhead  0 • SIGCE less sensitive than SIGCT, less overhead • SIGCED: an overall winner if the hardware budget does not allow for an S-cache • Overall, SIGCEK better than SIGCTK • What about energy overhead?

  30. Energy Overhead

  31. Energy Overhead

  32. st r2,(r3) mul r3,3 st r2,(r3) ld r1,(r3) add r1,r2 jmp (r1) Outline • Motivation • Techniques to Counter Code Injection Attacks • Architectures for Run-Time Verification of Software Integrity • Results • Conclusion

  33. Conclusions • Contributions • Proposed hardware support for code integrity • Evaluated four implementations • Run-time signature verification is a good choice for embedded systems • Low overhead • Protection from the whole class of code injection attacks • No compiler support necessary • Future work • Evaluate defense against other types of attacks • Data integrity

  34. Backup Slides

  35. Arc Injection • Direct jumps already protected • Two alternatives for indirect jumps (<20%) • Add more signature bits • Use some of the existing bits, but then allow only one indirect jump per block • Handling of multiple indirect jump targets • One bit in a signature determines if multiple targets • Addresses of multiple targets – in a hash table • Call/return • Secure stack

  36. SIGCE Address Calculation • True PC without padding: • Padding size: • True PC with padding:

More Related