Hardware Support for Code Integrity in Embedded Processors

1
Hardware Support for Code Integrity in Embedded
Processors

• Milena Milenkovic, Aleksandar Milenkovic, Emil
  Jovanov
• WebSphere Process Server Performance, IBM
• The LaCASA Laboratory
• Electrical and Computer Engineering Department
• The University of Alabama in Huntsville
• Email milenka_at_ece.uah.edu
• Web http//www.ece.uah.edu/milenka
• http//www.ece.uah.edu/lacasa

2
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 issueeven
  more so in the future

Attackers in the past
Today
Tomorrow
4
Motivation

• Computer security landscape
• Confidentiality
• Integrity
• Availability

5
Many Opportunities For Arbitrary Code Execution

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

• 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
Buf0
...
Literal Pool
localvariables
Bufn-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
Buf0
...
Literal Pool
localvariables
Bufn-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
Buf0
...
Literal Pool
localvariables
Bufn-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
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
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
Mechanism for Trusted Instruction Execution
16
Taxonomy of Proposed Techniques
17
Hardware Support for Signature Verification
18
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
Decrypt Signature from Memory Using a Hidden Key
Calculate Instruction Block Signature Using
MISR and 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
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 OverheadEmbedded Signatures, No
S-Cache
26
Performance Overhead Embedded Signatures, With
S-Cache
27
Performance OverheadSignatures in Table, No
S-Cache
28
Performance OverheadSignatures 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
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 (lt20)
• 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