Binary Code Software Weakness Analysis Method based on Smart Intermediate Language in Embedded Environment 1

Transcription

1 , pp Binary Code Software Weakness Analysis Method based on Smart Intermediate Language in Embedded Environment 1 Junho Jeong 1, Yunsik Son 2 and Seman Oh 2* 1 Electronic Commerce Institute, Dongguk University 2 Dept. of Computer Science and Engineering, Dongguk University {yanyenli, sonbug, smoh}@dongguk.edu, * Corresponding Author Abstract While software is being developed using open source and third-party libraries, analysis and security testing during the development process is very inadequate. As a result, the use of unverified third-party libraries is increasing the number of security incidents such as HeartBleed. However, it is very difficult to verify the security of binary libraries. In this paper, we propose a security vulnerability analysis method using an intermediate language that is effective in security weakness analysis to overcome the main CVE (Common Vulnerabilities Exposures) in embedded software environment. Keywords: Binary Code, Embedded Environment, Intermediate Language, Third Party Library, Vulnerability Analysis, Weakness Analysis 1. Introduction As the size of the software becomes larger, various developers develop software in order to maintain its overall quality. Various studies have been conducted to eliminate vulnerabilities found in software in order to eliminate security weaknesses. For this reason, applying a systematic and detailed development methodology that eliminates security weaknesses according to security weakness classification and analysis such as CERT Secure Coding, CWE / SANS TOP 25, etc., during the Software Development Life Cycle as well as during the development of embedded environments has become common practice [1,2]. Most of these applications, however, are methods to remove security weaknesses in advance by performing analysis on the development source code. However, in recent years, third-party libraries have become a major part of software development, and many third-party libraries are used for software development. Also, security analysis and testing of third party libraries are not being performed well during development. As a result, various security incidents such as HeartBleed, ShellShock, POODLE, and DROWN have occurred due to the use of the third-party libraries [3-8]. Thus, security verification should be performed on third-party libraries. However, in the case of third-party libraries that are provided only as a binary without source code, the syntactic structure and semantic information of many programs are removed, so security weakness analysis and potential security vulnerabilities through static analysis methods are limited. Therefore, there is a need for a method for analyzing security weaknesses in binary code. For software in embedded environments, it is important to analyze the security weakness in advance because security incidents are very important and SW accidents occurring in the environment can cause serious problems directly related to human life. Received (July 17, 2017), Review Result (October 3, 2017), Accepted (October 11, 2017) ISSN: IJSEIA Copyright c 2017 SERSC

2 However, since binary code is expressed according to the development language, target machine, operating system, and the compiler, a separate analysis method is required for each binary code to be analyzed [9-12]. Recently, studies on static analysis methods based on intermediate languages have been carried out [13-18]. The static analysis method based on the intermediate language is used to convert binary code into an intermediate language, and analyze the security weakness as an intermediate language rather than a binary code. Therefore, analysis of security weakness is done for intermediate languages and there is no need to consider the development environment of the binary code and target machine. In this paper, we propose a security weakness analysis method based on SIL (Smart Intermediate Language) to overcome major CVEs in binary code of embedded software environments. Section 2 explores security vulnerabilities that occur in major CVEs in embedded environments. Section 3 introduces the existing intermediate language and security weakness analysis techniques based on the language. In Section 4, we propose a method for analyzing security weakness based on our intermediate language, and in Section 5, we analyze the performance of the proposed method. Finally, we conclude in Section Embedded Software CVE A security vulnerability in a software means that there is already a proble m in the operation of the software, which is caused by security weaknesses. In other words, all security weaknesses inherent in software are not security vulnerabilities, but all security vulnerabilities are caused by security weaknesses. Therefore, it is most important to remove the security weakness inherent in a software in order to eliminate the security vulnerability of the software. Therefore, in order to find software security weaknesses in a specific environment, it is possible to analyze major security weaknesses mainly occurring in the environment through security vulnerabilities. In order to manage such security vulnerabilities more systematically, MITER is creating CVE [19]. CVE is a standardized list of security vulnerabilities and other information security exposures. The CVE covers 13 vulnerability representatives. Figure 1 shows a total of items of CVEs reported from 1999 to 2016, and the most common vulnerabilities in the embedded SW are DoS, Execute Code, Overflow, Bypass Something, and Gain Information, Gain Privilege, and Memory Corruption. Among these, Execute Code, DoS and Overflow vulnerabilities are more vulnerable than XSS vulnerabilities which are most frequently issued on web services. Because these three vulnerabilities have a significant impact, careful consideration of embedded software vulnerability is very important. Figure 1. Number of Vulnerabilities Reported by Type of CVE from 1999 ~ Copyright 2017 SERSC

3 Therefore, this paper proposes a method for analyzing security weaknesses that can cause these three vulnerabilities. 3. Intermediate Language and Software Weakness Analysis 3.1. Vine (Bit Blaze) BitBlaze is a unified binary analysis platform that provides a broad spectrum solution to solve a variety of security problems and consists of three components: Vine, TEMU and Rudd. Vine is a static analysis component that translates and analyzes binaries into intermediate languages. TEMU is a dynamic analysis component that monitors the entire system in detail, measures dynamic binaries, and dynamically analyzes the entire system. Rudder is a new component that combines static and dynamic analysis. The structure of Vine, which is the static analysis method component of BitBlaze, is largely divided into the front end and the rear end. The front end of Vine converts from 32-bit x86 binary code to assembly. Vine's intermediate language makes it easier to analyze programs with a platform-independent, simple-structured IL. Vine's Back End supports a variety of core program analysis and features Vine instructions that can be loaded into valid C code via the end code generator. By combining static analysis and dynamic analysis, Vine provides readable execution records created by dynamic analysis components such as TEMU. However, Vine lacks the semantic meaning of intermediate language, and it is difficult to apply it to structures such as ARM that deal with both big endian and little endian BIL (BAP) The Binary Analysis Platform (BAP) is a tool for binary code analysis and supports ARM machines as well as assembly language for x86, and provides various tools for static and dynamic analysis of binary code. The BAP receives the binary code as an input and converts it into a structure-independent intermediate language called the Binary Intermediate Language (BIL) at the front end. This intermediate language can be expressed in graph form, optimized, and can generate VC (Verification Conditions) by calculating the weakest preconditions. In addition, you can perform additional program analysis, and reverse-convert it back to assembly / binary / C code REIL Reverse Engineering Intermediate Language (REIL) is an intermediate language for representing platform-independent disassembled assembly code and can automate static analysis of assembly code in the context of software reverse engineering for vulnerability detection purposes. Implementation was completed using the commercial reverse engineering tool BinNavi. The conversion from raw assembly code to the REIL code is done by the REIL converter which converts the REIL code into a part of the original assembly code and iterates over all instructions of the input code. The translator converts each instruction independently into REIL code it does not need the information of the next command, and it does not require the information generated in the conversion of the previous instruction. Simply put, the REIL translator repeats mapping a single native instruction to a list of REIL instructions, and because of the simplicity of the REIL instruction, a single native assembly instruction is converted to many REIL instructions. However, REIL cannot translate special commands such as FPU and system calls. Copyright 2017 SERSC 55

4 3.4. SIL The SIL intermediate language is a language designed for operation in a stackbased virtual machine. The instruction set is divided into 7 operation codes according to the operation type. An opcode is represented by two bytes and can have instruction parameters as needed. The mnemonic of the opcode is defined as a combination of an alphabet and an integer meaning operation for the readability of the code. When type information is required according to the type of opcode, the type symbol is padded using '.' (dot). Intermediate language commands can have up to two operands, and can have one result value that is pushed onto the stack as a result of the operation. Each intermediate language instruction also has a type, so that each operand 1, operand 2, and result type can be formatted. The result type for type correcting is expressed as <operand 1, operand 2, arithmetic result>. In this paper, we use some modified SIL to convert binary code to SIL. Vulnerable functions that cause already well-known security weaknesses can be defined internally in advance to analyze security weaknesses. 4. Embedded Software Weakness Analysis based on SIL We propose a method for translating binary codes into intermediate languages and analyzing the security weaknesses of software using intermediate languages, similar to the existing intermediate language-based security weakness research. In this paper, we propose a methodology for analyzing buffer overflow, which is one of the most common weaknesses in the embedded environment, and we have developed a dedicated module for it. Buffer overflow is one of the most common security weaknesses that occur with stack and heap buffers. It is the most common security problem in the second half of 2000, and has been reported continuously in recent years. This problem is caused by using a vulnerable function that does not check the size of the buffer inside the source code and executes the user's command. Security problems arise when data input from external sources (file, socket, etc.) is used for these vulnerable functions. An example of the invocation sequence of a vulnerable function is shown in Figure 2. This is a typical example of a function that uses a strcpy function, known as a vulnerable function, to refer to a parameter when a buffer overflow occurs. Figure 2. Example Call Sequence using Common Vulnerable Functions Therefore, the procedure as shown in Figure 3 is performed to analyze whether the SIL code having security weakness has a vulnerability. For effective analysis of security weakness analysis, we improve the existing SIL and define the vulnerable functions in advance so that we can easily judge the use of vulnerable functions. 56 Copyright 2017 SERSC

5 Figure 3. When a Vulnerable Function References a Parameter There exists a case where the parameters of the fragile function are referred to within the analysis target function. This is the same statement as filling a big_buffer of size 256 through an iterator with 'A' characters and storing the variable in a buffer variable of size 16 as the source of the strcpy function as shown in Figure 4. Once the parameters of the vulnerable function are referenced internally, the analysis can be performed using the algorithm shown in Figure 5. Figure 4. Problematic Parameters when Passing the Internal Function Call Sequence Copyright 2017 SERSC 57

6 Figure 5. Analysis Algorithm when Referring to the Inside of the Vulnerable Function Parameter 5. Experiment To analyze the proposed method, the C source code as shown in figure 6, which has a buffer overflow, is generated as binary code and converted into SIL code, which is an early intermediate language. #include "sys_lib.h" void sample_function(char*string) { char buffer[16]; strcpy(buffer, string); return; } void main() { char big_buffer[256]; int i; for(i=0; i<256; i++) big_buffer[i] ='A'; sample_function(big_buffer); Buffer Overflow return 0; } Figure 6. C Source Code Example with buffer Overflow Security Weakness Figure 7 show the SIL code control flow of the example When analyzing the control flow of the converted SIL code, the corresponding source uses strcpy() in sample_function. In order to identify a security vulnerability, we check whether the src used in strcpy is smaller than the destination. Therefore, the data flow analysis is carried out by backward method in which input is started with sample_function(), and the following algorithm is applied as follows. First, it searches through the number of call function using vulnerable functions. Strcpy is predefined as 86 functions, so it can easily judge whether vulnerable functions are used. Afterwards, we specify the basic block from vulnerable function to ldp, and search for the variable using beige block. In the example, str.p 1 0 and lda 1 4 are variables. Since the function used is strcpy, the size of the variable lda 1 4 to be stored, and the variable str.p 1 0 to be the source, determine whether a buffer 58 Copyright 2017 SERSC

7 overflow occurs. Therefore, we need to deduce the size of the local variable through the declaration of the risk function. In the example, we can deduce that the size is 20, and the string stored in lda 1 4 by strcpy should be smaller than 16. Figure 7. SIL Code Control Flow of Example Code To check this, we can call sample_function in the main function, it sets the basic block from the area to ldp, and lda 1 0 is the corresponding parameter. In addition, we can see that the size of the variable is 256 by the bottom up method. In the previous analysis, we know that there is no problem because it is smaller than 16, so we can confirm that a buffer overflow occurs. Figure 8 shows the data flow of the SIL code. 6. Conclusion In this paper, we propose a method to perform SIL intermediate language-based analysis on security weakness inherent in embedded environment software. We propose a method to effectively analyze the buffer overflow that may occur in the stack and the heap area. As a result, we confirmed that it is possible to analyze security weakness effectively by converting binary code to SIL. However, since only one of the many security weaknesses has been analyzed, future research on methods for analyzing other major weaknesses such as Use After Free and Integer Overflow based on SIL will be conducted in the future. Ultimately, we will carry out research to implement embedded environment binary code security vulnerability integration analyzer that integrates these weakness analysis modules. Copyright 2017 SERSC 59

8 Acknowledgments Figure 8. SIL Code Data Flow Analysis of Example Code The authors gratefully acknowledge the financial support provided by Defense Acquisition Program Administration and Agency for Defense Development under the contract UD160035ED. References [1] B. Martin, M. Brown, A. Paller, D. Kirby and S. Christey, 2011 CWE/SANS top 25 most dangerous software errors, (2011) September. [2] K. Tsipenyuk, B. Chess and G. McGraw, Seven pernicious kingdoms: A taxonomy of software security errors, Journal of IEEE Security and Privacy, vol. 3, no. 6, (2005), pp [3] N. Mehta, The Heartbleed Bug, (2014) April. [4] S. Chazelas, The Shellshock vulnerability, (2014) September. [5] B. Möller, T. Duong and K. Kotowicz, This POODLE bites: exploiting the SSL 3.0 fallback, (2014). [6] N. Aviram, S. Schinzel, J. Somorovsky, N. Heninger, M. Dankel, J. Steube,... and E. Käsper, DROWN: Breaking TLS using SSLv2, Proceedings of the 25th USENIX Security Symposium, AUSTIN, USA, (2016) August [7] GRAMMATECH, Find Defects in Third-Party Code, [8] GRAMMATECH, Eliminating Vulnerabilities in Third-party Code with Binary Analysis, [9] S. Rawat and L. Mounier, Finding buffer overflow inducing loops in binary executables, Proceedings of IEEE 6th International Conference on Software Security and Reliability (SERE), Gaithersburg MD, USA, (2012). [10] J. Feist, L. Mounier and M. L. Potet, Statically detecting use after free on binary code, Journal of Computer Virology and Hacking Techniques, vol. 10, no. 3, (2014), pp Copyright 2017 SERSC

9 [11] T. Wang, T. Wei, Z. Lin and W. Zou, IntScope: Automatically Detecting Integer Overflow Vulnerability in X86 Binary Using Symbolic Execution, Proceedings of 16th Network and IT Security Symposium, (2009) San Diego, USA, February [12] B. Zhang, B. Wu, C. Feng, X. Zhang, and C. Tang, Statically detect invalid pointer dereference vulnerabilities in binary software, Proceedings of IEEE International Conference on Progress in Informatics and Computing (PIC), Nanjing, China, (2015), December [13] D. Song, D. Brumley, H. Yin, J. Caballero, I. Jager, M. G. Kang, Z. Liang, J. Newsome, P. Poosankam and P. Saxena, "BitBlaze: A new approach to computer security via binary analysis," Proceedings of the 4th International Conference on Information Systems Security, Hyderabad, India, (2008) December [14] D. Brumley, I. Jager, T. Avgerinos and E. J. Schwartz, BAP: A Binary Analysis Platform, Proceedings of the 23th international conference on Computer aided verification, (2011) Snowbird, USA, July [15] T. Dullien, and S. Porst, "REIL: A platform-independent intermediate representation of disassembled code for static code analysis," Proceeding of CanSecWest (2009). [16] Y. Son and Y. Lee, A Study on the Java Compiler for the Smart Virtual Machine Platform, Communications in Computer and Information Science, vol. 353, (2012), pp [17] G. C. Necula, S. McPeak, S. P. Rahul and W. Weimer, "CIL: Intermediate language and tools for analysis and transformation of C programs," Proceedings of the 11th international Conference on Compiler Construction, Grenoble, France, (2002) April [18] S. Cesare, and X. Yang, "Wire-A Formal Intermediate Language for Binary Analysis, Proceedings of IEEE 11th International Conference on Trust, Security and Privacy in Computing and Communications (TrustCom), Liverpool, UK, (2012) June [19] The MITRE Corporation, Common Vulnerabilities and Exposures, (2001). Copyright 2017 SERSC 61

10 62 Copyright 2017 SERSC