A survey of Buffer overflow exploitation on HTC touch mobile phone Advanced Defense Lab CSIE NCU Chih-Wen Ou
Jan 21, 2016
A survey of Buffer overflow exploitation on
HTC touch mobile phone
Advanced Defense Lab
CSIE NCU
Chih-Wen Ou
Abstract
Buffer overflow issues on ARM based handheld devices (HTC touch mobile phone)
Theoretical analysis and practical testing programming
Acknowledgement
怡群 Collin Mulliner
– Exploiting PocketPC, What the Hack! July 2005.
Collin Mulliner – BlackHat Japen, October 2008
Everybody and 老師
Outline
Introduction Background Programming Evaluation and Discussion Future work Conclusion
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)
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
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
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)
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)
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!
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)
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
Programming
Code and result
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
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
Programming
Code: execution in global data area
Programming
Code: execution in stack
Evaluation and Discussion
Injected instruction in Stack– Success(emulator)– Failed (device)
Injected instruction in global data– success
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
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
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
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
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