Defending embedded systems against buffer overflow attacks via hardware software
Download
1 / 63

Defending Embedded Systems Against Buffer-Overflow Attacks via Hardware/Software - PowerPoint PPT Presentation

Defending Embedded Systems Against Buffer-Overflow Attacks via Hardware/Software Zili Shao, Ph.D. Candidate Dept. of Computer Science University of Texas at Dallas Email: zlshao@student.utdallas.edu Hompage: http://www.utdallas.edu/~zlshao Stack Overflow – Intel Low Address

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha

Download Presentationdownload

Defending Embedded Systems Against Buffer-Overflow Attacks via Hardware/Software

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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Defending embedded systems against buffer overflow attacks via hardware software l.jpg

Defending Embedded Systems Against Buffer-Overflow Attacks viaHardware/Software

  • Zili Shao, Ph.D. Candidate

  • Dept. of Computer Science

  • University of Texas at Dallas

  • Email: zlshao@student.utdallas.edu

  • Hompage: http://www.utdallas.edu/~zlshao


Stack overflow intel l.jpg

Stack Overflow – Intel

Low Address

  • copy(char *msg)

  • {

  • char buf[5];

  • strcpy(buf, msg);

  • }

  • main(int argc, char *argv[])

  • {

  • if( argc> 1)

  • copy(argv[1]);

  • }

Buf[0]

Buf[1]

Attack Code

Buf[2]

Buf[3]

Buf[4]

bp

main-bp

ret addr.

argv[1]

bp

main-ret-bp

main-ret-bp

before

High Address


Stack overflow sun sparc l.jpg

Stack Overflow – Sun Sparc

sp

  • Harder than Intel, still easy

  • Ret. Addr. in register i7

  • 4-byte alignment

  • copy(char *msg)

  • {

  • char buf[5];

  • strcpy(buf, msg);

  • }

  • main(int argc, char *argv[])

  • {

  • if( argc> 1)

  • copy(argv[1]);

  • }

Current

Register

Windows

buf[0]

buf[4]

fp

sp

l 0

Attack

Code

Current Register Windows

i6 - fp’s value

i7 - ret addr. from main()

i 6

i 7

fp

High Address

Before

call copy()

After

call copy()


Organization l.jpg

Organization

  • Motivation

  • Background for Buffer Overflow

  • The Previous Work

  • Hardware/Software Defender (HSDefender)

  • Conclusion


Part i motivation l.jpg

Part I: Motivation


Buffer overflow attack causes serious problems l.jpg

Buffer Overflow Attack Causes Serious Problems

  • At least 50% of today's widely exploited vulnerabilities are buffer overflows and the ratio is increasing over time.

  • In 2003, buffer overflow related vulnerabilities account for 85.7% (24 of 28) of the serious vulnerability reports from CERT advisories.

  • Almost all effective worms use this vulnerability to attack.


Worm buffer overflow l.jpg

Worm & Buffer Overflow

  • Almost all the worms used it. Some famous examples caused serious damages:

    • Internet worm in 1988 - Buffer overflow in fingerd

    • Code Red, Code Red II, etc. in 2001, MS Index Service DLL

    • Sapphire (SQL Slammer) in Jan. 2003, MS SQL Server

    • MS Blaster in August 2003, MS DCOM RPC

    • Witty Worm in Mach 20, 2004, ISS Protocol Analysis

  • Model for ICQ Instant Message Protocol

    • Sasser Worm in May 2004, LSASS buffer overflow


2003 cert serious vulnerability reports l.jpg

2003 CERT Serious Vulnerability Reports

  • 2003 serious vulnerability reports from CERT (Total: 28, buffer overflow-related: 24)

    • 19 directly used stack overflow or heap overflow

    • 2 used integer overflow that causes heap overflow

    • 2 used memory de-allocation bug that causes heap overflow

    • 1 used format string vulnerabilities that is exploited similar to buffer overflow

    • The other 4 reports are related:

      - Protocol-based attacks - Weak password attacks for home computers

      - CISCO packet error - kmod/ptrace bug in Linux.


The security for critical systems l.jpg

The Security for Critical Systems

  • Buffer overflow attack is serious for special purpose systems

    • Routers

    • Network base stations, Wireless devices

  • Important security concern for networked embedded systems:

    • a battleship with thousands of embedded processors

    • an aircraft control system

    • a nuclear plant with network embedded controller

  • For such critical or military application, the hostile penetration by using buffer overflow will cause serious damages


Software in embedded systems l.jpg

Software in Embedded Systems

  • Most software written in assembly or C

  • Usually no access control mechanism

  • Maximum-degree security is required.

  • Strict requirements:

    • Timing: Real time system – Performance overhead

    • Limited memory space – Code Size

    • Power consumption, area, hardware cost, etc.

  • Off-the-shelf software components – Source code may not be available for a system integrator.


The design flow from system integrator s point view l.jpg

The Design Flow from System Integrator’s point view

System Integrator

1. Requirements & Rules

Third-party Software Developer

Software Components

3. Checking

2. Generate

1. Requirements & Rules

Third-party Software Developer

Software Components

3. Checking

2. Generate


Effective protection efficient checking l.jpg

Effective Protection & Efficient Checking

  • A solution should solve two problems:

  • A complete protection from buffer overflow attacks and the simple rules so software developers can easily follow.

  • An efficient checking mechanism for a system integrator.


Part ii background for buffer overflow l.jpg

Part II: Background for Buffer Overflow


Types of buffer overflow l.jpg

Types of Buffer Overflow

Memory Layout

  • Stack overflow

  • the most common case

  • Heap/bss overflow

  • more and more popular

  • Related vulnerabilities:

  • format-string vulnerability

  • integer overflow

Low

text section

Address

data section

bss section

heap

stack

High

Env. Variables & Command line Parameters

Address


Basic ideas of stack overflow l.jpg

Basic Ideas of Stack Overflow

  • Find a program with stack-overflow vulnerability

  • Prepare a buffer

    • Contain a hostile code such as to execute a “shell”

    • Long enough to overflow a stack frame so the return address is replaced.

  • Send this buffer as the input to the attacked program

  • Make the new return address jump to the inserted hostile code that was originally put in the buffer


Stack overflow intel16 l.jpg

Stack Overflow – Intel

Low Address

  • copy(char *msg)

  • {

  • char buf[5];

  • strcpy(buf, msg);

  • }

  • main(int argc, char *argv[])

  • {

  • if( argc> 1)

  • copy(argv[1]);

  • }

Buf[0]

Buf[1]

Attack Code

Buf[2]

Buf[3]

Buf[4]

bp

main-bp

ret addr.

argv[1]

bp

main-ret-bp

main-ret-bp

before

High Address


Stack overflow sun sparc17 l.jpg

Stack Overflow – Sun Sparc

sp

  • Harder than Intel, still easy

  • Ret. Addr. in register i7

  • 4-byte alignment

  • copy(char *msg)

  • {

  • char buf[5];

  • strcpy(buf, msg);

  • }

  • main(int argc, char *argv[])

  • {

  • if( argc> 1)

  • copy(argv[1]);

  • }

Current

Register

Windows

buf[0]

buf[4]

fp

sp

l 0

Attack

Code

Current Register Windows

i6 - fp’s value

i7 - ret addr. from main()

i 6

i 7

fp

High Address

Before

call copy()

After

call copy()


1 st trick for stack overflow intel l.jpg

1st Trick for Stack Overflow (Intel)

Low Address

2nd overflow: we can write anything there

  • Example program:

  • main(int argc, char *argv[])

  • {

  • char *p;

  • char buf[512];

  • p=buf;

  • strcpy(p,argv[1]);

  • strcpy(p,argv[2]);

  • printf(“Finish!\n”);

  • }

Buf[0]

Buf[511]

GOT

p

bp

old-bp

1st overflow: we can point p to anywhere

ret addr.

argc

argv[1]

argv[2]

High Address


2 nd trick for stack overflow intel l.jpg

2nd Trick for Stack Overflow (Intel)

Low Address

  • int good(const char *str);

  • main(int argc, char *argv[])

  • {

  • int (*fptr)(const char *str);

  • char buf[512];

  • fptr=(int (*)(const char *str)) good;

  • strcpy(buf,argv[1]);

  • (void) (*fptr)( argv[2] );

  • }

  • int good(const *str)

  • {

  • printf(“I am a good fun.\n”);

  • return 0;

  • }

Buf[0]

Attack

Code

Buf[511]

fptr

bp

old-bp

ret addr.

argc

argv[1]

argv[2]

High Address


Heap bss overflow l.jpg

Heap/bss Overflow

  • int good(const char *str);

  • main(int argc, char *argv[])

  • {

  • static char buf[512];

  • static int (*fptr)(const char *str);

  • fptr=(int (*)(const char *str)) good;

  • strcpy(buf,argv[1]);

  • (void) (*fptr)( argv[2] );

  • }

  • int good(const *str)

  • {

  • printf(“I am a good fun.\n”);

  • return 0;

  • }

BSS

Low

Address

Buf[0]

Attack

Code

Buf[511]

fptr

High

Address


Part iii the previous work l.jpg

Part III: The Previous Work


Previous work summary l.jpg

Previous Work – Summary

  • Stack Smashing Protection

    • Non-executable stack

    • Libsafe

    • StackShield

    • Compiler-assisted: StackGuard, Microsoft GS, IBM SSP, StackGhost

  • Buffer overflow vulnerability checking

    • The static checking

    • The dynamic checking

  • Array & Pointer Protection

    • Array boundary checks

    • PointerGuard

  • Pure Hardware Approach: XOM


Previous work stack smashing protection l.jpg

Previous Work – Stack Smashing Protection

  • Non-executable stack

    • Method: Make the stack be non-executable

    • Not effective. The attack code can be run from somewhere else, for example, heap/bss attacks

  • Libsafe

    • Method: Intercept vulnerable library functions and

      force verification of critical elements of stacks

    • Very limited:

      - Do not work for user defined functions

      - A lot of attacks that are correct from the verification of

      vulnerable library functions

      - Can not protect heap/bss smashing attacks


Slide24 l.jpg

Previous Work – Stack Smashing Protection

  • Stack Shield - Runtime Stack Protection

  • Method:

    • Store the return address into a different stack

    • Protect the integrity of return addresses

  • Disadvantages:

    • Can only prevent from the attacks that need to overwrite the return address.

    • Can not defend the attacks like 1st trick and 2nd trick

    • Can not defend heap/bss overflow


Slide25 l.jpg

Previous Work – Stack Smashing Protection

  • StackGuard – Compiler-assisted Runtime Stack Protection

  • Method:

    • Changes the prologue and epilogue of a function call.

    • Push a canary (such as NULL) before the return address in the prologue and check whether the canary has been changed in the epilogue

    • Preventing the attacks that overwrite the return address.

  • Disadvantages

    • Frame pointer is not protected

    • Can not defend the attacks like 1st trick and 2nd trick

    • Can not defend heap/bss overflow attacks


Slide26 l.jpg

Previous Work – Stack Smashing Protection

  • IBM SSP - Compiler-assisted Runtime Stack Protection

  • Method: similar to StackGuard.

    • Put random canary on top of frame pointer and return address

    • Check before the function is returned. (both fp and ret addr are “protected.”)

    • Reorder local variables so the pointers cannot be overwritten.

  • Disadvantages

    • Can not defend against heap/BSS overflow attack

    • For some cases, pointers in local variables and function arguments cannot be reordered


Previous work buffer overflow checking l.jpg

Previous Work – Buffer Overflow Checking

  • The static checking method

    • Use software tools to analyze the code.

    • The buffer overflow detection problem is undecideable.

    • Can not provide a complete solution

  • The dynamic checking method: Program Testing

    • Executing program with specific inputs.


Previous work pointer protection l.jpg

Previous work – Pointer Protection

  • Array & Pointer Boundary Checking

    • Compiler adds instructions

    • Too much overhead

    • Security Checking is not considered

  • PointerGuard: encrypting pointer values while they are in memory and decrypting pointer values before de-reference.

    • Easy to cause system crash if system is compromised

    • Security Checking is not considered


Pure hardware approach xom l.jpg

Pure Hardware Approach: XOM

  • CPU manufacturer puts a unique pair of private key and public key.

  • A secret key is generated which is used to encrypt all the code and data external to the CPU.

  • Strong protection for code confidentiality and integrity.

  • Large hardware overhead.

  • Even it is not enough: system will be crashed when a warm exploits a stack overflow vulnerability.

  • Our approach can be combined with XOM.


Part iii our hsdefender technique hardware software defender l.jpg

Part III: Our HSDefender Technique (Hardware/Software Defender)


The basic ideas l.jpg

The Basic Ideas

  • Hardware / Software Co-design is a common practice in embedded system design.

  • Design new special “secure call” instruction

  • Require software developers only use “secure call” instructions for function calls.

  • The checking for a system integrator is very simple. It is close to one-pass O(n) scan where n is the number of instructions in the program.


Hsdefender hardware software defender l.jpg

HSDefender: Hardware/Software Defender

  • HSDefender provides an effective solution by the combination of hardware (new instructions) and compiler

  • HSDefender protects any jump pointer

  • A jump pointer is a location that stores an address to a codesegment, and the program may jump to the address stored in ajump pointer. A jump pointer can be:

    • return address in a stack frame

    • a function pointer

    • an entry in a shared function pointer table such as GOT.


Classification of buffer overflow attacks l.jpg

Classification of Buffer Overflow Attacks

  • Stack smashing attacks

    • Most common attacks

    • Change return address or frame pointer so hostile code can be executed.

  • Function pointer attacks:

    • Exploit a function pointer by stack/heap/bss overflow to point to the attack code

    • Further classify into two sub-categories:

      - Shared function pointer attacks

      - Local function pointer attacks


Function pointer attacks l.jpg

Function Pointer Attacks

  • Shared function pointer attacks

    • It is common to have a table of function pointers that point to

      each shared library functions such as GOT.

    • Similar to Trick 1. Change some function pointers there by first overflowing stack, heap or BSS.

  • Local function pointer attacks

    • First overflow stack, heap, or BSS so a pointer that points to a local function pointer is changed.

    • Change the function pointer such that it points to the prepared hostile code. Similar to Trick 2.


Two components of hsdefender l.jpg

Two Components of HSDefender

  • Stack Smashing Attack Protection - two methods:

    • Hardware Boundary Check

    • Secure Function Call

  • Function Pointer Attack Protection

    • New secure instruction for jumping function pointer: SJMP


Stack smashing protection method 1 hardware boundary check basic idea l.jpg

Stack Smashing Protection - Method 1: Hardware Boundary Check - Basic Idea

  • Basic Idea:

    • Hardware boundary check performs address check with current frame pointer

    • “address check” is done in parallel with a “write” operation.

    • If the target address is equal to or bigger than the value of frame pointer, a buffer overflow exception is produced.


Hardware boundary check l.jpg

Hardware Boundary Check

low

local vars

des-addr should be

less than fp

previous fp

fp

return addr.

Compare with fp

arguments.

write to des-addr

high


Stack smashing protection method 1 hardware boundary check requirements l.jpg

Stack Smashing Protection - Method 1: Hardware Boundary Check - Requirements

  • Hardware boundary checking protects:

    • Frame pointers

    • Return addresses

    • Function arguments

  • Requirements for software developers:

    • If a variable needs to be changed in its child function, then define it as global or static variable or dynamic memory allocation.

    • Using fp in call convention is required.


Stack smashing protection method 1 hardware boundary check analysis l.jpg

Stack Smashing Protection - Method 1: Hardware Boundary Check - Analysis

  • Easy security checking for system integrator:

  • Execute the tested program and see whether the stack overflow exception occurs.

  • System crash can be avoid:

  • Call a recovery program in the stack overflow exception handler program.

  • The writing and the boundary checking can be executed parallel; therefore, there is almost no performance overhead.

  • The extra protection code are not needed


Stack smashing protection method 2 secure function call basic idea l.jpg

Stack Smashing Protection - Method 2: Secure Function Call – Basic Idea

  • Basic Idea:

    • Design two secure function call instructions: “SCALL” and “SRET” to replace old “CALL” and “RET” instructions.

    • Each process is randomly assigned a key when the process is created and the key is kept in a special register R.

    • SCALL – Generate a signature of the return address with

  • the key when a function is called.

    • SRET – Check the signature with the key before returning from a function.


Secure function call l.jpg

Secure Function Call

low

local vars

previous fp

Generate a

Check the

signature

signature from

signature and

return address

return address

return addr.

when call

when return

arguments.

high


Stack smashing protection method 2 secure function call scall design l.jpg

Stack Smashing Protection - Method 2: Secure Function Call – “SCALL” Design

  • “SCALL” has four operations:

    • Push the return address into the stacks;

    • Generate a signature S by S=XOR(R,Ret), where R stores the key and Ret is the return address;

    • Push S into the stack;

    • Put the address of function into Program Counter.


Stack smashing protection method 2 secure function call sret design l.jpg

Stack Smashing Protection - Method 2: Secure Function Call – “SRET” Design

  • “SRET” has 3 operations:

    • Load T1(SP) T2  (SP+4) where T1, T2 are two temporary registers storing the signature and the return address that were pushed by SCALL.

    • Calculate S’=XOR(R, T2).

    • Compare S and S’:

      If equal, move T2 to the Program Counter;

  • Otherwise, generate a stack overflow exception.


Stack smashing protection method 2 secure function call analysis l.jpg

Stack Smashing Protection - Method 2: Secure Function Call – Analysis

  • The key is randomly generated for each process, it is extremely hard for a hacker to guess the key.

  • If the return address is changed by a hacker, it can be found

  • since two signatures S and S’ will be different.

  • This is more powerful than StackGuard using a canary, which can be exploited by skipping around the canary to change ret. addr.


Stack smashing protection method 2 secure function call analysis45 l.jpg

Stack Smashing Protection - Method 2: Secure Function Call – Analysis

  • Easy security checking for system integrators:

    • Whether there are the original “CALL” instructions in a component based on binary code

    • Execute it to see whether there is stack overflow exception.

  • System Crash can be avoided by calling a recovery program in the exception handler program.


Function pointer protection basic idea l.jpg

Function Pointer Protection – Basic Idea

  • New secure instructions for the call through function pointer:

    • Call_SJMP: Ordinary Call (Method 1) + SJMP

    • Scall_SJMP: Secure Call (Method 2) + SJMP

  • “SJMP” has two operations:

    • Generate the Real Address by XORing the input address with

  • the key

    • Compare the instruction in the XORed address with a pre-defined flag instruction:

  • If they are equal, jump to this XORed address;

  • Otherwise, issue a buffer overflow exception.


Function pointer protection requirements l.jpg

Function Pointer Protection – Requirements

  • Two requirements for software developers:

    • Software developers must use these secure instructions (“Call_SJMP” or “Scall_SJMP”) for the calls through function pointers.

    • When assigning the address of function to a function pointer, the address is first XORed with the key and then the XORed result is assigned to the function pointer.


Function pointer protection analysis l.jpg

Function Pointer Protection – Analysis

  • The attack code can not be activated if a hacker changes a function pointer and makes it point to the attack code

  • The real address that the program will jump to is the XORed address with the key.

  • The system crash can be avoid in most cases by comparing the instruction in the XORed address with the flag

  • A system integrator can easily check whether “Call_SJMP” or “Scall_SJMP” has been used in all function calls that use function pointers.


Call using bl branch and link l.jpg

Call Using BL (Branch and Link)

  • Processors such as ARM, PowerPC, etc. use BL (Branch and Link) call a function, which puts return address into a register lr before Program Counter is changed. And BLR to copy LR to PC.

  • Secure CALL: use function pointer protection approach to encrypt the value of the return address before it is stored to lr.

  • Secure RET: decrypt the value and/or check the flag instruction before PC is reset.


Case study a fft ifft program l.jpg

Case Study: A FFT/IFFT Program

  • /* Check whether a pointer is empty*/

  • void CheckPointer( ) { }

  • /* FFT/ IFFT Transformation */

  • void fft_float( ) {

  • /* The added function pointer*/

  • void (* fptr) (void *p, char *name);

  • ……

  • /* Assign CheckPointer to fptr */

  • fptr = (void (*) (void *p, char * name ))

  • CheckPointer;

  • /* Perform FFT/IFFT; need to call CheckPointer*/

  • ……

  • (void *) fptr(…);

  • ……

  • }

  • main( int argc, char ** argv)

  • {

  • /* Prepare the inputs */

  • ……

  • /* Call fft_float */

  • fft_float( );

  • ……

  • }


Case study protect by hsdefender intel l.jpg

Case Study: Protect by HSDefender (Intel)

Original

Method 1

Method 2

  • CheckPointer:

  • pushl %ebp

  • ……

  • leave

  • ret

  • fft_float:

  • pushl %ebp

  • ……

  • movl $CheckPointer, -4 (%ebp)

  • movl -4(%ebp), %eax

  • call *%eax

  • ……

  • leave

  • ret

  • main:

  • pushl %ebp

  • ……

  • call fft_float

  • ……

  • leave

  • ret

  • CheckPointer:

  • pushl %ebp

  • ……

  • leave

  • ret

  • fft_float:

  • pushl %ebp

  • ……

  • movl $CheckPointer, -4 (%ebp)

  • xorl R, -4 (%ebp)

  • ……

  • Call_SJMP *%eax

  • ……

  • leave

  • ret

  • main:

  • pushl %ebp

  • ……

  • call fft_float

  • ……

  • leave

  • ret

  • CheckPointer:

  • pushl %ebp

  • ……

  • leave

  • ret

  • fft_float:

  • pushl %ebp

  • ……

  • movl $CheckPointer, -4 (%ebp)

  • xorl R, -4 (%ebp)

  • ……

  • Scall_SJMP *%eax

  • ……

  • leave

  • sret

  • main:

  • pushl %ebp

  • ……

  • scall fft_float

  • ……

  • leave

  • sret


Sun sparc like processors l.jpg

Sun-Sparc-like Processors

  • The return address of the current function is stored in a special register instead of in the stack in Intel-x-86-like processors.

  • The return address of the caller is still stored in the stack.

low

sp

Current

Stack

local variables

Frame

fp

other registers

previous fp

Previous

Stack

previous Ret. Addr.

Frame

arguments

local variables

high


Protect by hsdefender sun sparc l.jpg

Protect by HSDefender (Sun Sparc)

Original

Method 1

Method 2

  • CheckPointer:

  • save %sp, -112, %sp

  • ……

  • ret

  • restore

  • fft_float:

  • save %sp, -248, %sp

  • ……

  • sethi % hi (CheckPointer), % o0

  • or % o0, % lo(CheckPointer), % o0

  • st % o0, [%fp-20]

  • ……

  • ld [%fp-20], % o1

  • call % o1, 0

  • ……

  • ret

  • restore

  • main:

  • save %sp, -160, %sp

  • ……

  • call fft_float

  • ……

  • ret

  • restore

  • CheckPointer:

  • save %sp, -112, %sp

  • ……

  • ret

  • restore

  • fft_float:

  • save %sp, -248, %sp

  • ……

  • sethi % hi (CheckPointer), % o0

  • or % o0, % lo(CheckPointer), % o0

  • xor % o0, % R, % o0

  • st % o0, [%fp-20]

  • ……

  • ld [%fp-20], % o1

  • call_sjmp % o1, 0

  • ……

  • ret

  • restore

  • main:

  • save %sp, -160, %sp

  • ……

  • call fft_float

  • ……

  • ret

  • restore

  • CheckPointer:

  • save %sp, -112, %sp

  • ……

  • sret

  • restore

  • fft_float:

  • save %sp, -248, %sp

  • ……

  • sethi % hi (CheckPointer), % o0

  • or % o0, % lo(CheckPointer), % o0

  • xor % o0, % R, % o0

  • st % o0, [%fp-20]

  • ……

  • ld [%fp-20], % o1

  • scall_sjmp % o1, 0

  • ……

  • sret

  • restore

  • main:

  • save %sp, -160, %sp

  • ……

  • scall fft_float

  • ……

  • sret

  • restore


Security comparison of two methods of stack smashing attack protection l.jpg

Security Comparison of Two Methods of Stack Smashing Attack Protection

  • Security:

    • Both methods guarantee that it is extremely hard to exploit stack overflow vulnerabilities.

    • Hardware Boundary Check provides better security since it protects frame pointer, arguments, return address.

  • Hardware Cost:

    • Both need simple hardware to do comparison


Hardware cost comparison of two methods of stack smashing attack protection l.jpg

Hardware Cost Comparison of Two Methods of Stack Smashing Attack Protection

  • Hardware Cost: Both use simple hardware

  • Hardware design and simulation by VHDL (16 bit word length) in RTL

  • with Synopsis

Exception

To CPU

Exception

Move

Target

Address

Target

[0:15]

Address

[0:15]

Comparator

fp

Comparator

[0:15]

fp

[0:15]

(b) Method 2

(a) Method 1


Hardware cost comparison of two methods of stack smashing attack protection56 l.jpg

Hardware Cost Comparison of Two Methods of Stack Smashing Attack Protection


Timing performance comparison of two methods of stack protection l.jpg

Timing Performance Comparison of Two Methods of Stack Protection

  • Hardware Boundary Check:

    • Virtually no overhead.

    • Use additional hardware to parallel perform comparison while the write operation can be performed at the same time at MEM phase.

  • Secure Function Call:

    • 5 extra clock cycles for each function call.

    • SCALL – 2 extra, SRET – 3 extra clock cycles.


Recommendation for two methods of stack smashing attack protection l.jpg

Recommendation for Two Methods of Stack Smashing Attack Protection


Hardware of function pointer protection l.jpg

Hardware of Function Pointer Protection

  • Function pointer protection need simple hardware

    • Comparator

    • XOR-Operation Unit

  • Use the similar hardware as Secure Function Call


The security comparison between hsddefender and the previous work l.jpg

The Security Comparison between HSDdefender and the previous work


The experiments for timing performance l.jpg

The Experiments for Timing Performance

  • An embedded enchmarks from Mibench.

  • Test Platform: The SimpleScalar/ARM Simulator that is configured as the StrongARM-110 microprocessor.

  • ARM-elf executables using a GNU ARM-elf cross compiler is used for various benchmarks from Mibench.

  • The execution times of the original program and the program protected by HSDefender are compared.


Slide62 l.jpg

Experimental Results


Conclusion l.jpg

Conclusion

  • Combining hardware/compiler, HSDefender provides different levels of strength to solve two types of attacks:

    • For the most common stack smashing attacks, HSDefender provides a complete protection.

    • For the function pointer attack, it makes an hacker extremely hard to change a function pointer leading to his hostile code. And system is hard to be crashed even it is compromised.

  • With little overhead, it can be applied to many critical real-time systems.

  • HSDefender provide an efficient method for a system integrator to check whether a component has been protected.


ad
  • Login