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 DepartmentThe University of Alabama in Huntsville

Email: [email protected] 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

ld r1,(r3)add r1,r2jmp (r1)

st r2,(r3)mul r3,3st r2,(r3)

3

Motivation

Computer security today is a critical issue…even more so in the future

Today

Attackers in the past

Tomorrow

4

Motivation

Computer security landscape Confidentiality Integrity Availability

Arbitrary code execution

Code injection Arc injection

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.

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.

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.

Multiple heap-based buffer overflows in the imlib BMP image handler allow remote

attackers to execute arbitrary code via a crafted BMP file.

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.

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.

6

ProgramCode

Literal Pool

Heap

Stack

Arg #n

Buf[0]

...

Buf[n-1]

…

...

Arg #1

Return Address

Previous FP

Local var #1

Local var #2

Lower addresses

FP

functionarguments

localvariables

Higher addresses

Oldpointer

Stack Smashing

7

ProgramCode

Literal Pool

Heap

Stack

Arg #n

Buf[0]

...

Buf[n-1]

…

...

Arg #1

Return Address

Previous FP

Local var #1

Local var #2

Lower addresses

FP

functionarguments

localvariables

Higher addresses

Oldpointer

Stack Smashing

8

ProgramCode

Literal Pool

Heap

Stack

Arg #n

Buf[0]

...

Buf[n-1]

…

...

Arg #1

Return Address

Previous FP

Local var #1

Local var #2

Lower addresses

FP

functionarguments

localvariables

Higher addresses

Stack Smashing

Attack Code

Newpointer

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





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 instructions

and compared to stored signatures Signatures

Extended Multiple Input Signature Register (MISR) Advanced Encryption Standard (AES)

15

Mechanism for Trusted Instruction Execution

...

inc r0

st r2,(r3)

mul r3,3

st r2,(r3)

...

Original Code Signed Code

...

*&-!//*+)@

inc r0

st r2,(r3)

mul r3,3

st r2,(r3)

...MISRMISR

AES (Enc)

AES (Enc)

Secure Installation Trusted Code

MISRMISR

=?

Signature Match

AES (Dec)

AES (Dec)

*&-!//*+)@

Signature Fetch

InstructionFetch

Secure Execution

...

inc r0

st r2,(r3)

mul r3,3

st r2,(r3)

...

16

SIGCED SIGCEK SIGCTD SIGCTK

Taxonomy of Proposed Techniques

BinaryInstallation

Binary+ Sigs

Binary

Sigs

Installation

S-PlacementEmbedded (SIGCEx)

Table(SIGCTx)

S-Handling

KeepDiscard

S-Handling

Discard Keep

17

Hardware Support for Signature Verification

L1I-cache

L1 D-cache

MMU

Datapath

FPUs IF

Control IBSVU

Processor

K0 K1 Kn-1

D

ld

Q

Q

S

R

01 D

ld

Q

Q

S

R

01 D

ld

Q

Q

S

R

01

I0 I1 In-1

Init Init Init

. . .

Data bus

L1 I-cache

… …

… …

… …

… …

… …

SIGM

AESDecrypt

MISR

sig

sig

=?

S-matchS-Cache SC_hit

… …

18

SIGCED: Signature Verification

Address Translation

Go to decode & execute

Virtual to Physical Address Translation

Trap OS

Yes

I-Cache Lookup

Fetch Signature

Fetch Instructions

No

No

No

Yes

Yes


I-cache Miss?

Cache Line Fetched?

Decrypted Signature == Calculated Signature

Decrypt Signature from Memory

Using a Hidden Key

Calculate Instruction Block Signature Using MISR and a Hidden Key

Legend:

Parallel tasks

Steps supporting signature verification

19

SIGCEK: Signature Verification

Address Translation


Trap OS

Yes

I-Cache Lookup (PC)S-Cache Lookup (PC)

Fetch Signature

Fetch Instructions

No

No

No

Yes

Yes

No

Yes



I-cache Miss?

S-cache Miss?

Cache Line Fetched?



Using a Hidden Key


20


Virtual to Physical Address Translation(Signature)

Trap OS

Yes

Fetch Signature

Fetch Instructions

No

No

No

Yes

Yes


Signature Address Calculation


SIGCTD: Signature Verification

YesTrap OS

No


Using a Hidden Key


I-cache Miss?

Cache Line Fetched


SigAddress SigTableEnd?

I-Cache Lookup

21


Virtual to Physical Address Translation (Signature)


Using a Hidden Key


Trap OS

Yes

I-Cache Lookup(PC)S-Cache Lookup (PC)

Fetch Signature

Fetch Instructions

No

No

No

Yes

Yes


Signature Address Calculation


Yes

NoTrap OS

No

Yes

I-cache Miss?

SigAddress SigTableEnd?

S-Cache Miss?

Cache Line Fetched


SIGCTK: Signature Verification

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





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

SIGCED

0.98

1.00

1.02

1.04

1.06

1.08

1.10

1.12

1.14

1.16

1.18

32/slow 64/slow 32/fast 64/fast 32/slow 64/slow 32/fast 64/fast

System configuration: data bus width/processor core speed

Av

era

ge

of

CP

I/CP

I(B

as

e) 1K

2K

4K

8K

Line size 64B Line size 128B

26

Performance Overhead: Embedded Signatures, With S-Cache

SIGCEK

0.98

1.00

1.02

1.04

1.06

1.08

1.10

1.12

1.14

1.16

1.18



Av

era

ge

of

CP

I/CP

I(B

as

e) 1K

2K

4K

8K


27

Performance Overhead:Signatures in Table, No S-Cache

SIGCTD

0.98

1.00

1.02

1.04

1.06

1.08

1.10

1.12

1.14

1.16

1.18



Av

era

ge

of

CP

I/CP

I(B

as

e) 1K

2K

4K

8K


28

Performance Overhead:Signatures in Table, With S-Cache

SIGCTK

0.98

1.00

1.02

1.04

1.06

1.08

1.10

1.12

1.14

1.16

1.18



Av

era

ge

of

CP

I/CP

I(B

as

e) 1K

2K

4K

8K


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

I-cache 1K

0.90

0.95

1.00

1.05

1.10

1.15

1.20

1.25

1.30

1.35

blowfis

h_de

c

blowfis

h_en

ccjp

egdjp

eg

ecdh

b

ecds

ignb

ecds

verb

ecelg

decb

ecelg

encb

ispell

mpe

g2_e

ncqs

ort

rijnda

el_de

c

rijnda

el_en

c

strin

gsea

rch

aver

age

En

erg

y n

orm

ali

zed

to

Ba

se SIGCED

SIGCEK

31

Energy Overhead

I-cache 8K

0.90

0.95

1.00

1.05

1.10

1.15

1.20

1.25

1.30

1.35

blowfis

h_de

c

blowfis

h_en

ccjp

egdjp

eg

ecdh

b

ecds

ignb

ecds

verb

ecelg

decb

ecelg

encb

ispell

mpe

g2_e

ncqs

ort

rijnda

el_de

c

rijnda

el_en

c

strin

gsea

rch

aver

age

En

erg

y n

orm

aliz

ed t

o B

ase

SIGCED

SIGCEK

32

Outline





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

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:

)BlockSize

ePC-TextBas(SigSize PCtPCtemp 1

Padding size:

)(mod SigSizeBlockSizePageSizePagePad

True PC with padding:

PagePadPagePadPageSize-

xtBasetPCtemp-TetPCtemptPC

hardware support for code integrity in embedded processors

Documents