Hardware Support for Code Integrity in Embedded Processors
Hardware Support for Code Integrity in Embedded Processors Milena Milenković§, Aleksandar Milenković‡, Emil Jovanov Web. Sphere Process Server Performance, IBM ‡ The La. CASA 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 §
Outline n n n st r 2, (r 3) mul r 3, 3 st r 2, (r 3) ld r 1, (r 3) add r 1, r 2 jmp (r 1) Motivation Techniques to Counter Code Injection Attacks Architectures for Run-Time Verification of Software Integrity Results Conclusion 2
Motivation Computer security today is a critical issue …even more so in the future Attackers in the past Today Tomorrow 3
Motivation Computer security landscape n n n Confidentiality Integrity Availability Arbitrary code execution Code injection Arc injection 4
Many Opportunities For Arbitrary Code Execution n n Buffer overflow in n Multiple format string vulnerabilities in (1) neon MMClient. exe in Indiatimes n Multiple Messenger 6. 0 allowsheap-based remote 0. 24. 4 and earlier, and other attackersbuffer to causeoverflows a denial of in the imlib products that use neon including service (application BMP image crash) handlerand allow remote Cadaver, (3) Subversion, n (2) Stack-based buffer and possibly attackers execute (4) Open. Office, allow remote to arbitrary execute overflow in the URL parsing malicious Web. DAV servers to code via a long group namevia a crafted arbitrary code function in Gaim before 1. 3. 0 n Buffer overflow execute in argument to the arbitrary code. BMP file. Rename. Group allows remote attackers to WIDCOMM Bluetooth Connectivity function in the execute Software, as used in products such arbitrary code MMClient. Mundu. Messenger. 1 viaand an instant message (IM) with a as BTStack. Server 1. 3. 2. 7 Active. X object. large URL. 1. 4. 2. 10, Windows XP and Windows n Integer overflow 98 with MSI in Bluetooth Dongles, n Multiple buffer overflows in Buffer overflow inand the. HP JPEG IPAQ (io 5450 running Win. CE pixbuf_create_from_xpm Real. One Player, Real. One Player 2. 0, (JPG) parsing engine xpm. c) in in thethe XPMallows imageremote decoder 3. 0, attackers to Real. One Enterprise Desktop, and Microsoft Graphic Device Interface for gtk+ 2. 4. 4 (gtk 2) andarbitrary earlier, execute code Real. Player Enterprise allow remote Plus (GDI+)and component, gdk-pixbuf before 0. 22, allows via certain service requests. GDIPlus. dll, remote allows remote attackers to execute arbitrary attackers to execute attackers toarbitrary execute code via certain code via malformed (1). RP, (2). RT, arbitraryn_col code JPEG that enable a andvia cppa values image. heap-based buffer overflow. (3). RAM, (4). RPM or (5). SMIL files. 5
Stack Smashing Lower addresses Program Code Literal Pool Buf[0] local variables . . . Buf[n-1] Local var #2 Local var #1 Heap FP Previous FP Old pointer Return Address Arg #1 function arguments Stack . . . Arg #n … Higher addresses 6
Stack Smashing Lower addresses Program Code Literal Pool Buf[0] local variables . . . Buf[n-1] Local var #2 Local var #1 Heap FP Previous FP Old pointer Return Address Arg #1 function arguments Stack . . . Arg #n … Higher addresses 7
Stack Smashing Lower addresses Program Code Literal Pool Buf[0] local variables . . . Buf[n-1] Local var #2 Local var #1 Heap FP Previous FP Return Address Arg #1 function arguments Stack . . . Arg #n New pointer … Attack Code Higher addresses 8
Outline n n n ld r 1, (r 3) add r 1, r 2 jmp (r 1) Motivation Techniques to Counter Code Injection Attacks n n st r 2, (r 3) mul r 3, 3 st r 2, (r 3) Software-based, Static Software-based, Dynamic Hardware-based Architectures for Run-Time Verification of Software Integrity Results Conclusion 9
Software Techniques n Static techniques – in compile time n n n Automated tools: not scalable or not precise Programmers’ annotations: additional burden Dynamic techniques – in run time n Prevent attacks or make them less likely to succeed n Augment the code with run-time checks n “Safe dialects” of C n Code and address obfuscation n Monitoring of program behavior n Often require recompilation and incur significant performance and power overhead 10
Hardware-Based Defense Techniques n n n 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] 11
Outline n n n st r 2, (r 3) mul r 3, 3 st r 2, (r 3) ld r 1, (r 3) add r 1, r 2 jmp (r 1) Motivation Techniques to Counter Code Injection Attacks Architectures for Run-Time Verification of Software Integrity Results Conclusion 12
Architectures for Runtime Verification of Software Integrity n Goal: come up with architectural extensions that are n Universal n Cost-effective n Power efficient n Performance effective n Applicable to legacy software 13
Architectures for Runtime Verification of Software Integrity n n Common sign-and-verify mechanism Secure installation n n Secure execution n n Instruction block signatures are generated and stored together with the program binary Signatures are calculated from fetched instructions and compared to stored signatures Signatures n n Extended Multiple Input Signature Register (MISR) Advanced Encryption Standard (AES) 14
Mechanism for Trusted Instruction Execution Original Code Secure Installation Signed Code . . . inc r 0 AES (Enc) st r 2, (r 3) inc r 0 st r 2, (r 3) mul r 3, 3 st r 2, (r 3). . . *&-!//*+)@ MISR Secure Execution Signature Fetch *&-!//*+)@ . . . inc r 0 st r 2, (r 3) Instruction Fetch mul r 3, 3 st r 2, (r 3). . . Trusted Code AES (Dec) MISR . . . =? Signature Match 15
Taxonomy of Proposed Techniques Binary + Sigs Installation Binary Sigs S-Placement Embedded (SIGCEx) Table (SIGCTx) S-Handling Discard SIGCED S-Handling Keep SIGCEK Discard SIGCTD Keep SIGCTK 16
Hardware Support for Signature Verification Data bus Processor sig MMU L 1 D-cache Datapath FPUs IF Control … sig … L 1 I-cache … SIGM … … … MISR L 1 I-cache IBSVU AES Decrypt =? … … S-Cache SC_hit S-match 17
SIGCED: Signature Verification Legend: Parallel tasks I-Cache Lookup I-cache Miss? Steps supporting signature verification No Go to decode & execute Yes Address Translation Virtual to Physical Address Translation Fetch Signature Fetch Instructions No Cache Line Fetched? Yes No Calculate Instruction Block Signature Using MISR and a Hidden Key Decrypt Signature from Memory Using a Hidden Key Decrypted Signature == Calculated Signature Yes Trap OS Go to decode & execute 18
SIGCEK: Signature Verification I-Cache Lookup (PC) S-Cache Lookup (PC) I-cache Miss? No Yes Go to decode & execute Address Translation Virtual to Physical Address Translation No S-cache Miss? Yes Fetch Signature Fetch Instructions No No Cache Line Fetched? Yes Calculate Instruction Block Signature Using MISR and a Hidden Key Decrypt Signature from Memory Using a Hidden Key Decrypted Signature == Calculated Signature Yes Trap OS Go to decode & execute 19
SIGCTD: Signature Verification I-Cache Lookup No Yes Sig. Address Sig. Table. End? Go to decode & execute Signature Address Calculation I-cache Miss? No Yes Trap OS Virtual to Physical Address Translation (Signature) Fetch Signature Virtual to Physical Address Translation Fetch Instructions No Cache Line Fetched Calculate Instruction Block Signature Using MISR and a Hidden Key Decrypt Signature from Memory Using a Hidden Key Yes No Decrypted Signature == Calculated Signature Yes Trap OS Go to decode & execute 20
SIGCTK: Signature Verification I-Cache Lookup(PC) S-Cache Lookup (PC) No I-cache Miss? Yes Go to decode & execute Sig. Address Sig. Table. End? No Signature Address Calculation No Yes S-Cache Miss? Yes Trap OS Virtual to Physical Address Translation (Signature) Fetch Signature Virtual to Physical Address Translation Fetch Instructions No Cache Line Fetched Calculate Instruction Block Signature Using MISR and a Hidden Key Decrypt Signature from Memory Using a Hidden Key Yes No Yes Decrypted Signature == Calculated Signature Trap OS Go to decode & execute 21
Other Considerations n More complex memory hierarchy n n Dynamically linked libraries n n Code generator can generate the signatures Replay attacks n n Each DLL has signatures Dynamically generated code n n Even less overhead Signature function includes relative address Arc injection (return-into-libc) n n n Direct jumps: already protected Indirect jumps: allowed target addresses embedded in signatures Returns: secure stack 22
Outline n n n st r 2, (r 3) mul r 3, 3 st r 2, (r 3) ld r 1, (r 3) add r 1, r 2 jmp (r 1) Motivation Techniques to Counter Code Injection Attacks Architectures for Run-Time Verification of Software Integrity Results Conclusion 23
Experimental Methodology n Secure installation n n Architectural simulators n n Program that adds signatures to binaries in ELF format Expanded Simple. Scalar, Sim. Panalyzer Benchmarks n n n Mi. Bench Media. Bench Basicrypt 24
Performance Overhead: Embedded Signatures, No S-Cache 25
Performance Overhead: Embedded Signatures, With S-Cache 26
Performance Overhead: Signatures in Table, No S-Cache 27
Performance Overhead: Signatures in Table, With S-Cache 28
Sensitivity to Bus Width, Core Speed, I-Cache Line Size n n n 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? 29
Energy Overhead 30
Energy Overhead 31
Outline n n n st r 2, (r 3) mul r 3, 3 st r 2, (r 3) ld r 1, (r 3) add r 1, r 2 jmp (r 1) Motivation Techniques to Counter Code Injection Attacks Architectures for Run-Time Verification of Software Integrity Results Conclusion 32
Conclusions n Contributions n n n Run-time signature verification is a good choice for embedded systems n n Proposed hardware support for code integrity Evaluated four implementations Low overhead Protection from the whole class of code injection attacks No compiler support necessary Future work n n Evaluate defense against other types of attacks Data integrity 33
Backup Slides
Arc Injection n n Direct jumps already protected Two alternatives for indirect jumps (<20%) Add more signature bits n Use some of the existing bits, but then allow only one indirect jump per block Handling of multiple indirect jump targets n One bit in a signature determines if multiple targets n Addresses of multiple targets – in a hash table n n n Call/return n Secure stack 35
SIGCE Address Calculation n True PC without padding: n Padding size: n True PC with padding: 36
- Slides: 36