A survey of Buffer overflow exploitation on HTC touch mobile phone

1. A survey of Buffer overflow exploitation on HTC touch mobile phone Advanced Defense Lab CSIE NCU Chih-Wen Ou

2. Abstract • Buffer overflow issues on ARM based handheld devices (HTC touch mobile phone) • Theoretical analysis and practical testing programming

3. Acknowledgement • 怡群 • Collin Mulliner • Exploiting PocketPC, What the Hack! July 2005. • Collin Mulliner • BlackHat Japen, October 2008 • Everybody and 老師

4. Outline • Introduction • Background • Programming • Evaluation and Discussion • Future work • Conclusion

5. Introduction • ARM based handheld devices • Most widely used processor • PDAs • GPS devices • Mobile phone devices • Symbian • WinCE • iPhone • Our test platform: HTC touch • ARM processor • Windows mobile 6.0 (WinCE 5)

6. Introduction • Buffer overflow issues • Without social engineering • Computer compromised • String data manipulation without proper bound check • Memory corruption and possible malicious execution flow redirection • shellcode programming on ARM based WinCE • ARM assembler and disassembler • Visual studio with windows mobile 6.0 sdk • ARM instruction set reference • C. Mulliner’s work since 2003

7. Background • ARM • RISC Instruction set architecture • 32 bit word (4 bytes long) • Separated Instruction and data cache • Register organization (user32/system mode) • r0-r12 are general purpose register • r13 is stack pointer SP • r14 is subroutine link register LR • r15 is program counter PC

8. Background • WinCE • Slot virtual memory designed • 32-bit addressing, 4G address space • Divided into 32 MB sized slots • Slot 0 mapped for the “current execution” process • 33 slots used for user processes (including slot 0) • 1 slot for DLLs • Others slots used for kernel • Memory protection exists ( claimed by C. Mulliner)

9. Background • WinCE • Processes • Basically no thread limit (by C. Mulliner) • All processes share the same 4G virtual address space • Only few slots can be accessed by a certain process • XIP DLLs • eXecutin In Place DLLs • ROM • Function addresses are always the same (By C. Mulliner)

10. Background • C programming on WinCE • Dangerous string manipulation functions • Strcpy, strcat, sscanf…etc • Excution flow control variable in stack • LR is designed for resuming the execution address when subroutine call is finished • (mov pc,lr) • Hard to change the execution flow • Actually in our test program, saving return address in stack is still used on WinCE, when issuing a further subroutine call and current LR needs to be save in stack • The saved return address is always directly loaded to PC • (ldr pc, [sp],#4) • Buffer overflow vulnerabilities may exist!

11. Programming • Memory analysis program • Show the address of global variables • 0x000140dc (slot 0) • Show the address of local variables in stack • 0x??07fe7c (device) • 0x1807fe7c (emulator) • Different slot • Show the start address of function exectest() • 0x00011050 (slot 0) • Show the address of function MessageBoxW • 0x03f7f720 (fixed in slot 1)

12. Programming • Execution flow redirection testing • By directly rewriting the guessed memory address of first local variable plus offsets • The new redirected address point to a static link compiled target procedure in code segment because of leak information of : • Execution in stack • Execution in global data • Execution among unknown memory layout

13. Programming • Code and result

14. Programming • Simple MessageBox pop up Shellcode • Call MessageBoxW(0,0,0,0) by directly issuing a function pointer call from 0x03f7f720 • ((int(*)(DOWRD, DOWRD, DOWRD, DOWRD))(0x3f7f720))(0,0,0,0); • 感謝怡群 • 32 bytes of 8 instructions • “\x00\x30\xa0\xe3” mov r3, #0 • “\x00\x20\xa0\xe3” mov r2, #0 • “\x00\x10\xa0\xe3” mov r1, #0 • “\x00\x00\xa0\xe3” mov r0, #0 • “\xfe\x47\xa0\xe3” mov r4, #0xEF, 14 • “\x8e\x4e\x44\xe2” sub r4, r4, #0x8E, 28 • “\x0f\xe0\xa0\xe1” mov lr, pc • “\x04\xf0\xa0\xe1” mov pc, r4

15. Programming • According to result of analysis so far and the finished shellcode, we can write a test program on our HTC touch phone. • To test executing shellcode in global data area • To test executing shellcode in stack • Both above execution are launched by rewriting the return address in stack

16. Programming • Code: execution in global data area

17. Programming • Code: execution in stack

18. Evaluation and Discussion • Injected instruction in Stack • Success(emulator) • Failed (device) • Injected instruction in global data • success

19. Evaluation and Discussion • Executing in stack failed • Instruction cache? • Global data is much closer to code segment composed of instructions compared to local variable, which is in stack • Therefore, global data may be cached into instruction cache with other instructions (just guessing…) • Address range? • Any execution limitation of program counter? • Other possible execution limitations cause such failure • Found GS function on WinCE • __security_check_cookie • I will test it in the future

20. Evaluation and Discussion • Programs on ARM based WinCE platform • Extremely similar layout between emulator and HTC device. • No variation of layout when re-executing the program • Easy to decide addresses of functions within XIP DLLs without changed (ROM) • By default, GS function always protects our execution flow from control variable in stack being changed by malicious craft attacking string Good for security

21. Evaluation and Discussion • Programming on ARM based WinCE platform • Once program are compiled without GS on. • Once execution control variables can be changed through buffer overflow vulnerabilities • Once there is at least one enough writable global data space, especially string( because of XIP DLLs, may not be necessary) • We induce that such kind of program on a device is dangerous for compromising

22. Future work • Vulnerable program threat analysis • How much possibility for attacker changing the value of control variable in stack • GS function • Well attacking execution • Execution in global data • Execution by repeated calls within XIP DLLs • Completely proof of concept • A vulnerable program • buffer overflow vulnerable program on HTC touch phone • A classic attacking string • Malicious craft attacking string • A practical compromising • Download and execution … etc

23. Conclusion • Introduction of ARM register usage and its operation during subroutine call • WinCE memory layout analysis on emulator and HTC touch • Practical shellcode programming on ARM • Practical shellcode execution on HTC touch • GS function found