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 defend 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. W W 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( )/func( ) func( ) 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( )/func( ) func( ) 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( )/func( ) func( ) 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 0x h 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 0x h buffer(overflow) Hacker’s Shell Code 0x h 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 Protection Method 1: Boundary Check main( )’s arguments main( ) return address saved %ebp p func( )’s arguments return address saved %ebp var1 buf main( ) 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 Protection Method 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 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 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 PC SRetKey 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 If ta >= fp, Comp_out = 0 Move = 1 Move the return address to Program Counter 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 of secure 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