1 / 54

Introduce LLVM from a hacker's view.

Introduce LLVM from a hacker's view. Loda chou . hlchou@mail2000.com.tw For HITCON 2012. Who am I?. 愚妄 人所行的，在自己眼中看為正直；惟智慧人肯聽人的勸教. I am Loda . Work for 豬屎屋 ( DeSign House). Be familiar for MS-Windows System and Android/Linux Kernel. Sometimes…also do some software crack job.

holland
Télécharger la présentation

Introduce LLVM from a hacker's view.

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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Introduce LLVM from a hacker's view. Lodachou. hlchou@mail2000.com.tw For HITCON 2012

  2. Who am I? 愚妄人所行的，在自己眼中看為正直；惟智慧人肯聽人的勸教 • I am Loda. • Work for 豬屎屋 (DeSign House). • Be familiar for MS-Windows System and Android/Linux Kernel. • Sometimes…also do some software crack job. • Like to dig-in new technology and share technical articles to promote to the public. • Motto • The way of a fool seems right to him ,but a wise man listens to advice.(Proverbs12:15)

  3. What is LLVM? Created by VikramAdve and Chris Lattne on 2000 Support different front-end compilers (gcc/clang/....) and different languages (C/C++,Object-C,Fortran,JavaByteCode,Python,ActionScript) to generate BitCode. The core of LLVM is the intermediate representation (IR). Different front-ends would compile source code to SSA-based IR, and traslate the IR into different native code on different platform. Provide RISC-like instructions (load/store…etc), unlimited registers, exception (setjmp/longjmp)..etc Provide LLVM Interpreter and LLVM Compiler to run LLVM application.

  4. Let's enjoy it.

  5. Android DalvikRunTime DalvikByteCodeAP in dex/odex DalvikVirtual Machine DalvikByteCode Framework in JAR Java Native Interface Partial Dalvik AP implemented in Native .so Native .so library Linux Kernel

  6. The features of Dalvik VM • Per-Process per-VM • JDK will compile Java to Sun’s bytecode, Android would use dx to convert Java bytecode to Dalvikbytecode. • Support Portable Interpreter (in C), Fast Interpreter (in Assembly)and Just-In Time Compiler • Just-In-Time Compiler is Trace-Run based. • By Counter to find the hot-zone • Would translate Dalvikbytecode to ARMv32/NEON/Thumb/Thumb2/..etc CPU instructions.

  7. LLVM Interpreter RunTime LLVM BitCodeAP Running by LLI (Low Level Virtual Machine Interpreter & Dynamic Compiler) Native .so library Linux Kernel

  8. Why LLVM? • Could run llvm-application as the performance of native application • Could generate small size BitCode, translate to target platform assembly code then compiled into native execution file (final size would be almost the same as you compile it directly from source by GCC or other compiler.) • Support C/C++/… program to seamlessly execute on variable hardware platform. • x86, ARM, MIPS,PowerPC,Sparc,XCore,Alpha…etc • Googlewould apply it into Android and Browser (Native Client)

  9. The LLVM Compiler Work-Flows. X86Assembly X86Execution File llc-mcpu=x86-64 gcc C/C++ clang -emit-llvm llc -mcpu=cortex-a9 arm-none-linux-gnueabi-gcc-mcpu=cortex-a9 BitCodeAssembly LLVM Compiler ARMAssembly ARMExecution File Java Fortran ...etc

  10. LLVM in Mobile Device BitCode C/C++ JavaByteCode BitCode Application BitCode Render Script

  11. LLVM in Browser ChromiumBrowser HTML/Java Script SRPC NPAPI UnTrust Part IMC Would passed the security checking before execution. Native Client APP Call to run-time framework Service Framework SRPC IMC Trust Part StorageService IMC : Inter-Module Communications SRPC : Simple RPCNPAPI : Netscape Plugin Application Programming Interface

  12. LLVM Compiler Demo. Use clang to compile BitCode File. [root@localhostreference_code]# clang -O2 -emit-llvmsample.c -c -o sample.bc [root@localhostreference_code]# ls -l sample.bc -rw-r--r--. 1 root root 1956 May 12 10:28 sample.bc Convert BitCode File to x86-64 platform assembly code. [root@localhostreference_code]# llc -O2 -mcpu=x86-64 sample.bc -o sample.s Compiler the assembly code tox86-64 native execution file. [root@localhostreference_code]# gccsample.s -o sample -ldl [root@localhostreference_code]# ls -l sample -rwxr-xr-x. 1 root root 8247 May 12 10:36 sample Convert BitCode File to ARM Cortext-A9 platorm assembly code. [root@localhostreference_code]# llc -O2 -march=arm -mcpu=cortex-a9 sample.bc -o sample.s Compiler the assembly code toARM Cortext-A9native execution file. [root@localhostreference_code]# arm-none-linux-gnueabi-gcc -mcpu=cortex-a9 sample.s-ldl -o sample [root@localhostreference_code]# ls -l sample -rwxr-xr-x. 1 root root 6877 May 12 10:54 sample

  13. What is the problems for LLVM? Let’s see a simple sample code.

  14. LLVM dlopen/dlsymc Sample. int (*puts_fp)(const char *); int main() { void * libraryHandle; libraryHandle = dlopen("libc.so.6", RTLD_NOW); printf("libraryHandle:%xh\n",(unsigned int)libraryHandle); puts_fp = dlsym(libraryHandle, "puts"); printf("puts function pointer:%xh\n",(unsigned int)puts_fp); puts_fp("loda"); return 0; } [root@www LLVM]# clang -O2 -emit-llvmdlopen.c -c -o dlopen.bc [root@www LLVM]# llidlopen.bc libraryHandle:86f5e4c8h puts function pointer:85e81330h loda

  15. Make execution code as data buffer 0000000000000000 <AsmFunc>: 0: 55 push %rbp 1: 48 89 e5 mov %rsp,%rbp 4: b8 04 00 00 00 mov$0x4,%eax 9: bb 01 00 00 00 mov$0x1,%ebx e: b9 00 00 00 00 mov$0x0,%ecx f: R_X86_64_32 gpHello 13: ba 10 00 00 00 mov$0x10,%edx 18: cd 80 int$0x80 1a: b8 11 00 00 00 mov$0x11,%eax 1f: c9 leaveq 20: c3 retq Would place the piece of machine code as a data buffer to verify the native/LLVM run-time behaviors.

  16. Native Program Run Code in Data Segment int (*f2)(); char TmpAsmCode[]={0x90,0x55,0x48,0x89,0xe5,0xb8,0x04,0x00,0x00,0x00,0xbb,0x01,0x00,0x00,0x00,0xb9,0x40,0x0c,0x60,0x00,0xba,0x10,0x00,0x00,0x00,0xcd,0x80,0xb8,0x11,0x00,0x00,0x00,0xc9,0xc3}; char gpHello[]="Hello Loda!ok!\n"; int main() { intvRet; unsigned long vpHello=(unsigned long)gpHello; TmpAsmCode[19]=vpHello>>24 & 0xff; TmpAsmCode[18]=vpHello>>16 & 0xff; TmpAsmCode[17]=vpHello>>8 & 0xff; TmpAsmCode[16]=vpHello & 0xff; f2=(int (*)())TmpAsmCode; vRet=f2(); printf("vRet=:%d\n",vRet); return 0; } [root@www LLVM]# gcc self-modify.c -o self-modify [root@www LLVM]# ./self-modify Segmentation fault

  17. Native Program Run Code in Data Segment with Page EXEC-settings int (*f2)(); char TmpAsmCode[]={0x90,0x55,0x48,0x89,0xe5,0xb8,0x04,0x00,0x00,0x00,0xbb,0x01,0x00,0x00,0x00,0xb9,0x40,0x0c,0x60,0x00,0xba,0x10,0x00,0x00,0x00,0xcd,0x80,0xb8,0x11,0x00,0x00,0x00,0xc9,0xc3}; char gpHello[]="Hello Loda!ok!\n"; int main() { intvRet; unsigned long vpHello=(unsigned long)gpHello; unsigned long page = (unsigned long) TmpAsmCode & ~( 4096 - 1 ); if(mprotect((char*) page,4096,PROT_READ | PROT_WRITE | PROT_EXEC )) perror( "mprotect failed" ); TmpAsmCode[19]=vpHello>>24 & 0xff; TmpAsmCode[18]=vpHello>>16 & 0xff; TmpAsmCode[17]=vpHello>>8 & 0xff; TmpAsmCode[16]=vpHello & 0xff; f2=(int (*)())TmpAsmCode; vRet=f2(); printf("vRet=:%d\n",vRet); return 0; } [root@www LLVM]# gcc self-modify.c -o self-modify [root@www LLVM]# ./self-modify Hello Loda!ok! vRet=:17

  18. LLVM AP Run Code in Data Segment with EXEC-settings int (*f2)(); char TmpAsmCode[]={0x90,0x55,0x48,0x89,0xe5,0xb8,0x04,0x00,0x00,0x00,0xbb,0x01,0x00,0x00,0x00,0xb9,0x40,0x0c,0x60,0x00,0xba,0x10,0x00,0x00,0x00,0xcd,0x80,0xb8,0x11,0x00,0x00,0x00,0xc9,0xc3}; char gpHello[]="Hello Loda!ok!\n"; int main() { intvRet; unsigned long vpHello=(unsigned long)gpHello; unsigned long page = (unsigned long) TmpAsmCode & ~( 4096 - 1 ); if(mprotect((char*) page,4096,PROT_READ | PROT_WRITE | PROT_EXEC )) perror( "mprotect failed" ); char *base_string=malloc(256); strcpy(base_string,gpHello); vpHello=(unsigned long)base_string; TmpAsmCode[19]=vpHello>>24 & 0xff; TmpAsmCode[18]=vpHello>>16 & 0xff; TmpAsmCode[17]=vpHello>>8 & 0xff; TmpAsmCode[16]=vpHello & 0xff; f2=(int (*)())TmpAsmCode; vRet=f2(); printf("vRet=:%d\n",vRet); return 0; } [root@www LLVM]# clang -O2 -emit-llvmllvm-self-modify.c -c -o llvm-self-modify.bc [root@www LLVM]# llillvm-self-modify.bc Hello Loda!ok! vRet=:17

  19. LLVM AP Run Code in Data Segment without EXEC-settings? int (*f2)(); char TmpAsmCode[]={0x90,0x55,0x48,0x89,0xe5,0xb8,0x04,0x00,0x00,0x00,0xbb,0x01,0x00,0x00,0x00,0xb9,0x40,0x0c,0x60,0x00,0xba,0x10,0x00,0x00,0x00,0xcd,0x80,0xb8,0x11,0x00,0x00,0x00,0xc9,0xc3}; char gpHello[]="Hello Loda!ok!\n"; int main() { intvRet; unsigned long vpHello=(unsigned long)gpHello; char *base_string=malloc(256); strcpy(base_string,gpHello); vpHello=(unsigned long)base_string; TmpAsmCode[19]=vpHello>>24 & 0xff; TmpAsmCode[18]=vpHello>>16 & 0xff; TmpAsmCode[17]=vpHello>>8 & 0xff; TmpAsmCode[16]=vpHello & 0xff; f2=(int (*)())TmpAsmCode; vRet=f2(); printf("vRet=:%d\n",vRet); return 0; } [root@www LLVM]# clang -O2 -emit-llvmllvm-self-modify.c -c -o llvm-self-modify.bc [root@www LLVM]# llillvm-self-modify.bc Hello Loda!ok!  It still works! vRet=:17

  20. So…..What we got? Code LLVM BitCodeAP BidirectionalFunction Call Running by LLI (Low Level Virtual Machine Interpreter & Dynamic Compiler) Data LLVM could run data-segment as execution code. LLVM doesn’t provide a strict sandbox to prevent the unexpected program flows. For installed-application, maybe it is ok. (could protect by Android Kernel-Level Application Sandbox) How about LLVM running in Web Browser?

  21. Technology always come from humanity!!!

  22. Native Client(Nacl)- a vision of the future Provide the browser to run web application in native code. Based on Google’s sandbox, it would just drop 5% performance compared to original native application. Could be available in Chrome Browser already. The Native Client SDK only support the C/C++ on x86 32/64 bits platform. Provide Pepper APIs (derived from Mozilla NPAPI). Pepper v2 added more APIs.

  23. Hack Google's Native Client and get $8,192 http://www.zdnet.com/blog/google/hack-googles-native-client-and-get-8192/1295

  24. Security of Native Client http://code.google.com/p/nativeclient/issues/list • Data integrity • Native Client's sandbox works by validating the untrusted code (the compiled Native Client module) before running it • No support for process creation / subprocesses • You can call pthread • No support for raw TCP/UDP sockets (websockets for TCP and peer connect for UDP) • No unsafe instructions • inline assembly must be compatible with the Native Client validator (could use ncval utility to check)

  25. How Native Client Work? Launch nacl64.exe to Execute the NaClExecutable (*.NEXE) file. Browsing WebPagewith Native Client. ChromiumBrowser

  26. Main Process and Dynamic Library lib64/libc.so.3c8d1f2e lib64/libdl.so.3c8d1f2e lib64/libgcc_s.so.1 lib64/libpthread.so.3c8d1f2e lib64/runnable-ld.so hello_loda.html hello_loda.nmf hello_loda_x86_32.nexe hello_loda_x86_64.nexe C:\Users\loda\AppData\Local\Temp 6934.Tmp (=libc.so.3c8d1f2e) 6922.Tmp (=libdl.so.3c8d1f2e) 6933.tmp (=libgcc_s.so.1) 6912.tmp (=libpthread.so.3c8d1f2e) 67D8.tmp (=runnable-ld.so) 66AE.tmp (=hello_loda.nmf) 6901.Tmp(= hello_loda_x86_64.nexe) Download the main process and dynamic run-time libraries. ChromiumBrowser Server providedNative Client Page

  27. Dynamic libraries Inheritance relationship Hello Loda Process (.NEXE) libpthread.so.3c8d1f2e libgcc_s.so.1 libdl.so.3c8d1f2e libc.so.3c8d1f2e runnable-ld.so=(ld-nacl-x86-64.so.1)

  28. Portable Native Client (PNaCl) PNaCl(pronounced "pinnacle") Based on LLVMto provided an ISA-neutral format for compiled NaCl modules supporting a wide variety of target platforms without recompilation from source. Support the x86-32, x86-64 and ARM instruction sets now. Still under the security and performance properties of Native Client.

  29. LLVM and PNaCl Refer from Google’s ‘PNaCl Portable Native Client Executables ’ document.

  30. PNaCl Shared Libraries libtest.c app.c Libtest.pso App.bc App.pexe Translate tonative code pnacl-translate pnacl-translate Libtest.so App.nexe Execute under Native ClientRunTime Environment http://www.chromium.org/nativeclient/pnacl/pnacl-shared-libraries-final-picture

  31. Before SFI • Trust with Authentication • Such as the ActiveX technology in Microsoft Windows, it would download the native web application plug-in the browser (MS Internet Explorer). User must authorize the application to run in browser. • User-ID based Access Control • Android Application Sandbox use Linux user-based protection to identify and isolate application resources. Each Android application runs as that user in a separate process, and cannot interact with each other under the limited access to the operating system..

  32. General User/Kernel Space Protection Process individual memory space Process individual memory space Process individual memory space User Space Application #1 User Space Application #2 User Space Application #3 RPC RPC UnTrust Code Application could use kernel provided services by System Call Trust Code Kernel Space Device Drivers and Kernel Modules

  33. Fault Isolation • 1,ARM instruction length is fixed to 32-bits or 16bits(depend on ARMv32,Thumb or Thumb2 ISA) • 2,X86 instruction length is variable from 1 to 1x bytes. • CFI (CISC Fault Isolation) • Based on x86 Code/Data Segment Register to reduce the overhead, NaCl CFI would increase around 2% overhead. • SFI • NaCl SFI would increase 5% overhead in Cortex A9 out-of-order ARM Processor, and 7%overhead in x86_64 Processor.

  34. CISC Fault Isolation Data/Code Dedicated Register= (Target Address & And-Mask Register) | Segment Identifier Dedicated Register Address SandBoxing X86_64 Native Client running under specific 4GB memory 32bits4GBMemory Space RunningMemory Space Address SandBoxing

  35. Software Fault Isolation Process individual memory space Running in Software Fault Isolation Model User Space SFI Trust Code User Space SFI UnTrust Code Call Gate Return Gate UnTrust Code Application could use kernel provided services by System Call Trust Code Kernel Space Device Drivers and Kernel Modules

  36. NaCl SFI SandBox • NaCl would download the whole execution environment (with dynamic libraries) • Would use x86_64 environment as the verification sample. • Each x86_64 App would use 4GB memory space. • But for ARM App, it would only use 0-1GB memory space. • x86_64R15 Registers would be defined as “Designated Register RZP” (Reserved Zero-address base Pointer),and initiate as a 4GBaligned base address to map the UnTrust Memory space. For the UnTrust Code, R15 Registers is read-only.

  37. RSP/RBP Register Operation //by x86_64 GCC 0000000000400624 <testB>: 400624: 55 push %rbp 400625: 48 89 e5 mov %rsp,%rbp 400628: 48 83 ec 20 sub $0x20,%rsp 40062c: 89 7d ecmov%edi,-0x14(%rbp) testB(0x1234); inttestB(int I) { intvRet; void *libraryHandle; … } mov $0x1234,%edi callq 400624 <testB> //by x86_64 pnacl-clang 00000000010003e0 <testB>: 10003e0: 55 push %rbp 10003e1: 48 89 e5 mov%rsp,%rbp 10003e4: 83 ec10 sub $0x10,%esp 10003e7: 4a 8d 24 3c lea (%rsp,%r15,1),%rsp 10003eb: 89 7d fc mov%edi,-0x4(%rbp) Function in 32bytes Alignment Clear RSP high-32bits Use R15 to limit RSPin specific 4GB space The modification of 64bits RSP/RBP would be replaced by a set instructions to limit the 64bits RSP/RBP would be limited in allowed 32bits range.

  38. Function Call (1/3) //by x86_64 GCC 40067c: e8 77 feffffcallq 4004f8 <dlsym@plt> //rax = function puts address 40068f: bf d0 0b 60 00 mov $0x600bd0,%edi 400694: ff d0 callq*%rax char gpHello[]="Hello Loda!\n"; int (*f1)(const char *); …… f1 = dlsym(libraryHandle, "puts"); f1(gpHello); //by x86_64 pnacl-clang 100045b: e8 20 fdffffcallq 1000180 <dlsym@plt+0x120> //rax = function puts address 1000466: bf 00 02 01 11 mov $0x11010200,%edi ……. 1000478: 83 e0 e0 and $0xffffffe0,%eax 100047b: 4c 01 f8 add %r15,%rax 100047e: ff d0 callq *%rax Clear RAX high-32bits Use R15 to limit RAXin specific 4GB space The function target address would be 32 bytes alignment, and limit the target address toallowed 32bits range by R15.

  39. Function Call (2/3) callq 4004f8 <dlsym@plt> //by x86_64 GCC 4004f8: ff 25 ba 06 20 00 jmpq *0x2006ba(%rip) # 600bb8 <_GLOBAL_OFFSET_TABLE_+0x38> 4004fe: 68 04 00 00 00 pushq $0x4 400503: e9 a0 ffffffjmpq 4004a8 <_init+0x18> int(*f1)(const char *); …… f1 = dlsym(libraryHandle, "puts"); callq 1000180 <dlsym@plt+0x120> //by x86_64 pnacl-clang 1000080: 4c 8b 1d 49 01 01 10 mov 0x10010149(%rip),%r11 #110101d0<_GLOBAL_OFFSET_TABLE_+0x20> 1000087: 45 89 db mov %r11d,%r11d 100008a: 41 83 e3 e0 and $0xffffffe0,%r11d 100008e: 4d 01 fb add %r15,%r11 1000091: 41 ff e3 jmpq *%r11 R11 in 32bytes Alignment Use R15 to limit R11in specific 4GB space • Call function from ELF PLT (Procedure Linkage Table) • The function target address would be 32 bytes alignment, and limit the target address toallowed 32bits range by R15.

  40. Function Call (3/3) vRet=0x1234*testA(0x888); //by x86_64 GCC 400696: bf 88 08 00 00 mov $0x888,%edi 40069b: e8 54 ffffffcallq4005f4 <testA> 4006a0: 69 c0 34 12 00 00 imul $0x1234,%eax,%eax Directly call toUnTrust function. //by x86_64 pnacl-clang 1000480: bf 88 08 00 00 mov $0x888,%edi ………………….. 100049b: e8 e0 feffffcallq1000380 <testA> 10004a0: 69 c0 34 12 00 00 imul$0x1234,%eax,%eax Directly call toUnTrust function. For the internal UnTrust function directly calling, it doesn’t need to filter by the R15

  41. Function Return inttestB(int I) { intvRet; …………… vRet=0x1234*testA(0x888); return vRet; } //by x86_64 GCC 40069b: e8 54 ffffffcallq 4005f4 <testA> 4006a0: 69 c0 34 12 00 00 imul $0x1234,%eax,%eax 4006a6: 89 45 f4 mov%eax,-0xc(%rbp) 4006a9: 8b 45 f4 mov-0xc(%rbp),%eax 4006ac: c9 leaveq 4006ad: c3 retq //by x86_64 pnacl-clang 100049b: e8 e0 feffffcallq1000380 <testA> 10004a0: 69 c0 34 12 00 00 imul $0x1234,%eax,%eax 10004a6: 89 45 f8 mov%eax,-0x8(%rbp) 10004a9: 83 c4 10 add $0x10,%esp 10004ac: 4a 8d 24 3c lea (%rsp,%r15,1),%rsp 10004b0: 8b 2c 24 mov (%rsp),%ebp 10004b3: 4a 8d 6c 3d 00 lea 0x0(%rbp,%r15,1),%rbp 10004b8: 83 c4 08 add $0x8,%esp 10004bb: 4a 8d 24 3c lea (%rsp,%r15,1),%rsp 10004bf: 59 pop %rcx 10004c0: 83 e1 e0 and $0xffffffe0,%ecx 10004c3: 4c 01 f9 add %r15,%rcx 10004c6: ff e1 jmpq *%rcx Clear RSP high-32bits Use R15 to limit RSPin specific 4GB space RCX in 32bytes Alignment The function return address would be 32 bytes alignment, and limit the target address to allowed 32bits range by R15. Use R15 to limit RCX (return address)in specific 4GB space

  42. Read/Write Memory 0000000001000380 <testA>: …… 1000387: c7 45 f4 00 00 00 10 movl $0x10000000,-0xc(%rbp) 100038e: c7 45 f0 00 00 00 20 movl $0x20000000,-0x10(%rbp) ……………….. 10003a3: 89 c0 mov %eax,%eax 10003a5: 41 c6 84 47 11 00 00 movb $0x66,0x20000011(%r15,%rax,2) ……………… 10003b1: 89 c0 mov%eax,%eax 10003b3: 41 8a 44 07 22 mov 0x22(%r15,%rax,1),%al 10003b8: 88 45 ebmov%al,-0x15(%rbp) inttestA(int I) { intvRet; char *p1=0x10000000; char *p2=0x20000000; char *p3; char p4; p3=(char *)((int)p1*2+p2); p3[0x11]=0x66; //Write p4=p3[0x22]; //Read …. } //Write Clear RAX high-32bits Use R15 to limit RAXin specific 4GB space //Read Clear RAX high-32bits Use R15 to limit RAXin specific 4GB space The Read/Write Memory address would be limited in the 4GB 32bits range by R15.

  43. NaCl Software Fault Isolation in ARM Trust Code Region 3-1GB UnTrustCode Region 0-1GB NaCl ARMv32 Instruction Software Fault Isolation Memory

  44. SP Register Operation in ARMv32 testB(0x1234); inttestB(int I) { intvRet; void *libraryHandle; … } 250: e3010234 movw r0, #4660 ; 0x1234 .............. 25c: ebfffffe bl 160 <testB> Function in 16bytes Alignment //by armv7 pnacl-clang 00000160 <testB>: 160: e92d4800 push {fp, lr} 164: e24dd010 sub sp, sp, #16 168: e3cdd103 bicsp, sp, #-1073741824 ; 0xc0000000 The modification of SP would be replaced by a set instructions to limit the 32bits SP would be below 1GB address limit the SP address below 1GB address

  45. Function Call in ARMv32 char gpHello[]="Hello Loda!\n"; int (*f1)(const char *); …… f1 = dlsym(libraryHandle, "puts"); f1(gpHello); //by armv7 pnacl-clang 1bc: ebfffffebl<dlsym> …… 1e8: e3c1113f bic r1, r1, #-1073741809 ; 0xc000000f 1ec: e12fff31 blx r1 r1 in 16bytes Alignment and limit the address below 1GB address The function target address would be 16 bytes alignment, and limit the target address below 1GB address.

  46. Function Return in ARMv32 inttestB(int I) { intvRet; …………… vRet=0x1234*testA(0x888); return vRet; } limit the SP address below 1GB address //by armv7 pnacl-clang 214: e3cdd103 bicsp, sp, #-1073741824 ; 0xc0000000 218: e8bd4800 pop {fp, lr} 21c: e320f000 nop {0} 220: e3cee13f biclr, lr, #-1073741809 ; 0xc000000f 224: e12fff1e bxlr LR in 16bytes Alignment and limit the address below 1GB address Don’t allow “pop {pc}” directly. The function return address would be 16 bytes alignment, and limit the target address in LR below 1GB address.

  47. Read/Write Memory in ARMv32 00000110 <testA>: 110: e24dd018 sub sp, sp, #24 114: e3cdd103 bic sp, sp, #-1073741824 ; 0xc0000000 118: e3a01201 mov r1, #268435456 ; 0x10000000 ............ 120: e58d100c str r1, [sp, #12] 124: e3a01202 mov r1, #536870912 ; 0x20000000 128: e59d000c ldr r0, [sp, #12] 12c: e3a0207b mov r2, #123 ; 0x7b 130: e58d1008 str r1, [sp, #8] ............... 148: e3a01066 mov r1, #102 ; 0x66 14c: e320f000 nop {0} 150: e3c00103 bic r0, r0, #-1073741824 ; 0xc0000000 154: e5c01000 strb r1, [r0] ............. 164: e3c00103 bic r0, r0, #-1073741824 ; 0xc0000000 168: e5d00022 ldrb r0, [r0, #34] ; 0x22 16c: e5cd0003 strb r0, [sp, #3] ............... inttestA(int I) { intvRet; char *p1=0x10000000; char *p2=0x20000000; char *p3; char p4; p3=(char *)((int)p1*2+p2); p3[0x11]=0x66; //Write p4=p3[0x22]; //Read …. } //Write limit the ro addressbelow 1GB address //Read limit the ro addressbelow 1GB address The Read/Write Memory address would be limited below 1GB address by R0.

  48. For Hacker’s View Inner sandbox: binary validation Would limit stackin specific 4GB memory space intfunc(…..) { …………………………. } Use R15 to limit UnTrust function callin specific 4GB space Return to caller function. Would limit in 32bytes alignmentand specific 4GB memory space. outer sandbox: OS system-call interception

  49. Conclusion LLVM support IR and could run on variable processor platforms. Portable native client with LLVM should be a good candidate to play role in Browser usage ,and the LLVM would have a good role on Android platform. It is a new security protection model, use user-space Sandbox to run native code and validate the native instruction without kernel-level privilege involved. Break the Sandbox!!!

  50. Appendix

More Related