security protection and checking in embedded system integration against buffer overflow attacks zili...
Post on 20-Dec-2015
219 views
TRANSCRIPT
Security Protection and Checking in Embedded System Integration
Against Buffer Overflow Attacks
Zili Shao, Chun Xue, Qingfeng Zhuge, Edwin H.-M. Sha
International Conference on Information Technology : Coding and Computing
Presenter： Guang-Bao Lin
Outline
What’s the problem? Abstract Review: Stack Buffer overflow Related Work Hardware/Software Defender
Boundary Check Secure Function Call
Compare the two methods Conclusion
Outline
What’s the problem?
With more embedded systems networked, Security becomes an important research problem. “buffer overflow attack” takes over 50% of today
’s widely exploited vulnerabilities.
How to solve the problem? The author proposed HSDefender technique to def
end system against buffer overflow attacks.
What’s the problem?
Abstract
ith more embedded systems networked, it becomes an important research problem to effectively defend embedded systems against buffer overflow attacks and efficiently check if systems have been protected. In this paper, we propose the HSDefender (hardware/software Defender) technique that considers the protection and checking together to solve this problem. Our basic idea is to design a secure instruction set and require third-party software developers to use secure instructions to call functions. Then the security checking can be easily performed by system integrators even without the knowledge of the source code.
e first classify buffer overflow attacks into two categories, stack smashing attacks and function pointer attacks, and then provide two corresponding defending strategies. We analyze the HSDefender technique in respect of hardware cost, security, and performance, and experiment with it on the SimpleScalar/ARM simulator using benchmarks from MiBench. The results show that HSDefender can defend a system against more types of buffer overflow attacks with less overhead compared with the previous work.
WW
WW
Abstract
Review: Stack
A stack will be created including argument, return address, and buffer space
char *func(char *msg) { int var1; char buf[80];
strcpy(buf, msg); return msg;}
Int main( int argv,char **argc) { char *p; p = func(argc[1]); exit(0);}
main( )’s arguments
start( )/main( ) 12 bytes
return address
saved %ebp
p
func( )’s arguments
return address
saved %ebp
var1
buf
main( )
main( )
main( )
main( )/func( )
func( )
func( )
func( )
func( )
4 bytes
4 bytes
4 bytes
4 bytes
4 bytes
4 bytes
4 bytes
80 bytes
lower address
higher address
Introduce buffer overflow attack
Buffer overflow (1) If the filler is bigger than the buffer size…
main( )’s arguments
start( )/main( ) 12 bytes
return address
saved %ebp
p
func( )’s arguments
return address
saved %ebp
var1
buf
main( )
main( )
main( )
main( )/func( )
func( )
func( )
func( )
func( )
4 bytes
4 bytes
4 bytes
4 bytes
4 bytes
4 bytes
4 bytes
80 bytes
lower address
higher address
char *func(char *msg) { int var1; char buf[80];
strcpy(buf, msg); return msg;}
Int main( int argv,char **argc) { char *p; p = func(argc[1]); exit(0);}
char argc[255]; for (i=0;i<255;i++) argc[i] = ‘A’ ;//0x41h
Introduce buffer overflow attack
Buffer overflow (2) If the filler is bigger than the buffer size… Buffer overflow occurs (higher space will be
overwritten)
main( )’s arguments
start( )/main( ) 12 bytes
return address
saved %ebp
p
func( )’s arguments
return address
saved %ebp
var1
buf
main( )
main( )
main( )
main( )/func( )
func( )
func( )
func( )
func( )
4 bytes
4 bytes
4 bytes
4 bytes
4 bytes
4 bytes
4 bytes
80 bytes
lower address
higher address
char *func(char *msg) { int var1; char buf[80];
strcpy(buf, msg); return msg;}
Int main( int argv,char **argc) { char *p; p = func(argc[1]); exit(0);}
char argc[255]; for (i=0;i<255;i++) argc[i] = ‘A’ ;//0x41h
0x41414141h
0x41414141h
0x41414141h
0x41414141h
0x41414141h
0x41414141h
0x41414141h
0x41414141h
0x41414141h
Introduce buffer overflow attack
What does “buffer-overflow attack” do ?
argument
return addr
buffer
A wrong return address may cause a hacker’s shell been executed.
Before overflow
Overwrite
0x41414141h
buffer(overflow) Hacker’sShell Code
0x41414141h
After overflow
Execute hacker’s shell (with root’s authority)
-_-||
Introduce buffer overflow attack
Related Work
Adding checking instruction (this paper) StackGuard
Runtime boundary checking Shortage: big performance overhead
Analyzing C code by S/W tools Shortage: incomplete and imprecise
Related work
Problem of S/W solution
Performance overhead is too much
Too many old software have this problem and it’s impossible to solve them all in Software way
Related work
Hardware/Software Defender
Hardware modification Design a secure instruction set and require third-
party software developers to use secure instructions to call functions.
Two components Stack smashing protection (return address)
• Method 1: Boundary Check• Method 2: Secure Function Call
Function pointer protection (function pointer)
Work of this paper
Component 1: Stack Smashing ProtectionMethod 1: Boundary Check
main( )’s argumentsmain( )
return address
saved %ebp
p
func( )’s arguments
return address
saved %ebp
var1
buf
main( )
main( )
main( )
func( )
func( )
func( )
func( )
func( )
higher address
target address
frame pointer
ta >= fp
compare
stack overflow exception
ta < fp
lower address
(1) while a “write” operation is executed, an address check is parallel performed for the target’s addresses.
(2) if the target’s address is equal to or bigger than the value of the frame pointer, the stack overflow exception is issued; otherwise, do nothing.
Component 1---method 1
Component 1: Stack Smashing ProtectionMethod 2: Secure Function Call
Use new instruction “SCALL” and “SRET” to substitute “CALL” and “RET”
Introduce them as follow…
Component 1---method 2
Original instruction -- Call
main( )’s arguments
return address
Stack
Program Counter
…..
CALL
…..
func addr
What does “Call” do? (1) push the return address into the stack (2) put the address of the function into Program
Counter
Component 1---method 2
Original instruction -- Ret
main( )’s arguments
stack
Program Counter
…..
RET
…..
return address
return address
What does “Ret” do? Pop the return address to the Program Counter
Component 1---method 2
New instruction -- SCALL
main( )’s arguments
return address
stack
Program Counter
…..
SCALL
…..
func addr
S = XOR (key, Ret)
Component 1---method 2
Key stored in Register
Return address
What does “SCALL” do?(1) push return address(2) generate S(3) push S into Stack(4) put the address of the function into Program Counter
S
New instruction -- SRET
main( )’s arguments
previous_pc
stack
Program Counter
…..
SRET
…..
return address
S
return address
T = XOR ( Ret, Key)
Component 1---method 2
What does “SRET” do? (1) push S to reg1, and push return address to
reg2 (2) Calculate T (3) Compare T and S. If equal, move return
address to PCS Ret Key
compare
XOR
T
if T = S, move Ret to PC
Compare with method1 and method2
Method1 is better than method2: No increased instruction, checking the
boundary automatically Lower gate count Better protection
Compare method 1 and method 2
Hardware
Method 1: Boundary Check Method 2: Secure Function Call
Both methods needs simple hardware
0
1 1
If ta >= fp, Comp_out = 0
Move = 1
Move the return address to Program Counter
1
10
1
If T!= S, Comp_out = 0(Move not happen)
Compare method 1 and method 2
1
1
Comparison and Analysis
Both methods in component 1 need very simple hardware Hardware boundary check has less hardware cost
Compare method 1 and method 2
Performance overhead ofsecure function call method
hardware boundary check method is no performance overhead. Function Pointers are rarely used in embedded system. So here is secure function call method
Compare method 1 and method 2
Performance Overhead is small
Conclusion
The author proposed HSDefender to defend embedded system against buffer overflow attacks.
The results shows that HSDefender can defend more types of buffer overflow attacks with much less performance overhead.
Conclusion