Control Flow Integrity for COTS Binaries Report

Transcription

1 Control Flow Integrity for COTS Binaries Report Zhang and Sekar (2013) January 2, 2015 Partners: Instructor: Evangelos Ladakis Michalis Diamantaris Giorgos Tsirantonakis Dimitris Kiosterakis Elias Athanasopoulos 1 Introduction One of the most powerful defence technique against control flow hijacking is the Control Flow Integrity. The first proposal of CFI was made by Abadi et al. on 2005 which propose exploring the Control Flow Graph of a program and prevent Indirect Control Flow Transfers change the Indirect control flow to targets that are violating the CFG was produced. This was achieved by adding labels among targets and checks for these labels before an Indirect Control Flow Instruction. The main difference of this work from the original CFI work of Abadi is the, that the analysis and the instrumentation is based on the binary itself instead on the original code. Therefore with the proposing technique we can apply the CFI on Commercial Of The Self binaries. 2 Static Analysis In order to apply the CFI technique, first we have to disassembly the binary in order to find the complete assembly code. The x86 is based on RISC architecture and therefore, has a big instruction set which makes almost every byte a possible opcode. Also the instruction sizes vary and there are not align on 4 bytes. An assembly instruction of the x86 architecture can be from 1 to 15 bytes. Furthermore, often compilers emit data inside the text section among functions for alignment and therefore linear disassembly can inaccurate translate data into code. According to the facts above, the disassembly of an x86 binary is not an easy task. In this paper, they propose a technique in order to find the gaps among functions. In the first step they disassemble linearly the whole binary and record the errors. As errors are consider to be bytes that do not correspond to an opcode. Also 1

2 instructions that overlap with targets of control flow instructions. The error would be either the control flow instruction either the target. Finding more errors nearby will make as more confident of deciding which is the erroneous instruction. Also, errors are considered to be control flow instructions that the target falls outside the text section. After the error recognition which signifies a gap between functions, we need to identify the beginning and the end of the gap. In order to find the beginning of the gap we go backwards from the error until the first unconditional control flow instruction. The end of the gap is a control flow target which is the most close to the error instruction. After identifying the gaps we re-disassemble the binary by avoiding the gaps. If more errors occur we repeat the procedure. Code Pointers Constants In order to fix the assembly and construct the Control Flow Graph we need to all the code pointers. Code pointers live inside the data section. In order to find them we parse the data and code segment with a 4 byte window and for each one we examine if it falls inside the text section and if it points to a valid instruction boundary. If these conditions are satisfied we can assume that is a valid target. Computed Code Pointers These pointers are mostly used on switch case tables. They use a base pointer which they apply some arithmetic operations in order to find the final target. Due to the fact that these targets are computed at run time we can t be sure of what the targets would be. Therefore we can safely apply use a fixed size window of 50 instructions as possible targets. Exported Symbols Exported symbols are the exported functions entry points of a library that other programs may use. These pointers can be used for identifying functions inside the library and also for constructing the CFG graph. Interrupt Handlers The interrupt handlers pointers can be found in the headers of the ELF format. These pointers are also needed for completing the cfg graph. Return addresses Return addresses are being collected by the linear disassembly analysis. These pointers correspond to the instruction which are after a call. These targets are being used by the return address of a callee function. 3 Implementation The implementation of this CFI, targets 32-bit x86 processors running Linux. After disassembly, the resulting code is instrumented to enforce CFI. Instrumentation is performed on assembly representation. This simplifies the implementation since it does not need to be concerned with details such as encoding 2

3 and decoding of instructions. Moreover, it can use labels instead of addresses. In particular, for each instruction location A in the disassembler output of objdump, we associate a symbolic label L A as follows: L :movl %ecx, %eax These symbolic labels are used as targets of direct branch instructions, which means that the assembler will take care of fixing up the branch offsets. After rewriting, the instrumented assembly file is processed using the system assembler to produce an object file. We extract the code from this object file and then use the objcopy tool to inject it into the original ELF file. The final step prepares the ELF file produced by objcopy for execution. This step requires relocation actions on the newly added segment, and updating the ELF header to set its entry point to the segment containing instrumented code. The original code segments are made unexecutable. For shared libraries, it is also necessary to update the dynamic symbol sections. 4 Instrumentation Since instrumented code resides in a different code segment, function pointer values, which will typically appear in the code as constants, will have incorrect values. The typical way to deal with this uncertainty, employed in dynamic binary translation (DBT), is to wait until a value is used as the target of an ICF transfer. At that point, this target value is translated into the corresponding location in the instrumented code. This translation is performed using a table that consists of pairs of the form (original address, new address) At runtime, addr trans, a piece of trampoline code, performs address translation. For each Indirect branch, a check is performed against a table of (statically computed) valid targets. Intra-Module(indirect branch within the module) Addr trans performs an address range check to determine if the target is within the current module. After the range check, addr trans performs address translation. If no translation is found for the target address in the translation table, addr trans will set an error and terminate the program. Inter-Module(indirect branch outside the module) 1st stage: A global translation table (GTT) is used to map an ICF target to the translation routine address in the target module of a shared library. This array is made read-only in order to protect it. If the entry in the GTT is not null proceed to stage 2. 2nd stage: Performs a lookup in the destination module(shared library), using the address translation table for that module(intra- Module). 3

4 5 Basic Version Of CFI In this paper they named various methods of cfi and created a way to compare them. They named Abadi s cfi reloc cfi because it works with relocation information. Indirect calls and jumps target the addresses provided by the rellocation table, returns target an address right after a call. This technique can t work in cots binaries in unix based systems because they dont use relocation tables. So in this paper they used static analysis as described before and named it strict cfi. Then they implemented the more relaxed bin cfi policy compared with strict cfi to deal with some issues. 6 bincfi Policy They used the same policy for returns and indirect jumps, because the compiler will translate the return to pop and jump. Also they could not tell apart normal returns from returns used for stack unwinding, longjmp and thread context switch. Also they used the same policy for PLT jumps (used for library calls) and indirect calls, because both of them call binaries and libraries. Also they relaxed the policy and included code pointers because when there are many implementations for a function a library will export a chooser function that chooses which of the implementations will be used. 7 Average Indirect target Reduction AIR = 1 n n (1 T i S ) (1) i=1 They introduced AIR (average indirect reduction) which is a way to compare different cfi implementations. I1...In are all the possible icf transfers inside a program and S all the valid targets(size of the binary). Tj is the number of possible paths with cfi enabled. Then they also named bundle cfi as the cfi that instructions are separated in bundles and the icf must target the begining of a bundle. Instr cfi is the most basic version of cfi, it restrics the icf to valid instruction boundaries and prevents the jump to the middle of an instruction. They compared all the cfi they mentioned with AIR and concluded that the loss between reloc cfi and sctrict cfi due to the static analysis is very small and by comparing bin cfi with reloc cfi it is obvious that the costs of the relaxation policy is very small. 8 Evaluation As for evaluation results,assembly code produced by recompiling some large programs(firefox 5,GIMP-2.6 etc.) was compared with disassembly and no error found. 4

5 They also tested many real world programs and ensured that they worked correctly. They used a tool,an ROP gadget generator/compiler that scans binaries to find useful gadgets for ROP attacks and it was proved that CFI enforcement is effective, as it eliminates about 93% gadgets in the original program. In addition,the tool was able to find only a little variety of gadgets without being able to build even a single exploit. The original program had an 27% CPU overhead and they managed to bring it down after some optimizations(branch,jump table,etc. optimizations) to 4%. 9 Conclusion In conlusion, bincfi technique is robust against large and complex libraries and executables, effective against ROP/JOP gadgets and has a good perfomance (see optimization results above), although it does not support obfuscated binaries,runtime code generation,is implemented only for 32-bit Linux and tested with gcc and LLVM compilers and can not defeat all return-to-libc attacks. References Zhang, M. and Sekar, R. (2013). Control flow integrity for cots binaries. In Presented as part of the 22nd USENIX Security Symposium (USENIX Security 13), pages , Washington, D.C. USENIX. 5